Real-time modification of acceleration processing resources in an open-radio access network (o-ran) network

Abstract

A method implemented by a first acceleration abstraction layer, AAL, application that is configured to communicate with a second AAL application is provided. A configuration for at least one hardware acceleration resource that is assigned for use by the second AAL application is modified where the at least one hardware acceleration resource 5 is at least one resource provided by an AAL-logical processing unit, LPU.

Description

[0001] REAL-TIME MODIFICATION OF ACCELERATION PROCESSING

[0002] RESOURCES IN AN OPEN-RADIO ACCESS NETWORK (O-RAN) NETWORK

[0003] TECHNICAL FIELD

[0004] The present disclosure relates to wireless communications, and in particular, to modifying the use of hardware acceleration resources that are allocated and / or assigned to another Acceleration Abstraction Layer (AAL) Application.

[0005] BACKGROUND

[0006] The Third Generation Partnership Project (3GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and user equipment (UE), as well as communication between network nodes and between UEs. The 3 GPP is also developing standards for Sixth Generation (6G) wireless communication networks.

[0007] In particular, hardware acceleration has been used for some telecommunication layer functions. The Open-Radio Access Network (O-RAN) Alliance has been working to standardize the AAL (Acceleration Abstraction Layer) Application Program Interfaces (APIs) to support the acceleration for cloudified O-RAN functions.

[0008] In O-RAN, the AAL work aims at developing and standardizing interfaces for the use of Hardware Accelerators (HWAs) for offloading the specialized compute intensive processing from application(s) running on a General-Purpose Processor (GPP), to a Hardware Accelerator. This is referred to as hardware acceleration.

[0009] Cloudified O-RAN functions leverage instances of the hardware accelerator (HWA), or HWA Logical Processing Units (AAL-LPUs) that provide one or more AAL- LPU resources to offer the required enhanced performance capabilities to the cloudified network functions (NFs). From an AAL perspective, an NF is considered an AAL Application, and is defined as a workload that can offload certain functions to the AAL- LPU(s), for acceleration.

[0010] Examples of O-RAN defined NFs that may leverage Hardware Acceleration include the Centralized Unit or CU, or a Distributed Unit or DU. FIG. 1 is a diagram illustrating an example of the O-RAN AAL high level architecture. Different types of accelerations may be used by the AAL Application, and this is provided by the AAL-LPUs, where each type of acceleration can be described as an acceleration profile (AAL Profile). Examples of such acceleration profiles include Forward Error Correction (FEC) or High-PHY for the High part of the layer 1 (LI) Physical layer of the protocol stack. The AAL Application will use a specific acceleration profile instance supported by the AAL-LPU, and this is known in O-RAN AAL as an AALProfi lelnstance.

[0011] An AAL Application can make modifications to the characteristics, configuration and state of a given AALProfilelnstance that the AAL Application is using thorough the use of: the AALLC-App, via APIs such as setAalProfilelnstanceConfig , startAalProfilelnstance or stopAalProfilelnstance , or the AALLP API for profile specific characteristics and operations.

[0012] There are mechanisms defined in O-RAN that aim to enable the modification or reconfiguration of a given O-RAN NF. An example of such mechanisms may include, per the control loops:

[0013] Control loops, which operate 1 second or more, based on mechanisms hosted in the SMO;

[0014] Non-RT (Real Time) control loops, which operate control loops which are 10 milliseconds or more via non-Real-Time RAN Intelligent Controller Application, rAPP; and

[0015] RT (Real Time) control loops, which look operate controls loops which less than 10 milliseconds, via near Real-Time RAN Intelligent Controller Application, xAPP.

[0016] FIG. 2 is another diagram of an example O-RAN AAL high level architecture.

[0017] Similarly, mechanism have been specified in AAL for the Hardware Accelerator Manager (HAM) to set the configuration of AAL-LPUs via API as part of the AALI-C- mgmt.

[0018] However, the current O-RAN AAL specifications, procedures and APIs assume only a single AAL Application manages a set of AAL-LPU resources assigned to the AAL Application at a time. That is, current O-RAN AAL specifications, procedures and APIs disadvantageously limit an AAL-LPU to be used by at most one AAL Application and only that AAL Application can control the AAL Profile Instance resources executing on the AAL-LPU. SUMMARY

[0019] Some embodiments advantageously provide methods, systems, and apparatuses for modifying the use of hardware acceleration resources (i.e., AAL LPU resources) that are allocated and / or assigned to another AAL Application.

[0020] Existing O-RAN AAL specifications, procedures and APIs assume only a single AAL Application may manage a set of AAL-LPU resources provided by an AAL-LPU assigned to the AAL Application at a time.

[0021] There are currently no solutions or mechanisms specified within O-RAN to enable the ability in real-time for a given deployed cloudified application, i.e., an AAL Application whether it is an NF or not, to: enable a cloudified AAL Application to modify the use and configuration of the AAL-LPU resources (AALProfilelnstance) being used by another AAL Application; or enable from an rApp or from an xApp to modify the configuration and characteristics of the use of AAL-LPU resources (AALProfilelnstance) that have been assigned and are used by another AAL Application; or enable the SMO or the HAM to modify the configuration and characteristics of the use of AAL-LPU resources (AALProfilelnstance) that are used by another AAL Application; or enable the SMO to modify AAL-LPU resources used by a cloudified AAL Application.

[0022] Such capabilities are required to support various use cases.

[0023] One or more embodiments described herein solve at least one problem with existing O-RAN AAL specifications, procedures and APIs. One or more embodiments described herein provide mechanisms and extensions to the O-RAN AAL specifications, procedures, and APIs to enable the control, modification, addition or deletion of the use of AAL-LPU resources (e.g., hardware acceleration resources) by a cloudified AAL Application. One or more embodiments may be applied to, for example, rApps and network orchestration applications that can be developed to control and modify the use of AAL-LPU resources to address a wide range of use cases.

[0024] According to one aspect of the present disclosure, a method implemented by a first acceleration abstraction layer, AAL, application that is configured to communicate with a second AAL application is provided. A configuration for at least one hardware acceleration resource that is assigned for use by the second AAL application is modified where the at least one hardware acceleration resource is at least one resource provided by an AAL-logical processing unit, LPU.

[0025] According to one or more embodiments of this aspect, the modifying of the configuration for the at least one hardware acceleration resource comprises one of: releasing the at least one hardware acceleration resource that has been allocated for use by the second AAL application; adding at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the second AAL application, the at least one additional hardware acceleration resource being provided by the AAL-LPU; or changing usage of the at least one hardware acceleration resource.

[0026] According to one or more embodiments of this aspect, the second AAL application provides one of: at least one network node-distributed unit, DU, function; or at least one network node-centralized unit, CU, function

[0027] According to one or more embodiments of this aspect, a request is transmitted to the AAL-LPU to register the first AAL application with the AAL-LPU so that the first AAL application receives responses to Application Program Interface, API, requests processed by the AAL-LPU.

[0028] According to one or more embodiments of this aspect, a response to the request is received where the response indicates a plurality of AAL profile instances created on the AAL-LPU.

[0029] According to one or more embodiments of this aspect, the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

[0030] According to one or more embodiments of this aspect, the first AAL application is one of: a non-Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

[0031] According to one or more embodiments of this aspect, the second AAL application is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned to the second AAL application to enhance performance.

[0032] According to another aspect of the present disclose, a first acceleration abstraction layer, AAL, application that is configured to communicate with a second AAL application is provided. The first AAL application is configured to modify a configuration for at least one hardware acceleration resource that is assigned for use by the second AAL application, where the at least one hardware acceleration resource is at least one resource provided by an AAL-logical processing unit, LPU.

[0033] According to one or more embodiments of this aspect, the modifying of the configuration for the at least one hardware acceleration resource comprises one of: release the at least one hardware acceleration resource that has been allocated for use by the second AAL application; add at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the second AAL application, the at least one additional hardware acceleration resource being provided by the AAL-LPU; or change usage of the at least one hardware acceleration resource.

[0034] According to one or more embodiments of this aspect, the second AAL application provides one of: at least one network node-distributed unit, DU, function; or at least one network node-centralized unit, CU, function.

[0035] According to one or more embodiments of this aspect, the first AAL application is further configured to transmit a request to the AAL-LPU to register the first AAL application with the AAL-LPU so that the first AAL application receives responses to Application Program Interface, API, requests processed by the AAL-LPU.

[0036] According to one or more embodiments of this aspect, the first AAL application is further configured to receive a response to the request, where the response indicates a plurality of AAL profile instances created on the AAL-LPU.

[0037] According to one or more embodiments of this aspect, the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

[0038] According to one or more embodiments of this aspect, the first AAL application is one of: a non-Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

[0039] According to one or more embodiments of this aspect, the second AAL application is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned to the second AAL application to enhance performance.

[0040] According to another aspect of the present disclosure, a method implemented by a modifier application that is configured to communicate with an acceleration abstraction layer, AAL, application is provided. A configuration for at least one hardware acceleration resource that is assigned for use by the AAL application is modified where the at least one hardware acceleration resource is at least one resource provided by an AAL-logical processing unit, LPU.

[0041] According to one or more embodiments of this aspect, the modifying of the configuration for the at least one hardware acceleration resource comprises one of: releasing the at least one hardware acceleration resource that has been allocated for use by the AAL application; adding at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the AAL application, the at least one additional hardware acceleration resource being provided by the AAL-LPU; or changing usage of the at least one hardware acceleration resource.

[0042] According to one or more embodiments of this aspect, a request for AAL-LPU information is signaled to the AAL application, where the request is configured to implicitly register the modifier application with the AAL-LPU; a response to the request is received from the AAL application, where the response comprises information associated with AAL profile instances associated with the AAL-LPU, and the modifying of the configuration is based on the information in the response.

[0043] According to one or more embodiments of this aspect, the information comprises at least one of: a plurality of AAL profile instance identifiers; AAL profile instance configuration; or AAL profile instance state of at least one AAL profile instance created on the AAL-LPU.

[0044] According to one or more embodiments of this aspect, the AAL application provides one of: at least one network node-distributed unit, DU, function; or at least one network node-centralized unit, CU, function.

[0045] According to one or more embodiments of this aspect, a request to the AAL-LPU is transmitted via the AAL Application, where the request is configured to register the modifier application with the AAL-LPU so that the modifier application receives responses to API requests processed by the AAL-LPU.

[0046] According to one or more embodiments of this aspect, the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

[0047] According to one or more embodiments of this aspect, the AAL application is one of: a non-Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

[0048] According to one or more embodiments of this aspect, the AAL application is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned to the AAL application to enhance performance.

[0049] According to another aspect of the present disclosure, a modifier application that is configured to communicate with an acceleration abstraction layer, AAL, application is provided. The modifier application is configured to: modify a configuration for at least one hardware acceleration resource that is assigned for use by the AAL application, where the at least one hardware acceleration resource is at least one resource provided by an AAL-logical processing unit, LPU.

[0050] According to one or more embodiments of this aspect, the modifying of the configuration for the at least one hardware acceleration resource comprises one of: release the at least one hardware acceleration resource that has been allocated for use by the AAL application; add at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the AAL application, the at least one additional hardware acceleration resource being provided by the AAL-LPU; or change usage of the at least one hardware acceleration resource.

[0051] According to one or more embodiments of this aspect, the modifier application is further configured to: signal, to the AAL application, a request for AAL-LPU information, the request configured to implicitly register the modifier application with the AAL-LPU; receive, from the AAL application, a response to the request where the response comprises information associated with AAL profile instances associated with the AAL-LPU; and the modifying of the configuration being based on the information in the response.

[0052] According to one or more embodiments of this aspect, the information comprises at least one of: a plurality of AAL profile instance identifiers, AAL profile instance configuration, or AAL profile instance state of at least one AAL profile instance created on the AAL-LPU.

[0053] According to one or more embodiments of this aspect, the AAL application provides one of: at least one network node-distributed unit, DU, function; or at least one network node-centralized unit, CU, function.

[0054] According to one or more embodiments of this aspect, the modifier application is further configured to transmit, via the AAL application, a request to the AAL-LPU, where the request is configured to register the modifier application with the AAL-LPU so that the modifier application receives responses to API requests processed by the AAL-LPU.

[0055] According to one or more embodiments of this aspect, the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

[0056] According to one or more embodiments of this aspect, the AAL application is one of: a non-Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

[0057] According to one or more embodiments of this aspect, the AAL application is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned to the AAL application to enhance performance.

[0058] BRIEF DESCRIPTION OF THE DRAWINGS

[0059] A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

[0060] FIG. 1 is a diagram of an example 0-RAN AAL high level architecture;

[0061] FIG. 2 is a diagram of another example 0-RAN AAL high level architecture;

[0062] FIG. 3 is a diagram of an example 0-RAN AAL-LPU resources assigned to an AAL application;

[0063] FIG. 4 is a schematic diagram of an example AAL system;

[0064] FIG. 5 is a schematic diagram of an example network architecture illustrating a communication system according to principles disclosed herein;

[0065] FIG. 6 is a block diagram of an example modifier node according to some embodiments of the present disclosure;

[0066] FIG. 7 is a block diagram of an example peer AAL node according to some embodiments of the present disclosure;

[0067] FIG. 8 is a flowchart of an example process in a peer AAL node according to some embodiments of the present disclosure;

[0068] FIG. 9 is a flowchart of an example process in a modifier node according to some embodiments of the present disclosure; FIG. 10 is a diagram of an example showing peer A AL Applications where the AAL-LPU resources are directly connected to two peer A AL Applications;

[0069] FIG. 11 is a diagram of an example showing a modifier application managing AAL-LPU resources through an A AL Application;

[0070] FIG. 12 is a diagram of a relationship of modifier and peer applications to AAL- LPU resources and A AL Applications;

[0071] FIG. 13 is an example Peer AAL Application message sequence chart that shows an example of a message flow between an AAL Application, a Peer AAL Application and an AAL-LPU;

[0072] FIGs. 14-15 are a diagram of an example Modifier Application message sequence chart that shows an example of a message flow between an AAL Application, a Modifier Application and an AAL-LPU;

[0073] FIG. 16 is an example diagram of extensions to O-RAN APIs for the case of a Peer AAL Application, according to some embodiments of the present disclosure;

[0074] FIG. 17 is an example diagram of extensions to O-RAN APIs for the case of a Modifier Application, according to some embodiments of the present disclosure; and

[0075] FIG. 18 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.

[0076] DETAILED DESCRIPTION

[0077] However, there are use cases being explored by network operators that cannot be addressed using the current set of AAL procedures and APIs. These use cases require flexible and distributed management and control of the AAL resources used by AAL Applications, such as rApps, xApps, the SMO or HAM, and their ability to modify in real time the AAL-LPU resources (i.e., hardware accelerator resources) being used by another AAL Application.

[0078] The O-RAN AAL specifications, procedures and APIs currently limit that an AAL-LPU is used by at most one AAL Application and only that AAL Application can control the AAL Profile Instance resources executing on the AAL-LPU.

[0079] FIG. 3 is a diagram of an example of O-RAN AAL-LPU resources assigned to a single AAL Application.

[0080] An AAL application may use 1 or many AAL-LPUs. An AAL-LPU can be assigned to and / or used by at most one AAL application. There are several use cases where, once an O-RAN cloudified NF has been instantiated, there may be circumstances where there is a need to modify the current use of acceleration capabilities by the NF. Examples of such use cases include but are not limited to:

[0081] • energy savings, for instance, determining when to discontinue the use of higher- energy consuming AAL-LPU resources to generate energy savings during low traffic scenarios;

[0082] • interference management, for instance to reduce, control or mitigate the extent of interference temporarily that may be generated from one site to a given site to enable a better traffic conditions;

[0083] • radio performance improvements, for instance to temporarily improve radio conditions on a site to accommodate more demanding traffic; and / or

[0084] • Radar detection / incumbent detection / radio jammer detection, etc.

[0085] For instance, in the case of energy savings, the need may arise where, because of current low traffic conditions such as at night, there is temporarily no need for acceleration, and hence for the purpose of lowering energy consumption and generating energy savings at the site, the use of the acceleration capabilities (i.e., AAL-LPU resources) is not warranted and should be temporarily discontinued.

[0086] However, there are currently no solutions or mechanisms specified to include the ability by a given deployed cloudified application such as but not limited to an O-RAN NF to: modify the configuration and use of AAL-LPU resources of a given AALProfilelnstance used by a deployed AAL Application by another AAL Application, such as an rApp, an xApp, the SMO, a HAM or a Modifier Application.

[0087] The instant application solves at least one problem associated with existing systems by modifying the use of AAL-LPU resources that are allocated and / or assigned to another AAL Application.

[0088] Before describing in detail exemplary embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to modifying the use of hardware acceleration resources (i.e., AAL-LPU resources) that are allocated and / or assigned to another AAL Application. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0089] As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0090] In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

