Orchestration of control applications in the open radio access network

Abstract

The present disclosure relates to a method (100) performed by a system for orchestration of control applications in an open radio access network, O-RAN (10). The method (100) involves obtaining (110) quality attributes of control applications (24, 34; 5 220; 320; 904; 1004; 1101; 1204; 1312) executable on radio access network intelligent controller, RIC, platforms (26, 36; 202, 210; 310, 322; 906; 1006; 1206) in the O-RAN (10), and obtaining (120) at least one intent comprising fulfilment objectives for the quality attribute. Based on values of the quality attribute in relation to the fulfilment objectives, the method (100) involves determining (130) an invocation order of the 0 control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312), and orchestrating (140) the control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) on the RIC platforms (26, 36; 202, 210; 310, 322; 906; 1006; 1206) in the invocation order.

Description

[0001] ORCHESTRATION OF CONTROL APPLICATIONS IN THE OPEN RADIO

[0002] ACCESS NETWORK

[0003] TECHNICAL FIELD

[0004] The present disclosure relates to the Open Radio Access Network (O-RAN), and more particularly to an orchestration of control applications therein.

[0005] BACKGROUND

[0006] The O-RAN involves a network architecture that disaggregates traditional, monolithic radio access networks into software-based modular and interoperable control components. The O-RAN aims to promote vendor diversity, innovation, and costeffectiveness by standardizing interfaces between network elements, thereby allowing operators to mix and match components from different vendors. This open and flexible approach is designed to enhance network efficiency, reduce dependence on a single vendor, and foster the development of advanced technologies in the telecommunications industry. O-RAN has applications beyond traditional telecommunications and networks, and its principles and concepts may be applied for purposes of smart cities, industrial loT, satellite communication, rural connectivity, edge computing, or the like. The concepts and principles behind O-RAN are also expected to continue evolving and play a role in future generations of wireless technology for mobile telecommunication networks.

[0007] SUMMARY

[0008] The present inventors have identified limitations regarding contemporary orchestration tools for control application in the O-RAN, and thus seek to provide one or more improvements to the prior art. It is in view of these considerations, and others, that the various embodiments of this disclosure have been made. The present disclosure therefore recognizes the fact that there is a need for alternatives to the existing art described above. It is an object of some embodiments to solve, mitigate, alleviate, or eliminate at least some of the above or other disadvantages. In a first aspect, a method is provided. The method is performed by a system for orchestration of control applications in an open radio access network, O-RAN, and comprises: obtaining at least one quality attribute for each one of a plurality of control applications, the control applications being executable on at least one radio access network intelligent controller, RIC, platform in the O-RAN; obtaining at least one intent comprising fulfilment objectives for said at least one quality attribute; determining an invocation order of the control applications based on values of the at least one quality attribute in relation to their corresponding fulfilment objectives; and orchestrating the control applications on the at least one RIC platform in the invocation order.

[0009] In some embodiments, determining the invocation order comprises selecting a sequence of said plurality of control to be consecutively orchestrated such that each of the quality attributes for the sequence of said plurality of control applications satisfy the fulfilment objectives.

[0010] In some embodiments, the sequence of said plurality of control applications is selected by: generating an invocation graph having a plurality of invocation order candidates, wherein each invocation order candidate comprises a sequence of control applications enforcing the fulfilment objectives; and processing the invocation graph.

[0011] In some embodiments, processing the invocation graph involves: traversing the invocation graph to determine whether each traversed control application satisfies the fulfilment objectives; and during said traversal of the invocation graph, pruning the invocation graph for determining the invocation order from among the invocation order candidates.

[0012] In some embodiments, pruning the invocation graph involves: (a) selecting a particular control application in a particular layer of the invocation graph having an extremum quality attribute value from among other control applications in said particular layer, provided that a removal of the particular control application maintains the invocation graph as traversable; (b) removing the particular control application from said particular layer; (c) computing an aggregated value for the invocation graph; (d) stopping the pruning in response to the aggregated value being compliant with the fulfilment objectives; and (e) repeating steps (a) to (d) one or more times until the aggregated value is compliant with the fulfilment objectives. In some embodiments, the pruning is further based on a learning factor from outputs of previously executed control applications, the learning factor being a probability that the quality attributes of the control applications in the invocation order fail to meet their respective fulfilment objectives.

[0013] In some embodiments, the method further comprising combining a plurality of quality attributes associated with a single control application into a weighted quality attribute on which the invocation order for said single control application is based.

[0014] In some embodiments, the invocation order determines an order of invocation of control applications in a plurality of distributed RIC platforms.

[0015] In some embodiments, the obtaining of the at least one quality attribute from the RIC platform is performed in response to a control application being registered to the RIC platform.

[0016] In some embodiments, the method further comprising learning an estimation of the quality attributes in near real-time by a request to an orchestrated control application.

[0017] In some embodiments, the method further comprising applying a temporal difference learning algorithm for learning the estimation of the quality attributes.

[0018] In some embodiments, the fulfilment objectives are system-level threshold values specifying limits of allowed values of the respective quality attributes.

[0019] In some embodiments, said at least one quality attribute is one or more of an execution time attribute, an energy consumption attribute, a resource requirement attribute, a network reliability attribute, a network availability attribute, a network resilience attribute, a jitter, a packet loss attribute, and a latency.

[0020] In some embodiments, the method further comprising generating an exception indicator in response to the at least one quality attribute failing to satisfy the fulfilment requirements, the exception indicator generation triggering a re-determination of the invocation order.

[0021] In some embodiments, the control applications are orchestrated in the O-RAN by triggering respective invocation calls to the control applications to execute on the at least one RIC platform. In some embodiments, the at least one RIC platform is a near real-time RIC platform or a non-real-time RIC platform, the control applications in the near real-time RIC platform being xApps and the control applications in the non-real-time platform being rApps.

[0022] In some embodiments, the system is embodied as a network apparatus. The network apparatus may be a network node.

[0023] In some embodiments, the system includes a plurality of network apparatuses and the method is performed in a distributed manner by at least two network apparatuses from among the plurality of network apparatuses. At least one of the network apparatuses may be a network node.

[0024] In a second aspect, an apparatus is provided. The apparatus comprises a processor configured to perform the method of the first aspect.

[0025] In a third aspect, a computer program is provided. The computer program comprises instructions which, when executed on at least one processor, cause the at least one processor to carry out the method of the first aspect.

[0026] In a fourth aspect a carrier is provided. The carrier contains the computer program of the third aspect, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0027] Various aspects and embodiments described herein allow for an adherence to both functional and non-functional quality attributes of control applications in the O- RAN, while at the same time manage timing aspects (e.g. real-time aspects) associated with a computing environment where the control applications execute. A mechanism is provided where both functional and non-functional (def) quality attributes are considered when performing the orchestration and invocation of control applications dealing with a certain management task. This may enable an on-demand and intelligent invocation of control applications, by the RIC platforms, for achieving the intent objectives, as opposed to the prior art solutions which delegates the responsibility to the control applications and expects conformance to required constraints on best effort basis.

[0028] Further, the various aspects and embodiments described herein may allow for intent submission which evaluates whether an intent with associated time constraints for enforcement is acceptable by the RIC platform, and whether it is possible to fulfil it based on observed earlier performance of available control applications. Intent fulfilment may also be provided, which estimates the risk of a certain group of control applications in the RIC platform adhering to time constraints. Further, control application lifecycle monitoring may be achieved, which monitors a performance of a control application with respect to intent handling and enforcement in the RIC platform. In addition, adherence to stipulated quality attributes of the control applications may be provided, such as execution time or energy footprint, which guides the selection of a desired invocation order of control applications.

[0029] BRIEF DESCRIPTION OF THE DRAWINGS

[0030] These and other aspects, features and advantages will be apparent and elucidated from the following description of various embodiments; references being made to the appended diagrammatical drawings which illustrate non-limiting examples of how the concept can be reduced into practice.

[0031] FIG. 1 is an exemplary schematic illustration of a communication environment comprising an open radio access network and a telecommunication network in communicative connection.

[0032] FIG. 2 is an exemplary schematic illustration of a computer architecture of a near real-time RIC.

[0033] FIG. 3 is an exemplary schematic illustration of a computer architecture of a non-real-time RIC.

[0034] FIG. 4 is an exemplary schematic illustration of an intent handling function.

[0035] FIG. 5 is an exemplary schematic illustration of intent manager registration and discovery.

[0036] FIG. 6 is an exemplary schematic illustration of various intent manager control loops

[0037] FIGs. 7A-B are exemplary schematic illustrations of various intent manager control loops.