[0091] In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and / or wireless connections.

[0092] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0093] The term “network node” used herein can be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multistandard radio (MSR) radio node such as MSR BS, multi-cell / multicast coordination entity (MCE), relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), etc. The network node may also comprise test equipment. The term “radio node” used herein may be used to also denote a user equipment (UE) such as a wireless device (WD) or a radio network node.

[0094] In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The UE herein can be any type of wireless device capable of communicating with a network node or another UE over radio signals, such as a wireless device (WD). The UE may also be a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), low-cost and / or low-complexity UE, a sensor equipped with UE, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device etc.

[0095] Also, in some embodiments the generic term “radio network node” is used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell / multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH).

[0096] Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and / or New Radio (NR), may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure. Note further, that functions described herein as being performed by a user equipment or a network node may be distributed over a plurality of user equipments and / or network nodes. In other words, it is contemplated that the functions of the network node and user equipment described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

[0097] Further, as used herein, an AAL-LPU provides at least one AAL-LPU resource that may interchangeably be referred to as one or more of hardware acceleration resource, HWA resource and AAL resource.

[0098] Also, as used herein, Distributed Unit (DU) may refer to an Open DU (O-DU) that is used within the context of O-RAN deployments.

[0099] Also, as used herein, Centralized Unit (CU) may refer to an Open CU (O-CU) that is used within the context of O-RAN deployments.