[0038] FIG. 8 is an exemplary flowchart diagram of a method for orchestration of a plurality of control applications in an O-RAN. FIG. 9 is an exemplary flowchart diagram of a quality attribute registration.

[0039] FIG. 10 is an exemplary flowchart diagram of a quality attribute learning procedure.

[0040] FIG. 11 is an exemplary schematic illustration of an invocation graph construction.

[0041] FIG. 12 is an exemplary flowchart diagram of a method for quality-aware orchestration of control applications based on an invocation graph.

[0042] FIG. 13 is an exemplary schematic illustration of a telecommunication network connected via an intermediate network to a host computer.

[0043] FIG. 14 is an exemplary schematic illustration of a host computer communicating via a base station with a user equipment over a partially wireless connection.

[0044] FIGs. 15-18 are exemplary flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.

[0045] DETAILED DESCRIPTION

[0046] Hereinafter, certain embodiments will be described more fully with reference to the accompanying drawings. The invention described throughout this disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention, such as it is defined in the appended claims, to those skilled in the art.

[0047] The term ’’coupled” is defined as connected, although not necessarily directly, and not necessarily mechanically. Two or more items that are ’’coupled” may be integral with each other. The terms "a” and ”an” are defined as one or more unless this disclosure explicitly requires otherwise. The terms ’’substantially”, ’’approximately”, and ’’about” are defined as largely, but not necessarily wholly what is specified, as understood by a person of ordinary skill in the art. The terms ’’comprise” (and any form thereof, such as "comprises” and ’’comprising”), ’’have” (and any form thereof, such as ’’has” and ’’having”, ’’include” (and any form thereof, such as ’’includes” and ’’including”) and ’’contain” (and any form thereof, such as ’’contains” and ’’containing”) are open-ended linking verbs. As a result, a method that ’’comprises”, ’’has”, ’’includes” or ’’contains” one or more steps possesses those one or more steps, but is not limited to possessing only those one or more steps.

[0048] FIG. 1 is an exemplary schematic block diagram of a communication environment where some of the inventive concepts of the present disclosure may be applied. It shall be noted that the visualized block diagram is but one exemplary arrangement of the O-RAN 10. In other examples variations may be conceived. The communication environment comprises the O-RAN 10 and a communication system 1 being in communicative connection with one another. The communication system 1 may be a cellular communication system, or in optional embodiments other types of communication systems such as WiFi, Bluetooth or satellite communication systems. The communication system comprises a wireless communication device 4, or wireless device 4 for short. The wireless device 4 is in wireless communication with a radio base station (BS) 6 of the communication system 1. The wireless device 4 may be what is generally referred to as a user equipment (UE) herein. The terms wireless device and UE are used interchangeably throughout this disclosure to facilitate the reading of the disclosure. The wireless device 4 is depicted in FIG. 1 as a mobile phone, but may be any kind of device with cellular communication capabilities, such as a tablet or laptop computer, machine-type communication (MTC) device, or similar.

[0049] The UE 4 and BS 6 are examples of what in this disclosure is generically referred to as communication apparatuses. Embodiments are described below in the context of a communication apparatus in the form of the UE 4 or BS 6. However, other types of communication apparatuses can be considered as well, such as a WiFi access point or a WiFi enabled device.

[0050] In the exemplary illustration of FIG. 1, the O-RAN 10 comprises a non-real-time Radio Access Network Intelligent Controller (non-RT RIC) platform 26 and a near realtime Radio Access Network Intelligent Controller (near-RT RIC) platform 36. In other network arrangements, the O-RAN 10 may involve at least one, or a plurality of, the aforementioned platforms 26, 36. These platforms 26, 36 may form part of a distributed computing environment. No limitations shall thus be put in regards of the number and type of RIC platforms in the O-RAN 10. The RIC platforms 26, 36 are configured to control the performance of the O-RAN 10 towards certain fulfilment objectives. The near-RT RIC platform 36 may be included in an open cloud (O-cloud) 50, and the non- RT RIC platform 26 in a service management and orchestration (SMO) framework 20.

[0051] In the O-RAN 10 a plurality of control applications, referred to in FIG. 1 as rApps 24 and xApps 34, respectively, are configured to execute on the respective RIC platforms 26, 36. The rApps 24 and xApps 34 are both closed control loop software running on their respective RIC platforms 26, 36. However, their scope for RAN optimization is different from one another in the time domain. In the non-RT RIC platform 26, the rApps 24 are configured to control the behaviour of the O-RAN 10 to certain targets by transmitting Al policies. The Al policies shall be understood as intents comprising fulfilment objectives. The rApps 24 are configured to leverage the functionalities available in the SMO framework 20 to provide value added services related to operation and optimization of the O-RAN 10. The scope of the rApps 24 includes, but is not limited to, radio resource management, data analytics, and providing enrichment information (El). In the near-RT RIC platform 36, the xApps 34 use E2 interfaces to control the functionalities of the O-RAN 10. Control of functionalities in this regard involves controlling operations of E2 nodes 40, including open distributed units (O-DU) 42, open centralized units in the control plane (O-CU-CP) 44, and open centralized units in the user plane (O-CU-UP) 46. The O-DUs 42 are logical nodes hosting radio link control (RLC), medium access control (MAC) or High-PHY layers based on a lower layer functional split. The functional split refers to the division of functions (broken into two layers) between different elements or components within the radio access network architecture. The O-CU-CPs 44 are logical nodes hosting radio resource control (RRC) and the control plane part of the packet data convergence protocol (PDCP). The O-CU-UPs 46 are logical nodes hosting the user plane part of the PDCP protocol and service data adaptation protocol (SDAP).

[0052] The rApps 24 and xApps 34 are configured to receive fulfilment objectives through one or more intents. To this end, an intent comprises fulfilment objectives, where the fulfilment objectives may be seen as desirable targets for one or more quality attributes to reach upon the execution thereof. The intents are dynamic attributes and thus subjected to changes. The changes may be carried out by one or more rApps 24 or xApps 34, by one or more platforms 26, 36, or from system level perspectives. For system level perspectives, the intents may be system-level threshold values specifying limits of allowed values of the respective quality attributes. For the non-RT RIC platform 26, the intents may be in the form of standardized intents. For the near-RT RIC platform 36, the intents may be standardized policies. Purely by way of non-limiting examples, the quality attribute may be one or more of an execution time attribute, an energy consumption attribute, a resource requirement attribute, a network reliability attribute, a network availability attribute, a network resilience attribute, a jitter, a packet loss attribute, and a latency. Other relevant quality attributes that affect the performance of the O-RAN 10 are readily envisaged by persons skilled in the art. Intents will be further detailed later on in this disclosure with reference to FIGs. 4-7.

[0053] The present disclosure is concerned with the orchestration of a plurality of rApps 24 and xApps 34 on the respective RIC platforms 26, 36, based on the quality attributes. More particularly, the present disclosure concerns determining a preferred order of invocation in which the rApps 24 and xApps 34 are to be controlled upon the orchestration thereof in the O-RAN 10, wherein said invocation order is based on values of the quality attributes. The invocation order may determine an order of rApps 24 and xApps 34 to be invoked across a plurality of distributed RIC platforms 26, 36. For purposes of orchestration as discussed herein, an orchestration function 22, 32 is presented. The orchestration function 22, 32 is a novel component in the context of the O-RAN 10 which addresses many known issues of the prior art. In particular, the orchestration function 22, 32 addresses adherence of quality attributes, including both functional and non-functional quality attributes, of the rApps 24 and the xApps 34. The functional quality attributes focus on what the application does and its features, including core functionalities, user interface, data handling, security features, and so forth. The non-functional quality attributes are directed at how the control application performs, in terms of performance, reliability, usability, scalability, maintainability and security measures. In essence, the functional quality attributes define what the control application does, while the non-functional quality attributes define how well the control application does it. At the same time as the quality attributes are adhered to, the orchestration function 22, 32 manages timing aspects (e.g. real-time aspects) associated with the computing environment..

[0054] Considering timing aspects, it is of importance that control loops in the O-RAN 10, i.e., those associated with the rApps 24 and xApps 34, are delicately managed. This is especially the case for the lower control layers in the O-RAN 10, such as below the MAC layer in the protocol stack. For example, the O-RAN 10 may specify that programmatic control of some of the E2 nodes 40 shall be carried out in a particular time range, e.g. between 1 ms and 1 second, and be performed by xApps 34 running on the near-RT RIC platform 36. Similarly, an rApp 24 running on the non-RT RIC platform 26 may be expected to perform its functions in the range of 1 second and higher. Such timing aspects, especially for the lower ends of the respective ranges, may limit the applicability of intent-based closed loop management in several different ways. The prior art is limiting in this regard, because it merely suggests specifying a constant time constraint that control applications can use in order to avoid deadlocks, or other real-time control issues. The time constraints are used to manage various requirements associated with the O-RAN and are carried via intents. In the O-RAN there are expectations of the control loops of the control applications, such as pertaining to running of the control applications so that they can react to and control certain properties of the O-RAN. These are naive mechanisms that do not take into consideration the dynamicity of the computing environment that is the O-RAN.

[0055] While managing timing aspects is important in the O-RAN 10, so is adherence to functional and non-functional quality attributes of the rApps 24 and the xApps 34. In contemporary O-RAN solutions, these control applications are invoked exclusively based on their functional characteristics (i.e., their ability to perform a certain task) which is determined by implementation logic. The required time constraints in the O- RAN is currently based on design time considerations of the control applications and best effort management in the RIC platforms. There is thus no solution for on-demand invocation of control applications in the O-RAN from their respective platforms that can enforce adherence to functional and non-functional quality attributes. This is what the orchestration function 22, 32 is set out to resolve, and the present disclosure describes considerations necessary for the orchestration function 22, 32 to operate for providing such on-demand invocation of the control applications in the O-RAN 10.

[0056] The orchestration function 22, 32 is adapted to carry out a few steps in order to carry out the orchestration of the rApps 24 and xApps 34 in the O-RAN 10. The first step is to obtain at least one quality attribute for each one of a plurality of the rApps 24 and xApps 34. The second step is to obtain at least one intent comprising fulfilment objectives for the at least one quality attribute. Note that the order of obtaining quality attributes or the at least one intent is not necessarily of relevance. The third step is to determine an invocation order of the rApps 24 and xApps 34 based on values of the at least one quality attribute in relation to their corresponding fulfilment objectives. Finally, the fourth step is to orchestrate the rApps 24 and xApps 34 in the invocation order.

[0057] The orchestration function 22, 32 may be configured to orchestrate the respective rApps 24 and xApps 34 in the O-RAN 10 by triggering respective invocation calls in an order determined by the invocation order to the rApps 24 and xApps 34 to execute on the respective RIC platform 26, 36. Hence, the orchestration function 22, 32 is responsible for managing which of the rApps 24 and xApps 34 shall be invoked, in what order, and for how long they should run, for solving certain tasks. The invocation is configured to guide the RIC platforms 26, 36 in keeping the O-RAN 10 in adherence to the functional and non-functional quality attributes, while at the same time operating towards achieving the intent- specified fulfilment objectives pertaining to the quality attributes. For instance, the rApps 24 or xApps 34 may be invoked while keeping an execution time below a certain maximum execution value, or keeping an energy footprint of the control loops below a certain maximum energy consumption target. Any of the other quality attributes may be considered, and it shall be understood that it is not necessarily a maximum value limit that is considered herein. For certain other quality attributes it may be necessary to specify a minimum value, such as for a minimum packet loss attribute value that specifies the minimum number of packet losses that are acceptable for a certain transmission of information. Thus, the intents may comprise fulfilment objectives pertaining to an extremum value of the quality attributes (e.g. minimum or maximum). In other embodiments, the fulfilment objectives may pertain to an arbitrary range having at least one extremum value.

[0058] Further present in the O-RAN 10 are various control components, serialization functions, communication channels, and interfaces / peripherals. The notations 01, 02, El, E2, Fl-C, Fl-U define interfaces for allowing serialization of specific types of communication between control components of the O-RAN 10. Internal computer architectures of the RIC platforms 24, 34 will now be described in more exhaustion with further reference to FIGs. 2 and 3.

[0059] FIG. 2 is an exemplary schematic block diagram of a computer architecture of a near-RT RIC 200. It shall be noted that the visualized block diagram is but one exemplary arrangement of the near-RT RIC 200. In other examples variations may be conceived. The near-RT RIC 200 is a logical function that enables near-real-time control and optimization of elements and resources of the O-RAN 10, such as the E2 nodes 240, via fine-grained (e.g. UE basis, Cell basis) data collection and actions over E2 interfaces. Such data collection and actions may involve the gathering of information about individual UEs or specific cells through E2 interfaces in the 3GPP architecture. This data includes parameters like signal strength and throughput. The collected information enables network operators to take specific actions, such as optimization and load balancing, through E2 interfaces, contributing to the effective management and enhancement of network performance. In addition to the interfaces already described, FIG. 1 further shows the Y 1 interface between the near RT RIC 200 and Y 1 consumers 250. This interface enables RAN analytics information exposure from the near-RT RIC 200.

[0060] The near-RT RIC 200 is associated with a plurality of platform requirements for the near-RT RIC platform 210. The near-RT RIC platform 210 comprises a database 239 that stores RAN information, history of time- varying network state, as well as configurations related to E2 nodes 240, cells, bearers, flows, UEs, etc., and the mapping therebetween. This information may be provided as a service to any xApp 220a-n that requests it.

[0061] The near-RT RIC platform 210 comprises APIs decoupled from specific implementation solutions, including a shared data layer (SDE) 238 that works as an overlay for underlying databases and enables simplified data access. The near-RT RIC platform 210 comprises a conflict mitigation module 232 which is configured to resolve potentially overlapping or conflicting requests from multiple xApps 220a-n. The near- RT RIC platform 210 comprises an xApp subscription management module 233 which is configured to merge subscriptions from different xApps 220a-n and provide unified data distribution to xApps 220a-n. The near-RT RIC platform 210 comprises a management function 234 which is configured to manage faults, configurations, and performance as a service producer to the SMO framework 201. Further, the management function 235 is configured to manage logging, tracing and metrics collection, which captures, monitors and collects the status of near RT RIC internals and can be transferred to external systems for further evaluations. The near-RT RIC platform 210 comprises a security module 235 which provides security schemes for the xApps 220a-n. The near-RT RIC platform 210 comprises an AI / ML support module 236 that supports data for pipelining, training and performance monitoring. The near- RT RIC platform 210 comprises an xApp repository function 237 configured to select xApps 220a-n for Al message routing based on Al policy types and operator policies. The xApp repository function 237 is further configured to manage access control of Al- EI types for xApps 220a-n based on operator policies. The near-RT RIC platform 210 comprises a messaging infrastructure module 231 which is configured to enable message interaction amongst internal functions of the near-RT RIC 200. The near-RT RIC platform 210 comprises an API enablement module 230 which is configured to support capabilities related to near-RT RIC API operations (e.g. API repository / registry, authentication, discovery, generic event subscription, etc.).

[0062] The near-RT RIC platform 210 further comprises various interface termination modules 212, 214, 216, 218. These modules enable exchange of messages via respective interfaces pertaining to e.g. termination of services. The 01 termination module 212 configured to terminate the 01 interface from the SMO 201, the Al termination module 214 is configured to terminate the Al interface from the non-RT RIC platform 202, the Y1 termination module 216 is configured to terminate the Y1 interface from the Y 1 consumer 250, and the E2 termination module is configured to terminate the E2 interface from an E2 node 240. FIG. 3 is an exemplary schematic block diagram of a computer architecture of a non-RT RIC 300. It shall be noted that the visualized block diagram is but one exemplary arrangement of the non-RT RIC 300. In other examples variations may be conceived. As seen in the illustration, the various blocks are associated with different types of functions. These functions are either 1) functions anchored inside the SMO framework 301 (in uniform lines), 2) functions anchored outside the SMO framework 301 (in dotted lines) or 3) non-anchored functions (in dashed lines). The functions anchored inside the SMO framework 301 may be defined as logical functions that are part of the SMO framework 301. The functions anchored outside the SMO framework 301 may be defined as logical functions that are not part of the SMO framework 301. It is noted that these definitions do not make any assumptions as regards potential mandatory or optional qualifiers of the functions being anchored.