[0100] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0101] Some embodiments are directed to modifying the use of hardware acceleration resources that are allocated and / or assigned to another AAL Application.

[0102] Referring again to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in FIG. 4 a schematic diagram of an example AAL system 1 , according to an embodiment, such as an O-RAN AAL based system. The AAL system 1 comprises one or more AAL Applications 2 (collectively referred to as AAL Application 2) that are communication with one or more AAL-LPUs 4 (collectively referred to as AAL-LPU 4). AAL Application 2 and AAL-LPU 4 may be similar to like elements illustrated in FIG. 2. System 1 further comprises modifier node 6 in communication with AAL Application 2 via one or more interfaces, as described herein. Modifier node 7 includes modifier application 7 that is configured to modify the use of AAL-LPU 4 resources that are allocated and / or assigned to another AAL Application 2, as described herein.

[0103] System 1 further comprises Peer AAL Node 8 that is in communication with AAL- LPU 4 via one or more interfaces, as described herein. Peer AAL Node 8 includes Peer AAL Application 9 that is configured to modify the use of AAL-LPU 4 resources that are allocated and / or assigned to another AAL Application 2, as described herein.

[0104] FIG. 5 is an example schematic diagram of a communication system 10, according to an embodiment, such as a 3GPP-type cellular network that may support standards such as LTE and / or NR (5G), where one or more elements of the communication system 10 are able to off-load one or more network functions to AAL network 15 (e.g., cloudified AAL Applications and resources). In particular, system 10 comprises an access network 12, such as a radio access network, and a core network 14. The access network 12 comprises a plurality of network nodes 16a, 16b, 16c (referred to collectively as network nodes 16), such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 18a, 18b, 18c (referred to collectively as coverage areas 18). Each network node 16a, 16b, 16c is connectable to the core network 14 over a wired or wireless connection 20. A first user equipment (UE) 22a located in coverage area 18a is configured to wirelessly connect to, or be paged by, the corresponding network node 16a. A second UE 22b in coverage area 18b is wirelessly connectable to the corresponding network node 16b. While a plurality of UEs 22a, 22b (collectively referred to as user equipments 22) 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 network node 16. Note that although only two UEs 22 and three network nodes 16 are shown for convenience, the communication system may include many more UEs 22 and network nodes 16.

[0105] Also, it is contemplated that a UE 22 can be in simultaneous communication and / or configured to separately communicate with more than one network node 16 and more than one type of network node 16. For example, a UE 22 can have dual connectivity with a network node 16 that supports LTE and the same or a different network node 16 that supports NR. As an example, UE 22 can be in communication with an eNB for LTE / E-UTRAN and a gNB for NR / NG-RAN.

[0106] Further, AAL network 15 may include modifier node 6 and peer AAL node 8, which are described above.

[0107] For example, modifier node 6 is configured to include a modifier application 7 which is configured to modify the use of AAL-LPU 4 resources (i.e., hardware acceleration resources) that are allocated and / or assigned to another AAL application, as described herein. Peer AAL node 8 is configured to include a peer AAL application 9 which is configured to modify the use of AAL-LPU 4 resources that are allocated and / or assigned to another AAL application, as described herein.

[0108] Example implementations, in accordance with an embodiment, of the modifier node 6 and peer AAL node 8 discussed in the preceding paragraphs will now be described with reference to FIGS. 6 and 7.

[0109] Referring to FIG. 6, modifier node 6 includes hardware 28. The hardware 28 may include one or more communication interfaces 30 for communicating with one or more entities such as with, for example, AAL application 2.