[0063] The non-RT RIC 300 represents a subset of functionality of the SMO framework 301, and supports intelligent RAN operation and optimization. The Al termination module 318 is configured to logically terminate the Al interface, and provide policybased guidance, enrichment information, and AI / ML model management to the near-RT RIC 322. The non-RT RIC 300 may access other SMO framework functionalities, for instance influencing what is carried across the 01 and open fronthaul (FH) M-plane to the E2 nodes 324 and the open radio units 326, respectively, and across the 02 interface to the O-cloud 340.

[0064] The SMO framework 301 involves a non-RT RIC platform 310. An Al-related functions module 317 is configured to cause termination of the Al interface via the Al termination module 318. The SMO framework 301 is further configured to expose a set of R1 services to the rApps 320. The non-RT RIC platform 310 comprises an R1 services and exposure functions module 311 which involves a collection of services produced by logical functions in the SMO framework 301 or by the rApps 320. The R1 service management and exposure functions module 311 enable, amongst other functionalities, service registration, service discovery, service notification, authorization, authentication, communication support, and optional bootstrap and heartbeat services. The SMO framework 301 may further include a module for other SMO functions 313 which, among other functions, also offer RAN-specific slice management functionality.

[0065] The non-RT RIC platform 310 comprises an rApp management functions module 312 which enable the management of the rApps 320 within the context of the SMO framework 301. In non-limiting examples, such functions enable the configuration of the rApps 320, provide access to fault and performance related information from the rApps 320, and facilitate logging of rApps 320 functionalities. The R1 termination module 319 is configured to enable message exchange between the rApps 320 and other components of the SMO framework 301 for accessing the R1 service and exposure functions 311, as well as cause termination of the R1 interface.

[0066] The non-RT RIC platform 310 comprises a module for other non-RT RIC framework functions 313 which may provide additional services exposed via the R1 interface or provide El for Al-EI services. Further, the non-RT RIC platform 310 comprises an external terminations module 314 which enables the SMO framework 301 to exchange messages with external entities over interfaces outside the scope of the O- RAN 10. The non-RT RIC platform 310 also comprises an AI / ML workflow functions module 315 may include various services, including but not limited to an AI / ML training service, an AI / ML model management and exposure service, and / or an AI / ML model performance monitoring service. The AI / ML model management and exposure service may enable AI / ML model registration / deregistration, AI / ML model discovery, AI / ML model change subscription, AI / ML model storage, and / or AI / ML model training capability registration / deregistration. Other functions for data management and exposure are provided by the module for data management and exposure functions 316.

[0067] The SMO framework 301 further comprises a module for RAN OAM-related functions 304, which enables the rApps 320 to obtain information about alarms related to various network elements, obtain performance information related to the network elements (incl. e.g. network slicing information), obtain a current configuration of the network elements (incl. e.g. network slicing information), obtain trace information related to the network, obtain additional information related to the network elements (incl. e.g. network slicing information) and / or provision changes to the configuration of the network elements (incl. e.g. network slicing information). The network elements referred to above may be one of the E2 nodes 324, O-RUs 326 and the near-RT RIC 322. The RAN OAM-related functions module 304 may be configured to provide access to 0AM functionality for (i) the E2 nodes 324 and the near-RT RIC 322 via the 01 interface, (ii) the O-RUs 326 via the open FH M-plane interface, and (iii) RAN-specific network slicing in the SMO framework 301. The SMO framework 301 may further include an open FH M-plane termination module 306 configured to enable the SMO framework 301 to exchange messages with the O-RUs 326 via the open fronthaul M- plane interface pertaining to e.g. termination of services of the O-RUs 326. The SMO framework 301 may further include an 01 termination module 307 configured to enable the SMO framework 301 to exchange message with the near-RT RIC 322 and / or the E2 nodes 324 via the 01 interface, pertaining to e.g. termination of services.

[0068] The SMO framework 301 further comprises an 02 related functions module 303, which may enable the rApps 320 to obtain information related to the O-cloud 340 relating to e.g. infrastructure inventory, monitoring, provisioning, lifecycle management and / or software management. Further, the 02 related functions module 303 may enable the rApps 320 to obtain information related to the O-cloud 340 such as deployment inventory, monitoring and / or lifecycle management. Further, the 02 related functions module may enable the rApps 320 to provision changes of the configuration of the O- cloud 340, and / or to obtain additional information related to the O-cloud 340. Furthermore, the 02 termination module 305 may enable the SMO framework 301 to exchange messages with the O-cloud 340 over the 02 interface, pertaining to e.g. termination of services.

[0069] The SMO framework 301 is in further communication with various external services, including an external oversight module 332, an external AI / ME services module 334, and an external El sources module 336. The external terminations module 314 offer message exchange and service termination between the SMO framework 301 and one or more of these services over an external interface.

[0070] Reference will now be made to FIGS. 4-7, which present intents and associated functionalities. In contexts of the present disclosure, an intent is defined as a formal specification of all expectations including requirements, goals, and constraints given to a technical system. The definition excludes imperative implementation and solution aspects from the intent itself. Intent is therefore an expression of what needs to be achieved or avoided, or what outcome is more or less preferred, rather than indicating how and by which strategies and actions this can be realized. In this regard, artefacts including e.g., policies, workflows, rules, decision trees and other ways to express and implement a solution strategy, make decisions, and execute actions are separated from the intent expression. The understanding of intent implies implementation of intent- driven operations that strengthen system design concepts including e.g., a separation of concerns between sub-systems with encapsulation of solution implementations.

[0071] The concept of intent may be examined from the perspective of humans as external supervisors of autonomous systems, wherein intent serves as a specification of expectations. Humans, acting as customers or operators, communicate their needs to the autonomous system through intent, expecting the system to fulfil these needs using underlying infrastructure and resources appropriately. Intent is not only externally generated but also internally within the autonomous system to influence the behaviour of subsystems and contribute to overall goal fulfilment. These goal fulfilments are herein referred to as fulfilment objectives. External intents represent terminal goals, while internal intents express instrumental goals, thereby forming a solution strategy. The breakdown of goals involves transforming global terminal goals into detailed consequences, and intent serves as the mechanism to express these goals at various detail levels. The communication and management of intent involves system architecture, lifecycle management, and control loops. Although intent typically originates from automated processes or human input, it is received by a technical system, not intended for human consumption but for automated operation. However, there are exceptions, such as human intervention in case of system failure. Ensuring intuitiveness for humans and the use of formally defined models for intent expression are crucial to avoiding ambiguity and maintaining autonomy.

[0072] Intents may be categorized in various categories, including but not limited to targeted responsibility scope, concerns addressed with intent, origin type, and origin role, to name a few examples. The targeted responsibility scope may be the domain and layer in the autonomous network framework, or it can be an intent handling scope. The concerns addressed with intent may relate to service delivery, resource behaviour, regulatory compliance, or the like. The origin type may be derived from the category of the intent source, such as the type of entity that created the intent (human or another system). The origin role may be the entity which the intent originates from, e.g. product manager, customer, user, technician, etc. It shall be further understood that intent objects are a collection of distinct expressions, which means that a single intent can potentially address many concerns at once and therefore partially meet conditions of several intent categories.

[0073] FIG. 4 is an exemplary schematic block diagram of an intent handling function 400. The dashed arrows in the figure represent intent-based APIs, while the uniform arrows represent other, non-intent-based, APIs. Intent-based APIs refer to the means of communication between two intent handling functions, one of them having the role of an intent handler 410 and the other of an intent owner 420. The intent handling function 400 describes the functionality of the intent handler 410, which is a basic building block of intent-based operations. The intent owner 420 defines high-level goals for the system, specifying what needs to be achieved. The intent handler 410 is configured to interpret and execute goals at a lower level, dealing with the practical aspects of how to achieve them. The intent owner 420 thus sets objectives, while the intent handler 410 translates and implements those goals in the operational aspects of the system.

[0074] The intent handler 410 is configured to operate based on knowledge extracted and maintained by a knowledge unit 412. Knowledge in this context refers to operational goals and requirements as specified by the intents from the intent owner 420 in the form of fulfilment objectives. As described before, the fulfilment objectives are for quality attributes being, for example, one or more of an execution time attribute, an energy consumption attribute, a resource requirement attribute, a network reliability attribute, a network availability attribute, a network resilience attribute, a jitter, a packet loss attribute, and a latency. The knowledge unit 412 may be further configured to know the state of an environment 430, e.g. a system or a domain, for which an instance of the intent handling function 400 has the responsibility to operate, such as a certain RIC platform. While the intent specifies the wanted state to be in, measurements and analytics result may determine the current state, and the decision of the intent handling function 400 is primarily about closing the gap between the current state and the measured state.

[0075] The intent handler 410 comprises a decision unit 414. The decision unit 414 communicates with the knowledge unit 412, and is configured to decide about suitable actions needed to satisfy the fulfilment objectives defined by the intent. The intent handler 410 comprises a sensor unit 416 which is configured to percept (i.e. obtain) information of the environment 430. The environment 430 is in this context the surroundings in which the intent handling function 400 operates, and the sensor unit 416 may measure information pertaining to one or more of system state information, conditions and event of the system, domain knowledge, communication interface data, reporting mechanism information and external system and dependency data. The decision unit 414 is further configured to receive information percepted by the sensor unit 416, and based on this information submit a suggested decision to an actuator unit 418. The actuator unit 418 is configured to choose an action plan which can involve the definition of further intent 434 used to communicate requirements and goals to other subsystems. To this end, the intent handler 410 may act by defining an intent, thus becoming an intent owner itself. Moreover, the actuator unit 418 submits the actions to the environment 430, which in turn is updated to reflect changes provided by these actions, and the sensor unit 416 may accordingly percept information from the updated environment 430. Further updates 422 may be obtained by the knowledge unit 412 from other intent owners.