[0110] In the embodiment shown, the hardware 28 of modifier node 6 further includes processing circuitry 36. The processing circuitry 36 may include a processor 38 and a memory 40. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 36 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 38 may be configured to access (e.g., write to and / or read from) the memory 40, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0111] Thus, modifier node 6 further has software 42 stored internally in, for example, memory 40, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by modifier node 6 via an external connection. The software 42 may be executable by the processing circuitry 36. The processing circuitry 36 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by modifier node 6. Processor 38 corresponds to one or more processors 38 for performing modifier node 6 16 functions described herein. The memory 40 is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 42 may include instructions that, when executed by the processor 38 and / or processing circuitry 36, causes the processor 38 and / or processing circuitry 36 to perform the processes described herein with respect to modifier node 6. For example, processing circuitry 36 of modifier node 6 may include modifier application 7 which is configured to modify the use of AAL-LPU 4 resources that are allocated and / or assigned to another AAL application 2, as described herein. FIG. 7 is a block diagram of an example peer A AL node 8, according to some embodiments of the present disclosure. Peer AAL node 8 may have hardware 44 that may include one or more communication interfaces 46 for communicating with one or more entities such as with, for example, AAL LPU 4.

[0112] The hardware 44 of the peer AAL node 8 further includes processing circuitry 50. The processing circuitry 50 may include a processor 52 and memory 54. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 50 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 52 may be configured to access (e.g., write to and / or read from) memory 54, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0113] Thus, peer AAL node 8 may further comprise software 56, which is stored in, for example, memory 54 of peer AAL node 8, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by peer AAL node 8. The software 56 may be executable by the processing circuitry 50.

[0114] The processing circuitry 50 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by peer AAL node 8. The processor 52 corresponds to one or more processors 52 for performing peer AAL node 8 functions described herein. Peer AAL node 8 includes memory 54 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 56 may include instructions that, when executed by the processor 52 and / or processing circuitry 50, causes the processor 52 and / or processing circuitry 50 to perform the processes described herein with respect to peer AAL node 8. For example, the processing circuitry 50 of peer AAL node 8 may include peer AAL application 9 modify the use of AAL-LPU 4 resources that are allocated and / or assigned to another AAL application 2, as described herein.

[0115] Although FIGS. 4-7 show various “Applications” (e.g., units) such as modifier application 7 and peer AAL application 9 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry.

[0116] FIG. 8 is a flowchart of an example process in a peer AAL node 8 (e.g., first AAL application) according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of peer AAL node 8 such as by one or more of processing circuitry 50 (including peer AAL application 9), processor 52, and / or communication interface 46. Peer AAL Application 9 (i.e., first AAL Application) is configured to modify (Block S100) a configuration for at least one hardware acceleration resource that is assigned for use by the second AAL application 2 where the at least one hardware acceleration resource being at least one resource provided by an AAL-logical processing unit, LPU 4, as described herein.

[0117] According to one or more embodiments, the modifying of the configuration for the at least one hardware acceleration resource comprises one of: release the at least one hardware acceleration resource that has been allocated for use by the second AAL application 2; add at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the second AAL application 2, the at least one additional hardware acceleration resource being provided by the AAL-LPU 4; or change usage of the at least one hardware acceleration resource.

[0118] According to one or more embodiments, the second AAL application 2 provides one of: at least one network node-distributed unit, DU, function; or at least one network node-centralized unit, CU, function

[0119] According to one or more embodiments, the first AAL application is further configured to transmit a request to the AAL-LPU 4 to register the first AAL application with the AAL-LPU 4 so that the first AAL application receives responses to Application Program Interface, API, requests processed by the AAL-LPU 4.

[0120] According to one or more embodiments, the first AAL application is further configured to receive a response to the request, the response indicating a plurality of AAL profile instances created on the AAL-LPU 4.

[0121] According to one or more embodiments, the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

[0122] According to one or more embodiments, the first AAL application is one of: a non- Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

[0123] According to one or more embodiments, the second A AL application 2 is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned (e.g., offloaded) to the second AAL application 2 to enhance performance.

[0124] FIG. 9 is a flowchart of an example process in a modifier node 6 according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of modifier node 6 such as by one or more of processing circuitry 36 (including modifier application 7), processor 38, and / or communication interface 30. Modifier Application 7 is configured to modify (Block SI 02) a configuration for at least one hardware acceleration resource that is assigned for use by the AAL application 2, the at least one hardware acceleration resource is at least one resource provided by an AAL-LPU 4, as described herein.

[0125] According to one or more embodiments, the modifying of the configuration for the at least one hardware acceleration resource comprises one of: release the at least one hardware acceleration resource that has been allocated for use by the AAL application 2; add at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the AAL application 2, where the at least one additional hardware acceleration resource is provided by the AAL-LPU 4; or change usage of the at least one hardware acceleration resource.

[0126] According to one or more embodiments, the modifier application 7 is further configured to: signal, to the AAL application 2, a request for AAL-LPU information, the request configured to implicitly register the modifier application with the AAL-LPU 4; receive, from the AAL application 2, a response to the request, the response comprising information associated with AAL profile instances associated with the AAL-LPU 4; and the modifying of the configuration being based on the information in the response.

[0127] According to one or more embodiments, the information comprises at least one of: a plurality of AAL profile instance identifiers; AAL profile instance configuration; or AAL profile instance state of at least one AAL profile instance created on the AAL-LPU 4.

[0128] According to one or more embodiments, the AAL application 2 provides one of: at least one network node-distributed unit, DU, function; or at least one network nodecentralized unit, CU, function. According to one or more embodiments, the modifier application 7 is further configured to transmit, via the AAL application 2, a request to the AAL-LPU 4, the request being configured to register the modifier application 7 with the AAL-LPU 4 so that the modifier application 7 receives responses to API requests processed by the AAL- LPU 4.

[0129] According to one or more embodiments, the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

[0130] According to one or more embodiments, the AAL application 2 is one of: a non- Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

[0131] According to one or more embodiments, the AAL application 2 is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned (e.g., offloaded) to the AAL application 2 to enchance performance.

[0132] Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for modifying the use of AAL-LPU 4 resources (i.e., hardware acceleration resources) that are allocated and / or assigned to another AAL Application.

[0133] Some embodiments provide modifying the use of AAL-LPU 4 resources that are allocated and / or assigned to another AAL Application. One or more modifier node 6 functions described below may be performed by one or more of processing circuitry 36, processor 38, modifier application 7, communication interface 30, etc. One or more peer AAL node 8 functions described below may be performed by one or more of processing circuitry 50, processor 52, peer AAL application 9, communication interface 46, etc.

[0134] One or more embodiments described herein may applies at least to:

[0135] 0-RAN defined NFs which are using hardware acceleration; and / or any other cloudified application which leverages the AAL layer to take advantage of hardware acceleration capabilities.

[0136] An AAL application may be any Cloudified Application. Examples include but are not limited to rApps, xApps, the SMO, a HAM, 0-RAN NFs, RAN management functions, etc. Two example methods, according to one or more embodiments, are described as follows:

[0137] 1. Defining new AAL specifications, procedures, and APIs to enable multiple, independent AAL applications 9 to directly control and modify the AAL-LPU 4 resources used by other AAL applications 2 and exposed by a common AAL-LPU 4 over the AALI-P and AALI-C-App interfaces. This deployment method is referred to as the “Peer AAL Application” method where the AAL application 9 that controls AAL-LPU 4 resources used by other AAL Application(s) 2 is referred to as a “Peer AAL Application,” i.e., peer AAL application 9. There could be more than one peer AAL application 9 looking to modify the AAL-LPU 4 resources used by a third AAL application 2 (e.g., an O-DU). One example would be the case when several rApps are leveraged to optimize the behavior of the use of acceleration by an O-DU under different operating or traffic conditions.