[0076] Further seen in FIG. 4 are various intent reports 424, 432. These are exchanged between components of the intent handling function 400 for reporting on status and success of intent handling. The intent handler 410 is configured to operate based on intent reports 424 and report back to an intent owner in other reports 432. For each individual intent there may thus be a sequence of reports directly related to this intent. The intent reports 424, 432 may be generated and pushed by the reporting intent handler 410, rather than being pulled by the intent owner. Conditions defined within the intent, known as reporting expectations, determine when and why reports 424, 432 are created. The intent handler 410 may be equipped with detailed domain or system state information, and may be uniquely positioned to detect intent violations and promptly report major events, such as intent degradation. While intent owners outline operational aspects through intent objects, the intent handler 410, acting as knowledge aggregators and relevance filters, report only on these specified aspects. The intent reports 424, 432 may serve as the primary mechanism for informing intent owners about the system state and compliance. This ensures a clear separation of concerns and authority between domains.

[0077] FIG. 5 is an exemplary schematic block diagram depicting registration and discovery 500 of intent managers 506, 508. The figure shows interfaces involved in intent discovery 510, intent registration 520 and intent handling 530. An intent manager 506, 508 is an entity within a system responsible for overseeing and managing the intents defined by intent owners. The role of the intent managers 506, 508 involves communication and intent handling 530 between the intent handler 410 and intent owner 420 as described above with reference to FIG. 4. Therefore, in this example the intent manager 508 may be an intent owner and the intent manager 506 may be an intent handler. Within an administrative domain, i.e. a logical or physical grouping of network resources, devices, systems, or the like, that are subjected to a common set of administrative policies, rules and management, there typically exists one intent manager registry 502. The intent manager registry 502 is configured to expose an interface for intent discovery 510 which allows for querying the intent handler registry 502 by the intent manager 506. Intent owners 420 may thus identify suitable intent handlers 410 for the intents they want to create.

[0078] The intent manager registry 502 includes a database of intent manager capability profiles 504. Information included in the profiles is related to multiple tasks within the intent lifecycle. The information may allow an intent owner 508 to identify the intent handler 506 instance that is responsible for the domain targeted by the intent it wants to set. The information may further determine what vocabulary is available in the communication with said identified intent handler 506 instance. The information may also provide information about which interface procedures for intent feasibility study and requirement negotiation would be available to use in an investigation phase of the intent lifecycle. The intent managers 506, 508 may be configured to register themselves with their intent handler profile at the intent manager registry 502. This is done through the intent registration 520 interface exposed by the intent manager registry 502. It is thus the responsibility of each intent manager 506, 508 to keep its profile information up to date. This may be needed for dynamically deployed artefacts such as policies or machine learned models for introducing or removing capabilities.

[0079] FIG. 6 is an exemplary schematic block diagram illustrating various intent manager control loops 600. The figure shows control loops between an intent manager being an intent owner 610 and an intent manager being an intent handler 620. These managers communicate through an intent interface. In this example the intent managers 610, 620 are involved in three different types of control loops. The various control loops may be (at least near) real-time enabled control loops.

[0080] The first control loop type is an intent control loop 602. This is the control loop related to the intent lifecycle and executed between two intent managers, typically the intent owner 610 and the intent handler 620. The intent control loop 602 is executed over the intent interface, and comprises two actions. The first action is definition and communication of the intent in one direction to set requirements associated with the intent (“intent”). The second action is a closure of the loop by communicating an intent fulfilment and handling state back to the origin of the intent (“intent report”).

[0081] The second control loop type is intent manager inner loops 604a, 604b. The intent managers 610, 620 are configured to dynamically check whether fulfilment objectives are satisfied, and take appropriate action accordingly. The inner loops 604, 604b are thus typically seen as assurance control loops, where the subject to be assured are related to requirements, goals and constraints defined by the intent. This means that the inner loops 604a, 604b interact with the intent control loop 602.

[0082] The third control loop type is other control loops 606a, 606b. Since the intent managers 610, 620 typically exist in an environment not fully adaptable to intent based operations, a plurality of other control loops 606a, 606b based on other interfaces than the intent interfaces may be present. The intent managers 610, 620 may participate in these loops if this is desired for purposes of assuring whether intent expectations are adhered to. The intent managers 610, 620 can thus act through action on other control loops as part of their handler or owner roles. In FIG. 7A, an example of an intent manager (handler) 704 participating in a non-intent based control loop (other control loop 606b according to FIG. 6 above) and acting through other interfaces than the intent interface. Here the intent manager 704 is acting by configuring or ordering action from another control function 706 within the domain. The control function 706 then controls a set of resources 710, where the performance of state thereof is observed through a measurement and analytics function 708. The intent manager 704 is also configured to obtain information about the system state through the measurement and analytics function 708, thereby closing the control loop (“other control loop”) from the perspective of the intent handler 704.

[0083] In FIG. 7B, another example of an intent manager 744 is shown. The intent manager 744 participates in a plurality of intent control loops 723 with intent owners 722a, 722b in the role of a handler and a plurality of control loops 733 with intent handlers 732a, 732b in the role of an owner. In addition the intent manager 744 participates in any number of other, non-intent based control loops 725, 735 with respective management functions 724a-b, 734a-b. In this case where the intent manager 744 has a dual role of handler and owner, there is still typically a single inner control loop 746. The handler role is tasked with aligning its actions with the received requirements, with actions taking on an owner role when they encompass the creation and transmission of additional intent. This convergence of concerns and loops consolidates into a unified entity being the inner control loop 746.

[0084] The O-RAN, related RICs with respective platforms (non-RT / near-RT), control applications (rApps / xApps) and the concept of intent and associated managers / control loops have now been thoroughly defined. FIGs. 8-12 will now further elaborate upon the orchestration function which was touched upon when describing the components of FIG. 1 (“orchestration function 22 / 32”). The orchestration function combines the aspects as has been described herein into an approach for orchestration of control applications in the O-RAN. The approach advantageously addresses adherence of both functional and non-functional quality attributes of control applications, while at the same time manages timing aspects (e.g. real-time aspects) associated with the computing environment. In order to do this, the orchestration function involves determining an invocation order of the control applications which is based on fulfilment objectives, provided through one or more intents, pertaining to the quality attributes.

[0085] FIG. 8 shows method 100 for orchestration of a plurality of control applications in an 0-RAN according to an exemplary flowchart diagram. A system may perform the method 100. The system may be embodied as a network apparatus. The network apparatus may be a network node. The system may include a plurality of network apparatuses and the method 100 may be performed in a distributed manner by at least two network apparatuses among the plurality of network apparatuses. At least one of the network apparatuses may be a network node. The method 100 comprises obtaining 110 at least one quality attribute for each one of a plurality of control applications, the control applications being executable on at least one RIC platform in the O-RAN. The method 100 comprises obtaining 120 at least one intent comprising fulfilment objectives for the at least one quality attribute. The method 100 comprises determining 130 an invocation order of the control applications based on values of the at least one quality attribute in relation to their corresponding fulfilment objectives. The method 100 comprises orchestrating 140 the control applications on the at least one RIC platform in the invocation order.

[0086] FIG. 9 is an exemplary flowchart diagram of a quality attribute registration 900. The quality attribute registration 900 is carried out by three computerized modules, namely the orchestration function 902, a control application 904, and a RIC platform 906. The embodiment shown in FIG. 9 relates to the obtaining 110 of the at least one quality attribute from the RIC platform 906. This procedure is carried out for purposes of enabling the orchestration function 902 to learn the quality attributes of an individual control application 904, such that quality-aware orchestration can subsequently be carried out.

[0087] The quality attribute registration 900 comprises at 912 a step of requesting registration by the control application 904 to the RIC platform 906. This step is carried out when the control application 904 is registered to the RIC platform, for example as a part of an xApp registration procedure with a near-RT RIC platform. A developer of the control application 904 desires that the control application 904 is brought to the 0-RAN ecosystem. In order to do so, the control application 904 may define a package including descriptors of functionality of the control application 904, as well as certain requirements in order for it to run on the associated RIC platform 906. The RIC platform 906 may offer a registration mechanism which specifies information that the control application 904 should submit, including e.g. metadata, authentication credentials, and other relevant information. In this step, the control application 904 submits the quality attributes pertaining to the control application 904, for example an average execution time required for executing the functionality thereof.