[0138] FIG. 10 is a diagram of an example showing peer AAL Applications 9 where the AAL-LPU 4 resources are directly connected to two peer AAL applications 9.

[0139] 2. Defining new AAL specifications, procedures, and APIs to enable an AAL application to indirectly control and modify the AAL-LPU 4 resources exposed by an AAL-LPU 4 through an intermediate AAL application 2. This deployment method may be referred to as the “Modifier Application” method, where the AAL application that indirectly controls / modifies the AAL-LPU 4 resources is referred to as a “Modifier Application.” As in the case of the peer AAL application 9, more than one modifier application 7 may be used to modify the AAL-LPU 4 used by a third AAL application 2 (e.g., an O-DU).

[0140] FIG. 11 is a diagram of an example showing a modifier application 7 managing AAL-LPU 4 resources through an AAL Application 2.

[0141] A modifier application 7 may itself be modified by a third modifier application 7. Similarly, a modified AAL Application 2 can be modified by more than one AAL application (e.g., peer AAL application 9) or modifier applications 7. For example, an AAL application 2 can have its configuration modified or changed by one or more AAL applications where the modified configuration changes AAL application’s 2 usage of AAL-LPU 4 resource. The modification of AAL Application’s 2 configuration may correspond to modifying AAL Application 2.

[0142] FIG. 12 is a diagram of an example relationship of modifier application 7 and peer AAL application 9 to AAL-LPU 4 resources and AAL applications. In one or more embodiments, procedures and APIs may be described using the following non-limiting examples:

[0143] For the case of rApps seeking to modify in real-time the use of AAL-LPU 4 resources used by an AAL application 2: o If the rApp is considered an AAL application, then it is referred to as a peer AAL application 9. o If the rApp is not considered an AAL application, then it is referred to as a modifier application 7 and it leverages an AAL application 2 as a proxy and associated with the rApp. An rApp may not be considered an AAL application if, for example, the rApp is not an O-RAN cloudified network function.

[0144] For the case of xApps are looking to modify the use of AAL-LPU 4 resources used by an AAL application 2: o If the xApp is considered an AAL application, then it is referred to a peer AAL application 9. o If the xApp is not considered an AAL application, then it is referred to as a modifier application 7 and it leverages an AAL application 2 as a proxy and associated with the xApp.

[0145] For the case of the SMO looking to modify the use of AAL-LPU 4 resources used by an AAL application 2, the SMO is considered a modifier application 7. o In one or more embodiments, the SMO may not be a peer AAL application 9 since, for example, SMO is not required to be deployed in an O-Cloud and is not a network function.

[0146] For the case of the HAM looking to modify the use of AAL-LPU 4 resources used by an AAL application 2, the HAM is considered a modifier application 7.

[0147] One or more embodiments described herein provide new extensions to the AAL procedures and AALLC-App interface and includes the ability for a cloudified application to modify the AAL-LPU 4 resources (the AalProfilelnstances on the AAL LPUs 4) used by a different AAL application 2.

[0148] Procedures and API changes for both Peer AAL Application 9 and Modifier Application 7 methods

[0149] Any application can initialize the AAL implementation, (e.g., call “init” of AAL). (If the AAL is already initialized it has no effect). All applications may call init, only the first call will actually initialize the accelerator resources and state maintained by the AAL Implementation.

[0150] Any application can free the AAL-LPU 4 resources which allows the AAL implementation to release any internal resources that the AAL implementation has allocated during initialization procedures, (e.g., call cleanup API), in which case AAL sends a response to all connected applications that the AAL-LPU 4 resources are being cleaned up and destroyed.

[0151] Continuing to refer to FIG. 12, this figure summarizes the architecture and interface extensions proposed using the O-RAN APIs as a reference.

[0152] Initialization and registration

[0153] The first signalling from a peer AAL application 9 to an AAL-LPU 4 can be the initAal request or the getAalLpuInfo request. The receipt of an initAal or getAalLpuInfo request implicitly registers the peer AAL application 9 with the AAL-LPU 4. A registered AAL Application receives the responses to all API requests processed by the AAL-LPU 4.

[0154] A peer AAL application 9 may send a de -registration signal or notification to the AAL-LPU 4 which indicates that the peer AAL application 9 is no longer connected to the AAL-LPU 4.

[0155] Obtaining information from AAL

[0156] The first signalling from a modifier application 7 to an AAL application 2 is to request the AAL-LPU information, e.g., using the getAalLpuInfo API or a new getAalLpuInfo parameter in the 01 Read Managed Object Instance Attributes signal. The receipt of a getAalLpuInfo request or 01 getAalLpuInfo parameter implicitly registers the modifier application 7 with the AAL-LPU 4.

[0157] The getAalLpuInfo API from either a peer AAL application 9 or modifier application 7 includes the AAL-LPU identifier.

[0158] The response output information of the getAalLpuInfo API or 01 getAalLpuInfo response includes a new parameter that conveys a list of AalProfilelnstances which includes one or more of the AAL Profile Instance identifiers, AAL Profile Instance configuration and AAL Profile Instance state of each created AALProfilelnstance on the AAL-LPU 4. This parameter is included in all getAalLpuInfo responses or 01 Read Managed Object Instance Attributes responses. If there are no created AALProfilelnstance on the AAL-LPU 4, the parameter is included with an empty list in the response.

[0159] Modifying the use of AAL-LPU 4 resources AAL-LPUs 4 may receive configuration or operational requests from any registered AAL Applications 2 or AAL Applications 2 that have initialized the AAL Implementation. Indirectly, the AAL-LPUs 4 may receive requests originated by a modifier application 7 through its associated AAL application 2.

[0160] AAL-LPUs 4 sends responses to requests to the initiator of the request and any other AAL application 2 from which it has received an initialize initAal request or a getAalLpuInfo request (and not received a de -registration notification), i.e., the responses to requests are broadcast to all registered AAL applications 2.

[0161] If a getAalLpuInfo is received by an AAL application 2 from a modifier application 7 before the AAL application 2 has successfully issued the initAal API, the AAL application 2 may either initiate the initAal API procedure and then process the getAalLpuInfo API or the AAL application 2 may return an error in the getAalLpuInfo response indicating that the AAL application 2 is not connected to the AAL-LPU 4.

[0162] Mechanisms to obtain the identifiers for the AAL-LPU 4 and Profile Instances

[0163] Various procedures are described herein for obtaining the identifiers of the AAL- LPU 4 and AalProfilelnstances to establish connectivity with them:

[0164] Modifier applications 7 and / or peer AAL applications 9 may query the IMS to obtain the specific identities of the AAL-LPUs 4 and AalProfilelnstances of the AAL-LPU 4 resources that it is intending to control.

[0165] Alternatively, modifier applications 7 and / or peer AAL applications 9 may query the peer AAL application 9 or primary AAL application 2 to obtain the specific identities of the AAL-LPUs 4 and AalProfilelnstances of the AAL-LPU 4 resources that it is intending to control.

[0166] Example Message Sequence Charts

[0167] FIG. 13 is an example peer AAL application 9 message sequence chart that shows an example of a message flow between primary AAL application (e.g., AAL application 2), a peer AAL application 9 and an AAL-LPU 4. The example uses AAL APIs, but other signaling messages may be used, e.g., extensions to the E2 Service Model.

[0168] In this example, the primary AAL application 2 could be an O-DU NF and the peer AAL application 9 could be an xApp.

[0169] The peer AAL application 9 “registers” with the AAL-LPU 4 using the getAalLpuInfo Request. In this example, the peer AAL application 9 stops the profile instance that was created and started by the primary AAL application 2 and the AAL-LPU 4 notifies the primary AAL application 2 of the profile instance state change. Further, at step 4, the getAalLpulinfo may include a profile instance list, e.g., new parameter. Also, with respect to steps 6-8, the create and start responses may only go to the primary AAL Application 2 since the peer AAL application 9 is not yet known. Also, at step 9, the peer AAL application 9 “registers” with AAL-LPU 4 by calling getAalLpuInfo where, in some embodiments, the getAalLpuInfo API must be the peer AAL application 9’s first or initial API call. At step 10, becuase the primary AAL application 2 created (and started) a profile instance, it’s Id, state, configuration is returned in the response to the peer AAL application 9. At step 11, the peer AAL application 9 changes the profile instance state. At step 13, the AAL-LPU 4 also sends a response to the primary AAL application 2 where, in some embodiments, AAL-LPU 4 sends responses to all “registered” peer AAL applications 9.

[0170] FIGs. 14-15 are a diagram of an example modifier application 7 message sequence chart that shows an example of a message flow between an AAL application 2, a modifier application 7 and an AAL-LPU 4. The example uses AAL APIs, but other signaling messages may be used, e.g., extensions to 01 messaging. The modifier application 7 may be an 0-RAN rApp modifying the AAL-LPU 4 resources through an AAL application 2 (e.g., 0-DU NF).

[0171] As illustrated in this example, with respect to step 1A, when the modifier application 7 sends a signal to get the AAL-LPU 4 resource information (getAalLpuInfo Request), it causes the 0-DU AAL application 2 to initialize the AALI interface with the AAL-LPU 4 and then perform the procedure to get the AAL-LPU 4 resource information. In one or more embodiments, if the modifier application 7 calls any APIs before the primary AAL application 2 has called initAalQ, it causes the primary AAL application 2 to initiate the init procedure with the AAL-LPU 4.

[0172] Further, modifier application 7 and peer AAL application 9 may not have access to the full set of procedures and signaling that is supported by the AAL application 2 and the AAL-LPU 4. For example, a primary AAL application may only permit a subset of operations that a modifier application 7 may request - e.g., a primary AAL application may only permit the modifier application 7 to query the AAL-LPU information (get* APIs) but not permit state change operations (stop / start or set* APIs) or perform add / delete operations or configuration changes. Similarly, AAL-LPUs 4 may only permit peer AAL Applications 9 to perform a subset of operations and procedures. Further, with respect to step 11 A, the AALI-C- Application APIs adds the getAalLpuInfo, i.e., adds a new parameter when compared to existing signaling. In other words, in the example of FIGs. 14-15, the APIs used by modifier application 7 match the existing AALI-C-App APIs. In some embodiments, not all APIs might be needed by the a modifier AAL application 7 or supported by a primary AAL application 2, e.g., the primary AAL application 2 may only support some subset of operations from modifier application 7. For example, the modifier application 7 may have the ability to query the AAL-LPU 4 (get*APIs) but not one or more of change states (stop / start or set* APIs), add / delete things or change configurations. In another example, the modifier application 7 may use 01 signaling between modifier application 7 and AAL application 2 using new 01 messages and / or adding new parameters to existing 01 messages.

[0173] Proposed O-RAN O1 Interface extensions

[0174] Proposed Extensions to the 0-RAN 01 interface.

[0175] For the case of modifier applications 7, extensions may be required to the 01 interface between the modifier application 7 and the modifying AAL application. In one or more embodiments, the modifying AAL application is an intermediate AAL application 2 application where the modifier application 7 modifies the intermediate AAL application (i.e., root AAL application). In one or more embodiments, the modifying AAL application is another modifier application 7 if there is a chain of 2 or more modifier applications 7. One example of two modifier applications 7 is shown in FIG. 12. This applies to one or more of SMO, HAM, rApps and xApps, when one or more of these are not considered as AAL applications 2.

[0176] The extensions may be applicable to at least the following 01 management Services:

[0177] Create Managed Object Instance Modify Managed Object Instancesuggest Delete Managed Object Instance Read Managed Object Instance Attributes

[0178] The modifier application 7 instructs the modifying AAL application to perform the operations associated with these 01 management services on its behalf given AAL-LPU 4 resources.

[0179] O1 extensions

[0180] For the Create Managed Object Instance 01 management Service, the specific extensions that may be required to the 01 interface may include one or more of the following: the aal_lpu_handle, i.e., the handle to the AAL-LPU 4 resources. the characteristics of the target aal _profile_instance to be created.

[0181] The identifier to be used for the aal -profile -instance to be created.

[0182] The characteristics and attributes of the configuration that need to be used for the aal _profile_instance to be created.

[0183] For the Modify Managed Object Instance 01 management Service, the specific extensions that may be required to the 01 interface may include one or more of the following:

[0184] The handle to the aal _profile_instance.

[0185] The modifications to the attributes that are to be applied to the aal _profile -instance.

[0186] For the Delete Managed Object Instance 01 management Service, the specific extensions that may be required to the 01 interface may include the aal -profile -instance which needs to be deleted.

[0187] For the Read Managed Object Instance Attributes 01 management Service, the specific extensions that may be required to the 01 interface may include the handle to the aal -profile -instance whose attributes need to be obtained.

[0188] Proposed O-RAN E2 Interface extensions

[0189] Proposed Extensions to the E2 Service Model.

[0190] For the case of modifier applications 7, extensions are required to the E2 interface between a modifier application 7 and the modifying AAL Application. This applies to the Near RT RIC and xApps when these are not considered as AAL Applications 2.

[0191] These extensions apply to the following E2 Service Model (E2SM) services: Report, Query, Control.

[0192] E2 information element (IE) extensions

[0193] The specific information element extensions are proposed to the E2 interface and Service Model and are captured as follows:

[0194] - the identifier / handle to be used for the aal_profile_instance to be acted upon.

[0195] - the characteristics and attributes of the hardware acceleration and profile configuration that need to be used for the aal_profile_instance to be created, or to be modified. - the aal_lpu_handle, i.e., the handle to the AAL-LPU 4 resources being used by the aal_profile_instance.

[0196] AALI-C-App Interface extensions

[0197] In one or more embodiments, extensions are defined to the AALI-C-App to enable the modification and re-configuration of the use of hardware acceleration by an AAL application 2.

[0198] The figures described below illustrate the new APIs and API extensions.

[0199] FIG. 16 illustrates the new APIs and API extensions in the case of a Peer AAL Application (e.g., an rApp or xApp that is considered an AAL application) modifying use of AAL-LPU 4 resources, , according to some embodiments of the present disclosure.

[0200] New interfaces from Modifier Applications 7

[0201] A new interface is defined between the modifier application 7, e.g., the SMO, or a HAM, rApps and xApps when not considered as AAL applications 2, and the associated AAL application 2.

[0202] The new interfaces may be the same as the AALI-C-App defined in O-RAN and including the extensions described in the “Proposed O-RAN E2 Interface extensions” Section.

[0203] FIG. 17 illustrates the new APIs and API extensions in the case of a Modifier Application (e.g., an rApp or xApp that is not considered an AAL application, the SMO, or the HAM) modifying use of AAL-LPU 4 resources. , according to some embodiments of the present disclosure.