[0088] At 913, the RIC platform 906 is configured to receive the register inquiry from the control application 904 and carry out the registration of the control application 906. This step involves storing the quality attributes, in this example being the average execution time. At 914, the control application 906 is notified of a completed / failed registration. Some RIC platforms 906 may conduct testing and validation to ensure compliance and proper functionality. Once registered and approved, the control application 904 is deployed onto the RIC platform 906, involving e.g. configuration, role specification, and resource allocation. Ongoing monitoring and management tools may be provided to oversee the performance and behaviour of the registered control application 904. The specifics of the steps 912, 913 and 914 may vary, and adherence to documentation of the RIC platform 906 and collaboration with the development community are important for successful registration.

[0089] Now, the quality attributes associated with the control application 904 have been registered to the RIC platform 906, and the orchestration function 902 is configured to obtain the quality attributes. This can be done in response to the control application 904 being registered to the RIC platform 906, and is shown at 916 and 918. This may be done manually or at least semi-automatically. At 916, the orchestration function 902 requests a control application with certain quality attributes, in this case relating to the control application 904. At 918, the orchestration function 902 returns the requested information. In a slightly alternative method flow, the control application 904 may register its quality attributes to a database accessible by the orchestration function 22, 32. The skilled person will appreciate that the control application registration and the obtaining of quality attributes are not limited to the steps of the flowchart of FIG. 9. FIG. 10 is an exemplary flowchart diagram of a quality attribute learning 1000 procedure. This approach differs from the one shown and explained above with reference to FIG. 9 in that it requires a control application 1004 to already be registered to a RIC platform 1006 (through steps 1012, 1013, 1014 which corresponds to steps 912, 913 and 914). After that, quality attribute learning 1000 shall be understood as runtime learning procedure.

[0090] An orchestration function 1002 is configured to carry out one or more request loops involving a submission of a fake or real task at 1022 and a returnation of quality attributes at 1024. The real task corresponds to a normal operation of the orchestration function components. The fake task corresponds to a combination of a submitted job and an observation of a returned result, thereby being a check how the control application 1004 behaves without performing a real task. The orchestration function 1002 thus receives feedback from a real execution of the control application 1004. The orchestration function 1002 is thereby configured to learn an estimation of the quality attributes in near-RT by a request to an already orchestrated control application 1004, whereupon estimated quality attributes can be updated at 1025. This procedure may be carried out in run-time of the control application 1004. The frequency in which the orchestration function 1002 requests a task may depend on various factors, such as timing properties, performance requirements, or the like. If the values of the returned quality attributes have changed the update 1025 may be carried out, but if nothing has changed from the last task request iteration it may not be necessary to update the values.

[0091] In some embodiments, the learning of the estimation of the quality attributes in near-RT may be refined. This may be done by applying a temporal difference learning algorithm. The temporal difference learning algorithm may be defined according to the following formulation:

[0092] Er(x) = Er x — 1) + a[Rr x) — Er x — 1)], where Er(x) is the estimated execution time at learning step x of control application A, a G (0,1] is a learning rate parameter, Rr(x) is a response time experienced by the control application A when invoked, and Er(x-1 ) is an expected execution time calculated at a previous learning step, i.e., the summarized historical data in a value-function. The temporal difference learning method may provide information pertaining to how the control application A perform in dynamic conditions of the O- RAN, such as control applications suddenly performing badly which may be mitigated at the cost of extra monitoring and / or computing power. By way of providing such information, the orchestration function 1002 may be configured to orchestrate control applications in a time-aware approach, i.e., invoking the control applications with acceptable execution times (as for example determined by the quality attributes).

[0093] To cope with a non-stationary nature of the computing environment, the value a may be determined using different strategies. In one embodiment, the value a may be a constant value, for example a = 0.8, which makes it possible to give 80% of the estimation power of the value function to the latest experience performed. Other examples are readily envisaged of constant a values. In another embodiment, the value a may be a dynamically changing value according to a time window. The time window of refers to the specific duration during which the learning function gathers and processes data to adapt or learn. It can be predetermined based on the nature of the learning task and the desired balance between responsiveness and stability. Shorter time windows provide quick adaptations but may be sensitive to noise, while longer time windows offer more stability but may be slower to respond to changes. The determination of the time window involves considering the characteristics of the computing environment, the rate of data changes, the trade-off between adaptability and stability, and the like. In yet another embodiment, the value a may be a dynamically adjusted value in response to an incoming trigger identifying the dynamism of the computing environment. Typically, a higher a value biases the learning towards the latest observed response times of agents, and is adequate especially in highly dynamic and real-time environments.

[0094] Details of how the invocation order can be determined will now be further described with reference to the examples of FIGs. 11-12. In general, the invocation order is determined for the control applications based on values of the quality attributes in relation to their corresponding fulfilment objectives, wherein the fulfilment objectives are comprised in one or more intents as discussed herein. In one embodiment, the invocation order may be determined by selecting a sequence of control applications to be consecutively orchestrated such that each one of their quality attributes satisfy the fulfilment objectives. The orchestration function may thus work towards certain constraints (or values) as determined by the quality attributes. This may be done by providing an intelligent selection (and subsequent invocation) of control applications that have registered their quality attributes to the RIC platform. The expectations of fulfilment of an intent by the RIC platform instead of a specific control application enables the orchestration function to select the most suitable control application that can guarantee intent fulfilment in said certain constraints (or values). One way of performing such intelligent selection of control applications is shown in FIG. 11.

[0095] In the exemplary schematic illustration of FIG. 11, the selection is based on a generation of an invocation graph. The invocation graph comprises a plurality of invocation order candidates. An invocation order candidate comprises a sequence of control applications 1101 that together enforce the fulfilment objectives. By way of example, the sequence comprising the control applications 1101a, HOld, HOle and 1101g is one potential invocation order candidate. Another exemplary sequence comprises the control applications 1101c, HOld, HOlf, 1101g as a potential invocation order candidate. The skilled person will appreciate that this particular exemplary invocation graph can yield many different invocation order candidates depending on the selection of the control applications 1101. A single control application 1101 may be selected for one or more invocation order candidate. In addition, it shall be understood that this is but a non-limiting exemplary invocation graph. Other invocation graphs may include any number of nodes and / or edges in any number of layers, and the invocation order candidates may be selected in any number of ways depending on their respective quality attributes and the fulfilment objectives comprised in the one or more intents. By processing the invocation graph, the selection of the desired invocation order candidate can be carried out, thus leading to a certain invocation order to be established.

[0096] In one embodiment, processing the invocation graph may involve a combination of a graph traversal algorithm and a graph pruning algorithm. Graph traversal and pruning are, as such, concepts known to the skilled person. However, they have not been applied in the contexts of the present disclosure to determine invocation candidates according to quality attributes and intents for control application orchestration in the O- RAN. It is noted that the intelligent selection may in alternative possible implementations be carried out using other approaches not mentioned herein. Graph traversal is a computational process that involves systematically visiting and examining nodes in a graph data structure, the nodes in this case being control applications 1101. Graph traversal explores the relationships between nodes by moving from one node to another along edges, aiming to reach all nodes in the graph. There are two primary methods for graph traversal: depth-first and breadth-first. In depth-first traversal, the algorithm explores as far as possible along each branch before backtracking, while breadth-first traversal systematically explores all neighbours of a node before moving on to their neighbours. The present traversal can be carried out using any of these approaches. Graph pruning, on the other hand, is a computational process focused on systematically removing unnecessary or irrelevant nodes and edges from a graph data structure. The goal of graph pruning is to streamline the graph, reducing its size or complexity while preserving essential information. In this case, the objective of graph pruning is to filter out the non-desired invocation order candidates to end up with one or more desired invocation order candidates. This is achieved by identifying and eliminating nodes or edges that do not significantly contribute to the overall structure or desired analysis.

[0097] In embodiments of the present disclosure graph traversal and pruning are combined for determining the invocation order. Processing the invocation graph may thus involve traversing the invocation graph to determine whether each traversed control application satisfies the fulfilment objectives. During said traversal of the invocation graph, the invocation graph is pruned for determining the invocation order from among the plurality of invocation order candidates. Any known pruning algorithms may conveniently be applied for this purpose. One approach is described by the steps (a) through (e) following hereinbelow.