[0204] The capabilities and operations of the modifier application 7 interface would enable the modifier application 7 to execute all or a subset of the AALI-C-App and AALI- P APIs, procedures and operations.

[0205] For example, the modifier application 7 interfaces may be a one-to-one mapping of AALI-C-App and AALI-P APIs.

[0206] Network Cloud Implementation

[0207] The peer AAL application 9 and modifier application 7 can be deployed in a network cloud environment (e.g., AAL network 15). The AAL-LPU 4 resources may be cloud resources.

[0208] O-RAN Implementation

[0209] As part of the O-RAN implementation, the following extensions may be included in O-RAN specifications:

[0210] • Definition of peer AAL application 9 and modifier application 7 • Extensions to the AALIC-App API

[0211] • New interface between the modifier application 7 and an AAL Application 2.

[0212] • Extensions to 01 (Ol-App) and attributes for exchanges between modifier applications 7 and between modifier applications 7 and AAL applications 2 for the management of AAL-LPU 4 resources.

[0213] • Extensions to E2 (E2SM) information elements for exchanges between modifier applications 7 and between modifier applications 7 and AAL applications 2 for the management of AAL-LPU 4 resources.

[0214] For example, in some embodiments, the telecommunication system 10 includes one or more 0-RAN network nodes 16. An 0-RAN network node 16 is a node in the telecommunication system 10 that supports an 0-RAN specification (e.g., a specification published by the 0-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication system 10, including one or more network nodes 16 in the access network 12 and / or core network nodes 14.

[0215] Examples of an 0-RAN network node 16 include an open radio unit (0-RU), an open distributed unit (0-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near- real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an 0-RAN specification). The network node may support a specification by, for example, supporting an interface defined by the 0-RAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an 0-RAN access node may be a logical node in a physical node. Furthermore, an 0-RAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the 0-RAN Alliance or comparable technologies. The network nodes 16 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 22a, 22b, 22c, and 22d (one or more of which may be generally referred to as UEs 22) to the core network 14 over one or more wireless connections. FIG. 18 is a block diagram illustrating a virtualization environment 94 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 94 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 94 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

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

[0217] Hardware 98 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 100 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 102a and 102b (one or more of which may be generally referred to as VMs 102). The virtualization layer 100 may present a virtual operating platform that appears like networking hardware to the VMs 102.

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

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

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

[0221] Further, one or more functions of the virtualized environment 94 may be assigned (e.g., offloaded) to AAL network 15, as described herein.

[0222] Technical Specification Impact

[0223] The embodiments described herein may be applicable to at least the following specifications:

[0224] O-RAN.WGl.Use-Cases-Detailed-Specification;

[0225] O-RAN Work Group 1 O-RAN Architecture Description;

[0226] O-RAN WG6 AAL-GAnP - O-RAN Acceleration Abstraction Layer (AAL) General Aspects and Principles;

[0227] O-RAN WG6 AAL Common API - Acceleration Abstraction Layer Common API;

[0228] O-RAN.WG10 - Ol-Interface; and

[0229] O-RAN WG3 - E2SM. Therefore, one or more embodiments described herein provide extensions to the AAL specifications, procedures and APIs, and enable the real-time modification of the runtime behavior of AAL-LPU 4 resources either directly through additional peer AAL application(s) 9 or indirectly through modifier application(s) 7.

[0230] HW Accelerator resources such as an AAL-LPU 4 and AalProfilelnstance may be used, managed, and controlled by multiple AAL Applications 2 simultaneously.

[0231] To enable multiple, independent peer AAL applications 9 to directly control and modify the AAL-LPU 4 resources exposed by a common AAL-LPU 4 over the AALI-P and AALI-C-App interfaces one or more of the following may be provided:

[0232] • Extend AAL procedures and APIs to support receiving requests from multiple AAL application.

[0233] • Extend AAL procedures and APIs to support sending request responses to multiple AAL application.

[0234] • Extend AAL procedures and APIs to support discovery and exchange of the AAL-LPU 4 and AalProfilelnstance identifiers to multiple AAL applications. To enable an AAL application to indirectly control and modify AAL-LPU 4 resources exposed by an AAL-LPU 4 through modifier application 7 one or more of the following are provided:

[0235] • Extend AAL procedures and APIs to enable an AAL application client to send and receive state-aware AALI-C-App and AALI-P operations to / from another AAL application 2.

[0236] • Extend AAL procedures and APIs to support discovery and exchange of the AAL-LPU 4 and AalProfilelnstance identifier from one AAL Application 2 to another AAL Application 2.

[0237] One or more embodiments described herein provide one or more solutions that extend the capabilities to control AAL-LPU 4 resources in cellular networks based on O- RAN specifications. The one or more solutions enable the ability for additional cooperating applications 7 and / or 9 to modify in real time the use of how and whether an AAL Application 2 utilizes AAL-LPU 4 resources. This may be relevant for use cases such as network energy savings, network performance improvements, interference mitigation & resolution, as well as for AI / ML applications.

[0238] One or more embodiments described herein can be adapted to various scenarios. For example, an xApp or rApp can modify the AAL-LPU 4 resources that are used by gNB-DU (e.g., network node-DU) functions to save energy when user traffic levels are low and then modify the AAL-LPU 4 resources again when user traffic increases without interrupting service provided by the gNB-DU function. The xApp or rApp may be developed to manage the hardware resources directly (i.e., as a peer AAL application 9) or indirectly (i.e., as a modifier application 7) through another already deployed AAL Application 2.

[0239] One or more benefits of defining the various methods described herein is that they allow for different application implementations and deployments which provides the flexibility for vendors of the applications to be integrated into different network operators’ networks. For example, a vendor may develop a peer AAL application 9 that is installed in the O-Cloud on the same nodes as the primary AAL application (AAL Application 2). Alternatively, a vendor may develop a modifier application 7 that is deployed as part of an SMO and is designed to coordinate with AAL Applications (e.g., AAL Application 2 and / or Peer AAL Application 9) installed in the O-Cloud.

[0240] As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and / or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and / or functionality described herein may be performed by, and / or associated to, a corresponding module, which may be implemented in software and / or firmware and / or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

[0241] Some embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0242] These computer program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function / act specified in the flowchart and / or block diagram block or blocks.

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

[0244] It is to be understood that the functions / acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0245] Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and / or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

[0246] Abbreviations that may be used in the preceding description include:

[0247] Abbreviations Explanation

[0248] RAN Radio Access Network

[0249] AAL Accelerated Abstraction Layer

[0250] AAL Application A cloudified Application leverages AAL resources

[0251] CU Centralized unit

[0252] DU Distributed unit

[0253] HAM Hardware Accelerator Manager

[0254] HWA Hardware Accelerator

[0255] NF Network Function

[0256] O-RAN Open RAN, as defined by the ORAN Alliance

[0257] SMO Service Management and Orchestration

[0258] It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings.

Claims

1. WHAT IS CLAIMED IS:

1. A method implemented by a first acceleration abstraction layer, AAL, application (9) that is configured to communicate with a second AAL application (2), the method comprising: modifying (SI 00) a configuration for at least one hardware acceleration resource that is assigned for use by the second AAL application (2), the at least one hardware acceleration resource being at least one resource provided by an AAL-logical processing unit, LPU (4).