[0098] The first step (a) involves selecting a particular control application in a particular layer of the invocation graph, such as 1101a. The particular control application has an extremum quality attribute value compared to other control applications in the same layer, such as 1101b and 1101c. This means that the value is either a maximum value or a minimum value, depending on what quality attribute is being examined. For example, it may be desired that certain attributes are associated with higher values compared to lower values (such as a network resilience attribute), while it may be preferable for other attributes to be associated with lower values compared to higher values (such as a maximum execution time). For explanation purposes, a maximum execution time is considered in this case. Step (a) thus selects the highest maximum execution time of the control applications of the particular layer. However, a requisite in that a removal of this particular control application maintains the invocation graph as traversable is conceived. If the graph is no longer traversable, there may be a risk of disconnecting or isolating nodes, losing paths, etc., thereby potentially leading to a poor graph reachability and a loss of information. If there would be no nodes left at a particular layer, a node of a different layer would be selected, for instance based on one of a depth-first or a breadth- first approach.

[0099] Provided that the graph remains traversable, the second step (b) involves removing the particular control application from its layer, thus effectively eliminating the risk of that one being included in a preferred invocation order. In this example, if 1101a would be removed the other control applications 1101b and 1101 would be those remaining from this particular layer.

[0100] The third step (c) involves computing an aggregated value for the invocation graph, for example by accumulating all of the maximum execution time values for the control applications of that layer. In this example it would include accumulating the values of the control applications 1101b and 1101c.

[0101] The fourth step (d) is a stoppage of the pruning, which is done in response to the aggregated value being compliant with the fulfilment objectives. In this example it would include comparing the aggregated value calculated in step (c) with a value defined by a particular fulfilment objective. If the aggregated value is higher than the value defined by the particular fulfilment objective, the pruning would not stop, because it would not be compliant with the maximum allowable execution time. The pruning would thus proceed to the fifth step (e).

[0102] The steps (a) through (d) are repeated at step (e) one or more times until the aggregated value is not compliant with the fulfilment objectives. Hence, for as long as the aggregated value of one layer does not comply with the stipulated fulfilment objective comprised in the one or more intents, an additional control application is selected, provided that the removal thereof maintains the graph as traversable, the additional control application is removed, and an aggregated value of the graph is computed. By this approach, a desired invocation order candidate can be obtained and accordingly selected as the invocation order.

[0103] In some embodiments, the pruning may be further based on a learning factor from outputs of previously executed control applications. The learning factor is a probability that the quality attributes of the control applications in the invocation order fail to meet their respective fulfilment objectives. The learning factor may be a risk of a risk of non-compliance for a certain quality attribute of a control application with respect to the fulfilment objectives stipulated by the intent. The learning factor may be further based on observations on previous executions by following a certain path in the invocation graph, i.e., the risk of a certain path leading to non-compliance for certain quality attribute with respect to the fulfilment objectives stipulated by the intent. The learning factor may be further based on the lack of prior experience from observations (prior executions). This may be the case where control applications are newly introduced to a system.

[0104] In some embodiments, the learning factor as described above may be simplified. The simplification may involve dividing a number of ingoing edges (indegrees) to a particular node in the invocation graph (i.e. a particular control application) by a number of indegrees to all control applications belonging to the same layer in the invocation graph as the particular control application. The simplification may also involve removing one particular control application associated with an unsatisfiable value, for instance caused by an erroneous execution or other bugs. The simplification may thus involve removing the particular control application associated with an unsatisfiable value. Moreover, the simplification may involve a removal of one or more invocation order candidates involving this single control application with the unsatisfiable value.

[0105] In all of the embodiments explained thus far, it has been assumed that a control application is associated with one or more quality attributes. However, in some embodiments, it may be useful to calculate a weighted quality attribute by combining a plurality of quality attributes associated with a single control application. In these embodiments, the invocation order may accordingly be determined based on weighted quality attribute values of the control applications. For example, a network resilience attribute may be intrinsically connected to another attribute, such as a redundancy attribute of a network, thus indicating that a certain attribute may be multifaceted and influenced by other attributes. By calculating the weighted quality attribute, two or more values can be considered in combination, which can be useful for some areas of application and in some domains.

[0106] FIG. 12 is an exemplary flowchart diagram of a method for quality-aware orchestration of control applications based on an invocation graph. An orchestration function 1202 may be configured to fetch control applications and associated key performance indicators (including quality attributes) from a RIC platform 1206 at 1212, and receive them at 1214. Although not shown in the flowchart, it is assumed that the orchestration function 1202 has access to relevant intents before the invocation order it determined. When the invocation graph has been constructed at 1215, for instance using one of the approaches as discussed above with reference to FIG. 11, the invocation graph may be traversed and pruned according to any of the examples explained above. After traversal and pruning, the orchestration function 1202 may be configured to update the invocation graph at 1217 based on the outcome of the traversal and pruning. Accordingly, a desired invocation order has been determined. Based on the desired invocation order, the orchestration function 1202 is at 1218 configured to invoke the control applications 1204 in the order of the determined invocation order.

[0107] With reference to FIG. 13, in accordance with an embodiment, a communication system includes a telecommunication network 1310, such as a 3GPP-type cellular network, which comprises an access network 1311, such as a radio access network, and a core network 1314. The communication system may be the communication system 1 as referred to in FIG. 1. The access network 1311 comprises a plurality of base stations 1312a, 1312b, 1312c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1313a, 1313b, 1313c. Each base station 1312a, 1312b, 1312c is connectable to the core network 1314 over a wired or wireless connection 1315. A first user equipment (UE) 1391 located in coverage area 1313c is configured to wirelessly connect to, or be paged by, the corresponding base station 1312c. A second UE 1392 in coverage area 1313a is wirelessly connectable to the corresponding base station 1312a. While a plurality of UEs 1391, 1392 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1312.

[0108] The telecommunication network 1310 is itself connected to a host computer 1330, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 1330 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 1321, 1322 between the telecommunication network 1310 and the host computer 1330 may extend directly from the core network 1314 to the host computer 1330 or may go via an optional intermediate network 1320. The intermediate network 1320 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 1320, if any, may be a backbone network or the Internet; in particular, the intermediate network 1320 may comprise two or more sub-networks (not shown).

[0109] The communication system of FIG. 13 as a whole enables connectivity between one of the connected UEs 1391, 1392 and the host computer 1330. The connectivity may be described as an over-the-top (OTT) connection 1350. The host computer 1330 and the connected UEs 1391, 1392 are configured to communicate data and / or signaling via the OTT connection 1350, using the access network 1311, the core network 1314, any intermediate network 1320 and possible further infrastructure (not shown) as intermediaries. The OTT connection 1350 may be transparent in the sense that the participating communication devices through which the OTT connection 1350 passes are unaware of routing of uplink and downlink communications. For example, a base station 1312 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 1330 to be forwarded (e.g., handed over) to a connected UE 1391. Similarly, the base station 1312 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1391 towards the host computer 1330.

[0110] Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in preceding paragraphs will now be described with reference to FIG. 14. In a communication system 1400, a host computer 1410 comprises hardware 1415 including a communication interface 1416 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1400. The host computer 1410 further comprises processing circuitry 1418, which may have storage and / or processing capabilities. In particular, the processing circuitry 1418 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 1410 further comprises software 1411, which is stored in or accessible by the host computer 1410 and executable by the processing circuitry 1418. The software 1411 includes a host application 1412. The host application 1412 may be operable to provide a service to a remote user, such as a UE 1430 connecting via an OTT connection 1450 terminating at the UE 1430 and the host computer 1410. In providing the service to the remote user, the host application 1412 may provide user data which is transmitted using the OTT connection 1450.

[0111] The communication system 1400 further includes a base station 1420 provided in a telecommunication system and comprising hardware 1425 enabling it to communicate with the host computer 1410 and with the UE 1430. The hardware 1425 may include a communication interface 1426 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1400, as well as a radio interface 1427 for setting up and maintaining at least a wireless connection 1470 with a UE 1430 located in a coverage area (not shown in FIG. 14) served by the base station 1420. The communication interface 1426 may be configured to facilitate a connection 1460 to the host computer 1410. The connection 1460 may be direct or it may pass through a core network (not shown in FIG. 14) of the telecommunication system and / or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1425 of the base station 1420 further includes processing circuitry 1428, which may comprise one or more programmable processors, application- specific integrated circuits, field programmable gate arrays or combinations of these (not shown in FIG. 14) adapted to execute instructions. The base station 1420 further has software 1421 stored internally or accessible via an external connection.

[0112] The communication system 1400 further includes the UE 1430 already referred to. Its hardware 1435 may include a radio interface 1437 configured to set up and maintain a wireless connection 1470 with a base station serving a coverage area in which the UE 1430 is currently located. The hardware 1435 of the UE 1430 further includes processing circuitry 1438, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 1430 further comprises software 1431, which is stored in or accessible by the UE 1430 and executable by the processing circuitry 1438. The software 1431 includes a client application 1432. The client application 1432 may be operable to provide a service to a human or non-human user via the UE 1430, with the support of the host computer 1410. In the host computer 1410, an executing host application 1412 may communicate with the executing client application 1432 via the OTT connection 1450 terminating at the UE 1430 and the host computer 1410. In providing the service to the user, the client application 1432 may receive request data from the host application 1412 and provide user data in response to the request data. The OTT connection 1450 may transfer both the request data and the user data. The client application 1432 may interact with the user to generate the user data that it provides.

[0113] It is noted that the host computer 1410, base station 1420 and UE 1430 illustrated in FIG. 14 may be identical to the host computer 3430, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291, 3292 of FIG. 13, respectively. This is to say, the inner workings of these entities may be as shown in FIG. 14 and independently, the surrounding network topology may be that of FIG. 13.

[0114] In FIG. 14, the OTT connection 1450 has been drawn abstractly to illustrate the communication between the host computer 1410 and the use equipment 1430 via the base station 1420, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 1430 or from the service provider operating the host computer 1410, or both. While the OTT connection 1450 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

[0115] The wireless connection 1470 between the UE 1430 and the base station 1420 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 1430 using the OTT connection 1450, in which the wireless connection 1470 forms the last segment. More precisely, the teachings of these embodiments may improve the latency and thereby provide benefits such as reduced user waiting time, better responsiveness and / or extended battery lifetime.

[0116] A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1450 between the host computer 1410 and UE 1430, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection 1450 may be implemented in the software 1411 of the host computer 1410 or in the software 1431 of the UE 1430, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1450 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 1411, 1431 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1450 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 1420, and it may be unknown or imperceptible to the base station 1420. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 1410 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 1411, 1431 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1450 while it monitors propagation times, errors etc.

[0117] FIG. 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to FIGs. 13 and 14. For simplicity of the present disclosure, only drawing references to FIG. 15 will be included in this section. In a first step 1510 of the method, the host computer provides user data. In an optional substep 1511 of the first step 1510, the host computer provides the user data by executing a host application. In a second step 1520, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 1530, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 1540, the UE executes a client application associated with the host application executed by the host computer.

[0118] FIG. 16 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to FIGs. 13 and 14. For simplicity of the present disclosure, only drawing references to FIG. 16 will be included in this section. In a first step 1610 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 1620, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 1630, the UE receives the user data carried in the transmission.

[0119] FIG. 17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to FIGs. 13 and 14. For simplicity of the present disclosure, only drawing references to FIG. 17 will be included in this section. In an optional first step 1710 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 1720, the UE provides user data. In an optional substep 1721 of the second step 1720, the UE provides the user data by executing a client application. In a further optional substep 1711 of the first step 1710, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 1730, transmission of the user data to the host computer. In a fourth step 1740 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

[0120] FIG. 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to FIGs. 13 and 14. For simplicity of the present disclosure, only drawing references to FIG. 18 will be included in this section. In an optional first step 1810 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 1820, the base station initiates transmission of the received user data to the host computer. In a third step 1830, the host computer receives the user data carried in the transmission initiated by the base station.

Claims

CLAIMS1. A method (100) performed by a system for orchestration of control applications in an open radio access network, 0-RAN (10), comprising: obtaining (110) at least one quality attribute for each one of a plurality of control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312), the control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) being executable on at least one radio access network intelligent controller, RIC, platform (26, 36; 202, 210; 310, 322; 906; 1006; 1206) in the O-RAN (10); obtaining (120) at least one intent comprising fulfilment objectives for said at least one quality attribute; determining (130) an invocation order of the control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) based on values of the at least one quality attribute in relation to their corresponding fulfilment objectives; and orchestrating (140) the control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) on the at least one RIC platform (26, 36; 202, 210; 310, 322; 906; 1006; 1206) in the invocation order.

2. The method (100) of claim 1, wherein determining (130) the invocation order comprises selecting a sequence of said plurality of control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) to be consecutively orchestrated such that each of the quality attributes for the sequence of said plurality of control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) satisfy the fulfilment objectives.

3. The method (100) of claim 2, wherein the sequence of said plurality of control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) is selected by: generating an invocation graph having a plurality of invocation order candidates, wherein each invocation order candidate comprises a sequence of control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) enforcing the fulfilment objectives; and processing the invocation graph.

4. The method (100) of claim 3, wherein processing the invocation graph involves: traversing the invocation graph to determine whether each traversed control application (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) satisfies the fulfilment objectives; and during said traversal of the invocation graph, pruning the invocation graph for determining the invocation order from among the invocation order candidates.

5. The method (100) of claim 4, wherein pruning the invocation graph involves:(a) selecting a particular control application (24, 34; 220; 320; 904; 1004;1101; 1204; 1312) in a particular layer of the invocation graph having an extremum quality attribute value from among other control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) in said particular layer, provided that a removal of the particular control application (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) maintains the invocation graph as traversable;(b) removing the particular control application (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) from said particular layer;(c) computing an aggregated value for the invocation graph;(d) stopping the pruning in response to the aggregated value being compliant with the fulfilment objectives; and(e) repeating steps (a) to (d) one or more times until the aggregated value is compliant with the fulfilment objectives.

6. The method (100) of any of claims 4-5, wherein the pruning is further based on a learning factor from outputs of previously executed control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312), the learning factor being a probability that the quality attributes of the control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) in the invocation order fail to meet their respective fulfilment objectives.

7. The method (100) of any preceding claim, further comprising combining a plurality of quality attributes associated with a single control application (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) into a weighted quality attribute on which the invocation order for said single control application (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) is based.

8. The method (100) of any preceding claim, wherein the invocation order determines an order of invocation of control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) in a plurality of distributed RIC platforms (26, 36; 202, 210; 310, 322; 906; 1006; 1206).

9. The method (100) of any preceding claim, wherein the obtaining (110) of the at least one quality attribute from the RIC platform (26, 36; 202, 210; 310, 322; 906; 1006; 1206) is performed in response to a control application (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) being registered to the RIC platform (26, 36; 202, 210; 310, 322; 906; 1006; 1206).

10. The method (100) of claim 9, further comprising learning an estimation of the quality attributes in near real-time by a request to an orchestrated control application (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312).

11. The method (100) of claim 10, further comprising applying a temporal difference learning algorithm for learning the estimation of the quality attributes.

12. The method (100) of any preceding claim, wherein the fulfilment objectives are system-level threshold values specifying limits of allowed values of the respective quality attributes.

13. The method (100) of any preceding claim, wherein said at least one quality attribute is one or more of an execution time attribute, an energy consumption attribute,a resource requirement attribute, a network reliability attribute, a network availability attribute, a network resilience attribute, a jitter, a packet loss attribute, and a latency.

14. The method (100) of any preceding claim, further comprising generating an exception indicator in response to the at least one quality attribute failing to satisfy the fulfilment requirements, the exception indicator generation triggering a re-determination of the invocation order.

15. The method (100) of any preceding claim, wherein the control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) are orchestrated in the 0-RAN (10) by triggering respective invocation calls to the control applications (24, 34; 220; 320; 904; 1004; 1101; 1204; 1312) to execute on the at least one RIC platform (26, 36; 202, 210; 310, 322; 906; 1006; 1206).

16. The method (100) of any preceding claim, wherein the at least one RIC platform (26, 36; 202, 210; 310, 322; 906; 1006; 1206) is a near real-time RIC platform or a non-real-time RIC platform, the control applications (34; 220; 804; 904; 1001;1104; 1312) in the near real-time RIC platform being xApps and the control applications (24; 320; 804; 904; 1001 ; 1104; 1312) in the non-real-time platform being rApps.

17. The method (100) of any preceding claim, wherein the system is embodied as a network apparatus.

18. The method (100) of claim 17, wherein the network apparatus is a network node.

19. The method (100) of any of claims 1-16, wherein the system includes a plurality of network apparatuses and the method is performed in a distributed manner by at least two network apparatuses from among the plurality of network apparatuses.

20. The method (100) of claim 19, wherein at least one of the network apparatuses is a network node.

21. An apparatus comprising a processor configured to perform the method (100) of any of claims 1-16.

22. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method of any of claims 1-16.

23. A carrier containing the computer program of claim 22, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Images