2. The method of Claim 1, wherein the modifying of the configuration for the at least one hardware acceleration resource comprises one of: releasing the at least one hardware acceleration resource that has been allocated for use by the second AAL application (2); adding at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the second AAL application (2), the at least one additional hardware acceleration resource being provided by the AAL-LPU (4); or changing usage of the at least one hardware acceleration resource.

3. The method of any one of Claims 1-2, wherein the second AAL application (2) provides one of: at least one network node-distributed unit, DU, function; or at least one network node-centralized unit, CU, function4. The method of any one of Claims 1-3, further comprising: transmitting a request to the AAL-LPU (4) to register the first AAL application (9) with the AAL-LPU (4) so that the first AAL application (9) receives responses to Application Program Interface, API, requests processed by the AAL-LPU (4).

5. The method of Claim 4, further comprising receiving a response to the request, the response indicating a plurality of AAL profile instances created on the AAL- LPU (4).

6. The method of any one of Claims 1-5, wherein the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

7. The method of any one of Claims 1-6, wherein the first AAL application (9) is one of: a non-Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

8. The method of any one of Claims 1-7, wherein the second AAL application (2) is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned to the second AAL application (2) to enhance performance.

9. A first acceleration abstraction layer, AAL, application (9) that is configured to communicate with a second AAL application (2), the first AAL application (9) configured to: modify a configuration for at least one hardware acceleration resource that is assigned for use by the second AAL application (2), the at least one hardware acceleration resource being at least one resource provided by an AAL-logical processing unit, LPU (4).

10. The first AAL application (9) of Claim 9, wherein the modifying of the configuration for the at least one hardware acceleration resource comprises one of: release the at least one hardware acceleration resource that has been allocated for use by the second AAL application (2); add at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the second AAL application (2), the at least one additional hardware acceleration resource being provided by the AAL-LPU (4); or change usage of the at least one hardware acceleration resource.

11. The first AAL application (9) of any one of Claims 9-10, wherein the second AAL application (2) provides one of: at least one network node-distributed unit, DU, function; or at least one network node-centralized unit, CU, function12. The first AAL application (9) of any one of Claims 9-11, wherein the first AAL application (9) is further configured to transmit a request to the AAL-LPU (4) to register the first AAL application (9) with the AAL-LPU (4) so that the first AAL application (9) receives responses to Application Program Interface, API, requests processed by the AAL-LPU (4).

13. The first AAL application (9) of Claim 12, wherein the first AAL application (9) is further configured to receive a response to the request, the response indicating a plurality of AAL profile instances created on the AAL-LPU (4).

14. The first AAL application (9) of any one of Claims 9-13, wherein the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

15. The first AAL application (9) of any one of Claims 9-14, wherein the first AAL application (9) is one of: a non-Real-Time RAN Intelligent Controller Application,, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

16. The first AAL application (9) of any Claims 9-15, wherein the second AAL application (2) is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned to the second AAL application (2) to enhance performance.

17. A method implemented by a modifier application (7) that is configured to communicate with an acceleration abstraction layer, AAL, application (2), the method comprising: modifying (SI 02) a configuration for at least one hardware acceleration resource that is assigned for use by the AAL application (2), the at least one hardware acceleration resource is at least one resource provided by an AAL-logical processing unit, LPU (4).

18. The method of Claim 17, wherein the modifying of the configuration for the at least one hardware acceleration resource comprises one of: releasing the at least one hardware acceleration resource that has been allocated for use by the AAL application (2); adding at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the AAL application (2), the at least one additional hardware acceleration resource being provided by the AAL- LPU (4); or changing usage of the at least one hardware acceleration resource.

19. The method of any one of Claims 17-18, further comprising: signaling, to the AAL application (2), a request for AAL-LPU information, the request configured to implicitly register the modifier application with the AAL-LPU (4); receiving, from the AAL application (2), a response to the request, the response comprising information associated with AAL profile instances associated with the AAL- LPU (4); and the modifying of the configuration being based on the information in the response.

20. The method of Claim 19, wherein the information comprises at least one of: a plurality of AAL profile instance identifiers;AAL profile instance configuration; orAAL profile instance state of at least one AAL profile instance created on the AAL-LPU (4).

21. The method of any one of Claims 17-20, wherein the AAL application (2) provides one of: at least one network node-distributed unit, DU, function; at least one network node-centralized unit, CU, function.

22. The method of any one of Claims 17-21, further comprising: transmitting, via the AAL application (2), a request to the AAL-LPU (4), the request being configured to register the modifier application (7) with the AAL-LPU (4) so that the modifier application (7) receives responses to API requests processed by the AAL- LPU (4).

23. The method of any one of Claims 17-22, wherein the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

24. The method of any one of Claims 17-23, wherein the AAL application (2) is one of: a non-Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

25. The method of any one of Claims 17-24, wherein the AAL application (2) is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned to the AAL application (2) to enhance performance.

26. A modifier application (7) that is configured to communicate with an acceleration abstraction layer, AAL, application (2), the modifier application (7) configured to:modify a configuration for at least one hardware acceleration resource that is assigned for use by the A AL application (2), the at least one hardware acceleration resource is at least one resource provided by an AAL-logical processing unit, LPU (4).

27. The modifier application (7) of Claim 26, wherein the modifying of the configuration for the at least one hardware acceleration resource comprises one of: release the at least one hardware acceleration resource that has been allocated for use by the AAL application (2); add at least one additional hardware acceleration resource to the at least one hardware acceleration resource that has been allocated for use by the AAL application (2), the at least one additional hardware acceleration resource being provided by the AAL- LPU (4); or change usage of the at least one hardware acceleration resource.

28. The modifier application (7) of any one of Claims 26-27, wherein the modifier application (7) is further configured to: signal, to the AAL application (2), a request for AAL-LPU information, the request configured to implicitly register the modifier application with the AAL-LPU (4); receive, from the AAL application (2), a response to the request, the response comprising information associated with AAL profile instances associated with the AAL- LPU (4); and the modifying of the configuration being based on the information in the response.

29. The modifier application (7) of Claim 28, wherein the information comprises at least one of: a plurality of AAL profile instance identifiers;AAL profile instance configuration; orAAL profile instance state of at least one AAL profile instance created on the AAL-LPU (4).

30. The modifier application (7) of any one of Claims 26-29, wherein the AAL application (2) provides one of: at least one network node-distributed unit, DU, function; at least one network node-centralized unit, CU, function.

31. The modifier application (7) of any one of Claims 26-30, wherein the modifier application (7) is further configured to transmit, via the AAL application (2), a request to the AAL-LPU (4), the request being configured to register the modifier application (7) with the AAL-LPU (4) so that the modifier application (7) receives responses to API requests processed by the AAL-LPU (4).

32. The modifier application (7) of any one of Claims 26-31, wherein the modifying of the configuration for the at least one hardware acceleration resource is performed via signaling over one of: an 01 interface; or an E2 interface.

33. The modifier application (7) of any one of Claims 26-32, wherein the AAL application (2) is one of: a non-Real-Time RAN Intelligent Controller Application, rAPP; a near Real-Time RAN Intelligent Controller Application, xAPP; a service management and orchestration, SMO, application; or a hardware accelerator manager, HAM.

34. The modifier application (7) of any one of Claims 26-33, wherein the AAL application (2) is configured to execute at least one radio access network, RAN, function, using the at least one hardware acceleration resource, wherein the at least one RAN function has been assigned to the AAL application (2) to enhance performance.

Images