Open radio access network interface adaptation

Abstract

An adaptation entity for an Open Radio Access Network (O-RAN) for interfacing between a Radio Access Network (RAN) Intelligent Controller (RIC) and a non-O-RAN-compliant RAN entity, wherein the adaptation entity is configured to: receive a first message from an application of the RIC (RICapp), the first message having an O-RAN-compliant format associated with the RIC, convert the first message to a second message having a non-O- RAN-compliant format associated with the non-O-RAN-compliant RAN entity, and transmit the second message to the non-O-RAN-compliant RAN entity.

Description

OPEN RADIO ACCESS NETWORK INTERFACE ADAPTATIONBACKGROUNDField

[0001] The present disclosure relates to open radio access network interface adaptation and, in particular, an adaptation entity for an open radio access network and an open radio access network, and methods of operation of an adaptation entity in an open radio access network and an open radio access network.Description of Related Art

[0002] Wireless or mobile (cellular) communications networks in which a mobile terminal (e.g., user equipment (UE), such as a mobile handset) communicates via a radio link with a network of base stations, or other wireless access points or nodes, have undergone rapid development through a number of generations. The 3rdGeneration Partnership Project (3GPP) design, specify and standardise technologies for mobile wireless communication networks. Fourth Generation (4G) and Fifth Generation (5G) systems are now widely deployed, and development of 5G-adavnced and Sixth Generation (6G) Systems is in progress.

[0003] 3GPP standards for 4G systems include an Evolved Packet Core (EPC) and an Enhanced-UTRAN (E-UTRAN: an Enhanced Universal Terrestrial Radio Access Network). The E-UTRAN uses Long Term Evolution (LTE) radio technology. LTE is commonly used to refer to the whole system including both the EPC and the E- UTRAN, and LTE is used in this sense in the remainder of this document. LTE should also be taken to include LTE enhancements such as LTE Advanced and LTE Pro, which offer enhanced data rates compared to LTE.

[0004] In 5G systems a new air interface has been developed, which may be referred to as 5G New Radio (5G NR) or simply NR. NR is designed to support the wide variety of services and use case scenarios envisaged for 5G networks, though builds upon established LTE technologies. New frameworks and architectures are also being developed as part of 5G networks in order to increase the range of functionality and use cases available through 5G networks.

[0005] Although the development of 6G systems is in its infancy, a number of further use cases and aims have been proposed, such as enhanced human communications, enhanced machine communications, enhanced communications for autonomous processes and vehicles, improved energy efficiency, providing and utilising AI / ML,and environmental sustainability for example. Consequently, the development of 6G systems is likely to be based on at least some of these.

[0006] An Open Radio Access Network (O-RAN) is an approach to providing radio access networks in a disaggregated manner such that a RAN can be constructed using elements from different manufacturers / suppliers (i.e. multi-vendor deployment). Among others, some of the primary aims of O-RANs is to promote innovation and increase manufacturer diversity, which are enabled by this disaggregation of a conventional RAN into interoperable elements. Due to these advantages, O-RANs are envisaged to implement the RAN for future 5G networks and beyond (e.g. 5G- advanced, 6G etc.).

[0007] Central to the concept of O-RANs is the standardisation of the interface between the disaggregated elements that combine to form the radio interface with the core network and the UEs (i.e. the radio access network), since this allows elements from different manufacturers / suppliers to be deployed in conjunction with one another. However, this can limit the integration of network entities that use legacy and / or proprietor interfaces into O-RANs.SUMMARY

[0008] It is an aim of certain examples of the present disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.

[0009] In accordance with a first aspect of the present disclosure, there is provided an adaptation entity for an Open Radio Access Network (O-RAN) for interfacing between a Radio Access Network (RAN) Intelligent Controller (RIC) and a non-O- RAN-compliant RAN entity, wherein the adaptation entity is configured to: receive a first message from an application of the RIC (RICapp), the first message having an O-RAN-compliant format associated with the RIC, convert the first message to a second message having a non-O-RAN-compliant format associated with the non- O-RAN-compliant RAN entity, and transmit the second message to the non-O- RAN-compliant RAN entity.

[0010] In an example, the first message is received via an O-RAN-compliant interface associated with the RIC.

[0011] In an example, the O-RAN-compliant interface is one of an E2 interface, an 01 interface, an A1 interface, and an Open Fronthaul interface.

[0012] In an example, the adaptation entity is configured to receive the first message and convert the first message to the second message based on a Application Programming Interface (API) associated with the non-O-RAN-compliant RAN entity.

[0013] In an example, the second message is transmitted via a non-O-RAN-compliant interface associated with the non-O-RAN-compliant RAN entity.

[0014] In an example, the converting includes configuring one or more of a voltage, frequency, and timing of the second message based on the non-O-RAN-compliant interface.

[0015] In an example, the adaptation entity interfaces with only the non-O-RAN-compliant RAN entity among one or more non-O-RAN-compliant RAN entities.

[0016] In an example, the adaptation entity is included in the single non-O-RAN-compliant RAN entity.

[0017] In an example, the adaptation entity is configured to interface with a plurality of non-O-RAN-compliant entities using messages having a non-O-RAN-compliant format.

[0018] In an example, each of the plurality of non-O-RAN-compliant entities has an associated API and the adaptation entity is configured to convert the first message to the second message based on the API associated with the non-O-RAN compliant entity.

[0019] In an example, the adaption entity is provided outside of the RIC and the plurality of non-O-RAN-compliant RAN entities.

[0020] In an example, the adaptation entity is included in the RIC.

[0021] In an example, the first message includes a monitoring identifier or a parameter identifier associated with the non-O-RAN-compliant RAN entity or a functionality of the non-O-RAN-compliant RAN entity, and the converting includes generating the second message based on the monitoring identifier or the parameter identifier and the API associated with the non-O-RAN-compliant RAN entity.

[0022] In an example, the RIC is a near-real-time RIC and the RICapp is an xApp of the RIC.

[0023] In an example, the RIC is a non-real-time RIC and the RICapp is an rApp of the RIC.

[0024] In an example, the first and second messages are for control of and / or monitoring of the non-O-RAN-compliant RAN entity and / or a function associated with the non- O-RAN compliant RAN entity.

[0025] In an example, the adaptation entity is at least partially implemented in hardware (e.g. ASIC, CPU, GPU etc.).

[0026] In an example, the non-O-RAN-compliant RAN entity includes at least one of a distributed unit (DU), a radio unit (RU), a central unit (CU), a power supply unit (PSU), a power amplifier (PA), and an eNB / gNB.

[0027] In an example, the second message is transmitted to the non-O-RAN-compliant RAN entity via an Internet Protocol (IP) network.

[0028] In an example, the adaptation entity is configured to: receive a third message from the non-O-RAN-compliant RAN entity, the third message having a non-O-RAN- compliant format associated with the non-O-RAN-compliant RAN entity, convert the third message to a fourth message having an O-RAN-compliant format associated with the RIC, and transmit the fourth message to an application of the RIC (e.g. RICapp).

[0029] In accordance with a second aspect of the present disclosure, there is provided a method of an adaptation entity of an Open Radio Access Network (O-RAN) for interfacing between a Radio Access Network (RAN) Intelligent Controller (RIC) and a non-O-RAN-compliant RAN entity, the method including: receiving a first message from an application of the RIC (RICapp), the first message having an O- RAN-compliant format associated with the RIC, converting the first message to a second message having a non-O-RAN-compliant format associated with the non- O-RAN-compliant RAN entity, and transmitting the second message to the non-O- RAN-compliant RAN entity.

[0030] In accordance with a third aspect of the present disclosure, there is provided an Open Radio Access Network (O-RAN) including a RAN Intelligent Controller (RIC), a non-O-RAN-compliant RAN entity, and an adaptation entity for interfacing between the RIC and the non-O-RAN-compliant RAN entity, wherein RIC includes an application (RICapp) and the RICapp is configured to generate and transmit a first message to the adaptation entity, the first message having an O-RAN- compliant format associated with the RIC; wherein the adaptation entity is configured to receive the first message, convert the first message to a secondmessage having a non-O-RAN-compliant format associated with the non-O-RAN- compliant RAN entity, and transmit the second message to the non-O-RAN- compliant RAN entity; and wherein the non-O-RAN-compliant RAN entity is configured to receive the second message and perform a function based on the second message.

[0031] In an example, the O-RAN the includes a distributed unit (DU), a radio unit (RU), a central unit (CU), and the non-O-RAN-compliant RAN entity is associated with the RU.

[0032] In accordance with a fourth aspect of the present disclosure, there is provided a method of operation of an Open Radio Access Network (O-RAN) including a RAN Intelligent Controller (RIC), a non-O-RAN-compliant RAN entity and an adaptation entity, the method comprising: generating, by the RIC, a first message, the first message having an O-RAN-compliant format associated with RIC; transmitting, by the RIC, the first message to the adaptation entity; receiving, by the adaptation entity, the first message; converting, by the adaptation entity, the first message to a second message having a non-O-RAN-compliant format associated with the non- O-RAN-compliant RAN entity; transmitting, by the adaptation entity, the second message to the non-O-RAN-compliant RAN entity; receiving, by the non-O-RAN- compliant RAN entity, the second message; and performing, by the non-O-RAN- compliant RAN entity, a function based on the second message.

[0033] In an example, the non-O-RAN-compliant RAN entity is a RAN entity that provides at least one RAN function that is not supported by / not directly accessible by the RIC via an O-RAN-compliant interface.

[0034] In accordance with a fifth aspect of the present disclosure, there is provided a computer-readable recording medium having stored thereon computer-readable instructions which when executed by a computer cause the computer to perform any of the above methods.

[0035] Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Embodiments / examples of the present disclosure are further described hereinafter with reference to the accompanying drawings, in which:Figure 1 provides a diagram of an example Open Radio Access Network (O-RAN);Figure 2 provides a diagram of an example O-RAN including an adaptation entity in accordance with the present disclosure;Figure 3 provides a diagram of an example O-RAN including an adaptation entity in accordance with the present disclosure;Figure 4 provides a diagram of an example O-RAN including an adaptation entity in accordance with the present disclosure;Figure 5 provides a diagram of an example O-RAN including an adaptation entity in accordance with the present disclosure;Figure 6 provides a diagram of an example O-RAN including an adaptation entity in accordance with the present disclosure; andFigure 7 provides a block diagram of an exemplary network entity / function that may be used in certain examples of the present disclosure.DETAILED DESCRIPTION

[0037] The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of certain examples of the present disclosure. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the invention or disclosure.

[0038] The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

[0039] Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure.

[0040] The terms and words used herein are not limited to the bibliographical or standard meanings, but are merely used to enable a clear and consistent understanding of the disclosure.

[0041] Throughout the description of this specification, the words “comprise”, “include” and “contain” and variations of the words, for example “comprising” and “comprises”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof.

[0042] Throughout the description of this specification, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects.

[0043] Throughout the description, the expression “at least one of A, B and / or C” (or the like) and the expression “one or more of A, B and / or C” (or the like) should be seen to separately include all possible combinations, for example: A, B, C, A and B, A and C, A and B and C.

[0044] Throughout the description of this specification, language in the general form of “X for Y” (where Y is some action, process, operation, function, activity or step and X is some means for carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y.

[0045] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof described or disclosed in conjunction with a particular aspect, embodiment or example are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith.

[0046] The following examples are applicable to, and use terminology associated with, 3GPP 4G (e.g., LTE) and / or 5G (e.g., NR). However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 4G (e.g., LTE) and / or 5G (e.g., NR), and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards (e.g., B5G, 5G-Advanced, 6G etc.). The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 4G (e.g., LTE) and / or 5G (e.g., NR) and / or 5G Advanced and / or 6G, and / or (3GPP Release 17, 18, 19, 20, etc.) or any other relevant standard. For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards such as non-terrestrial networks (NTNs). Furthermore, the examples set out in this disclosure are not limited to Open RAN and the inventive principles disclosed herein may be applied to any RAN. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network.

[0047] Furthermore, the following also applies to the present disclosure:• The terms functionality / use-case / configuration / scenario / site may be used interchangeably.• The terms model and model functionality may be used interchangeably.• This disclosure also applies to non-3GPP entities.• The term radio access network (RAN) refers to any form of radio access network and is not limited to a specific architecture or functionality.• The concepts, proposals, solutions, methods, embodiments, figures, and / or examples, presented in this disclosure, would apply to various type of communication systems, such as 4G, 4G-Advanced, 5G, 5G-Advanced, and 6G.

[0048] A particular network entity may be implemented as a network element on dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0049] The skilled person will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example:• One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations.• One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information.• One or more further elements, entities and / or messages may be added to the examples disclosed herein.• One or more non-essential elements, entities and / or messages may be omitted in certain examples.• The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example.• The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example.• Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example.• Information carried by two or more separate messages in one example may be carried by a single message in an alternative example.• The order in which operations are performed may be modified, if possible, in alternative examples.• The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein.Open Radio Access Networks (O-RANs)

[0050] Open Radio Access Networks (O-RANs) are being designed as a way of allowing other actors into the telecoms supply chain by providing approaches to disaggregate the Radio Access Network (RAN) into separate entities / components. Other advantages of O-RANs may include:• Accelerate innovation by leveraging opensource technologies.• Service differentiation.• A lower Total Cost of Ownership (TCO).• Secure the telecom supply chain.• Operator control and applications security.

[0051] Examples of the disaggregated components include the Core / Central Unit (OU), Distributed Unit (DU) and Radio Unit (RU). Control of the disaggregated components and thus the RAN is performed by RAN Intelligent Controllers (RICs), with predefined interfaces to obtain information or provide actuation functions to one of more of the CU, DU, and RU. In one current implementation, a RIC has been defined for non-real time control (non-RT RIC), via rApps, and a RIC defined for near-real time control (near-RT RIC) via xApps, where these RICs may be used in combination to control the O-RAN.

[0052] Central to O-RAN is the provision of standardised interfaces between the disaggregated components in order to allow interoperability. In particular, the intention is that O-RAN compatible equipment, e.g. the CU, DU and RU, will be equipped with standardised (i.e. O-RAN-compliant) interfaces, to allow components from different providers to interoperate and be controlled from the RICs.

[0053] More specifically, as part of an O-RAN, the RAN is primarily disaggregated into an O-RAN Radio Unit (O-RU or RU) that communicates with UEs, an O-RAN Distributed Unit (O-DU or DU), and O-RAN central unit (O-CU or CU), where the O- CU includes logical components CU-User Plane (CU-UP) and CU-Control Plane (CU-CP), with RICs controlling each of these.

[0054] Figure 1 provides an example O-RAN architecture in accordance with the O-RAN Architecture Description produced by the O-RAN Alliance, where further details can be found in O-RAN Architecture Description (OAD), version 11.0, O-RAN Alliance, February 2024.

[0055] In Figure 1 , the non-RT RIC 102 (which may be part of the System Management and Orchestration (SMO) framework 118), the near-RT RIC 104, the Open eNB (O- eNB) 106, the O-CU-CP 108, the O-CU-UP 110 (O-CU-CP and O-CU-UP together form the CU), the O-DU 112, O-RU 124, and O-Cloud 126 that form the O-RAN are illustrated along with the interfaces that connect each. The interfaces 01, 02, A1 , Open Fronthaul Management Plane (Open FH M-Plane), Open Fronthaul Control User Synchronisation Plane (Open FH CUS-Plane) are O-RAN Alliance-defined interfaces; the interfaces E1 , F1-c, F1-u, X2-c, X2-u, NG-u, NG-c, Xn-u, and Xn-u are 3GPP-defined interfaces; and interface 120 has yet to be defined. Details of the O-RAN Alliance and 3GPP interfaces can be found in the relevant technical specifications for each of these standards. The CU is communicatively connected to a core network (e.g. 5G or 6G core network) via the one or more of the interfaces X2-c, X2-u, NG-u, NG-c, Xn-u, and Xn-u.

[0056] The non-RT RIC primarily manages functionality that requires / has a response time of over 1s, such as those at a higher level of the O-RAN, for example, configuration management, device management, fault management, performance management, and lifecycle management for network elements. The near-RT RIC primarily manages functionality that requires / has a response time of approximately 10ms to 1s, such as those at a lower level of the O-RAN and closer to the UE, for example, load-balancing, resource management, interference detection and mitigation. However, a near-RT RIC is not only limited to this response time and may manage functions with shorter response times (e.g. less than 10ms), such as those that may be required in future generation mobile networks (e.g. 6G and beyond).

[0057] Although Figure 1 illustrates a single RU and a single DU, multiple RUs may be connected to a DU and multiple DUs may be connected to a CU. Due to the standardised open interfaces between the disaggregated elements of the O-RAN, any of the entities of Figure 1 may be provided by different vendors, thus contributing to the advantages of the O-RAN architecture.O-RAN Interface Adaptation

[0058] Although the use of open / standardised interfaces is central to O-RANs, much equipment, for example current / legacy RUs and components thereof, have proprietary interfaces (i.e. they are non-O-RAN-complaint) and therefore will not beable to be used in O-RANs and / or their RAN functionality cannot be controlled by / exposed to RICs. This impedes the use of current / legacy equipment in future O-RANs. Consequently, means for enabling the use of non-O-RAN compatible / compliant entities / equipment in O-RANs would be beneficial.

[0059] In accordance with the present disclosure, this problem is addressed via the provision an adaptation layer / entity / function, which enables standard O-RAN interfaces, (x,r)apps and messages across the O-RAN interfaces to be translated through to the proprietary interface of the non-standard O-RAN equipment and vice versa. Among other things, this may help to lower the barrier to entry for smaller manufacturers and legacy manufacturers, and allow non-standard telecoms equipment to be used within the standard O-RAN stack.

[0060] More specifically, the adaptation layer / entity / function is made up of hardware and / or software that enables two sets of virtual and / or physical interfaces to be connected via a translation function, that will translate the messages both northbound and southbound within the protocol stack, such that they appear at the interfaces of each component in the appropriate format. In the case of physical interfaces, this may also include providing one or more of the appropriate, voltage, frequency, timing, and interface form factor for correct operation with the interface.

[0061] Throughout this disclosure the conversion of messages sent between O-RAN- compliant entities and non-O-RAN-compliant entities may be referred to as conversion, adaptation, translation, function adaptation, transformation, or any other suitable term. The term O-RAN-compliant refers to entities that communicate with other entities in an O-RAN according to O-RAN specified interfaces (i.e. using messages having an O-RAN-compliant format). In particular, O-RAN-compliant entities include entities that communicate via and / or may be controlled via one of the standardised O-RAN (i.e. O-RAN specified) interfaces and the message formats thereof. The term non-O-RAN-compliant refers to entities that communicate (e.g. allow access to functionality thereof) at least partially via a non- O-RAN standardised (non-O-RAN specified or proprietary) interfaces (i.e. using messages having a non-O-RAN-compliant format). It should be noted that non-O- RAN interfaces may include standardised / open interfaces that have not been specified as being an O-RAN interface. The term compliant may be used interchangeably with compatible and standardised, and the entity that is performing the conversion may also be referred to as an element, component, transformer, function, or layer, and may take the form of a logical, virtual, or physical entity, and the functionality provided by such entities may be provided via software, hardwareor any other suitable platform e.g. virtualisation, cloud-based. Furthermore, the functionality provided by the conversion may be distributed across different entities but may still be considered as being provided by a signal entity / function / layer etc. The non-O-RAN-compliant entities may provide any function associated with a RAN or components thereof, such as functions associated with the CU, DU, and / or RU for example. With respect to RU-associated functions, such functions may for example include RU power control, RU amplifier control etc. and may be provided via hardware and / or software. Non-O-RAN-compliant entities / components may be considered to provide non-standardised (i.e. non-O-RAN-compliant) functions that cannot be accessed via an O-RAN-compliant interface. In some instances, one or more non-O-RAN compliant functions may be associated with an O-RAN entity that also provides O-RAN-compliant functions, such as a CU / DU for example. More specifically, certain RAN functions associated with the CU / DU may not be exposed via an O-RAN-compliant interface (e.g. E2) and thus a conversion entity / layer is needed for such RAN functions to be accessed by the RIC(s). Therefore, in this disclosure, although non-O-RAN compliant entities are predominantly referred to as RAN entities that do not communicate via an O-RAN-compliant interface (i.e. do not expose functions to the RIC directly via an O-RAN-compliant interface), this terminology may also refer to RAN entities that provide at least some RAN functions that cannot be accessed / exposed by a RIC directly via an O-RAN- compliant interface (i.e. non-O-RAN-compliant functions). In other words, a non-O- RAN compliant entity may also refer to a RAN entity that does not provide access to RAN functions by a RIC exclusively via an O-RAN-compliant interface.

[0062] Throughout this disclosure, unless otherwise stated the conversion applies to messages being transmitted and received by the O-RAN-compliant and non-O- RAN-compliant entities. The messages may also be referred to as signals, commands, information, communications, instructions, data, frames, packets or any other suitable term. Furthermore, the non-O-RAN-compliant and O-RAN- compliant entities may be logical entities, hardware-based, and / or software-based.

[0063] In this disclosure the messages are predominantly considered as being communicated between RICs (and the applications running thereon) and non-O- RAN-compliant entities for the purposes or monitoring and control. However, the messages may be communicated between any two components within an O-RAN that do not have compatible interfaces and the messages may be for any purpose. For example, although the figures described below include particular non-O-RAN- compliant entities, the disclosed approach is not limited to such entities.

[0064] As noted above, given O-RAN and its multi-vendor nature, the RAN could consist of not only the components such as CU / DU / RU, but also non-O-RAN-compliant entities such as power supply, external amplifier, conventional all-in-one eNB / gNB, etc. which can be controlled / configured via their specific interfaces. These entities may not feature the open O-RAN-compliant (i.e. O-RAN standardised) interfaces such as E2 and 01, therefore making the RIC / RICapp difficult to integrate the control / configuration for them. To allow the RIC / RICapp to obtain access to RAN components (and their functions) that do not communicate via an O-RAN-compliant interface, an adaptation entity may be provided which exchanges information received from non-O-RAN-compliant entities with the RIC / RICapp via an O-RAN- compliant interface, where the information may be for control and or monitoring purposes for example.

[0065] The deployment of the adaptation entity (i.e. its location) may be dependent on the types of the hardware connections it is associated with. For example, if the connected entities can be controlled via Ethernet, the deployment of the adaptation entity can be flexible as long as the entity is reachable via IP. If the entity only offers USB connection, the adaptation entity may have to be deployed on a computing platform with a physical connection to the entity to be communicated with. Other types of connections may also lead to other deployment structures.

[0066] The concept of the O-RAN adaptation entity / layer is primary concerned with hardware elements associated with or that are part of the RU but can be extended to other elements of the O-RAN system including non-proprietary DUs for example. It is also possible for the O-RAN adaptation entity to interoperate with other management planes associated with other telecommunication protocols, including Wi-Fi, and also management planes associated with non-telecommunication equipment, enabling both sensing and actuation functions to be performed as part of RIC functionality.

[0067] The adaptation entity could be bespoke to fit the specific adaptation function that is needed to integrate the non-O-RAN-compliant equipment into O-RAN. However, it could also be developed in a generic way, which implements a number of inputs and outputs. These inputs and outputs can be activated or deactivated, as needed, with their exact functionality configured via a control panel or management plane to perform the function needed. In this way the adaptation entity can be more flexible and offered to a customer at reduced cost, with reduced development time needed to instigate O-RAN-compliant equipment.

[0068] For some functions, features of the adaptation entity may be implemented in hardware, for example, functions where acceleration is needed. Such hardware could be based on ASICs or programmable ASICs. Alternatively, the adaptation entity functionality could be assisted by incorporating other processing capability, e.g. via a CPU and GPU.

[0069] Figure 2 illustrates a first implementation 200 of an adaptation entity in an O-RAN in accordance with the present disclosure.

[0070] The O-RAN of Figure 2 includes the standardised O-RAN components CU 211, DU, 212, RU 213 and RIC 220. The CU 211, DU, 212, RU 213 may be considered to form the at least part of the RAN 210, and the RIC is a near-RT RIC in this example, and includes RIC xApps RICappI 221, RICApp2 222, and RICApp3 223 running thereon. The RIC 220 is connected to the CU 211 and DU 212 by an O- RAN-compliant E2 interface 262 and may control one or more O-RAN-standardised RAN functions 240 via another E2 interface 263, including Key Performance Measurement (KPM) metric collection 241 , cell configuration 242, and RAN control 243 for example, where these functions are provided by O-RAN-compliant entities (i.e. the functions are accessible through the entity via an O-RAN-complaint interface), thus allowing them to be accessed by the RIC without an adaptation entity. Although the RIC 220 is a near-RT RIC in this example, it may also be a non-RT RIC which is instead connected to other components of the O-RAN via an O-RAN-compliant 01 interface. Examples of xApps may include a KPM xApp, which receives KPM metrics (e.g., UE throughput, packet drop rate) from the network and an RC (RAN Control) xApp, which uses the KPMs to make changes (e.g., balance resources allocated to each UE) to the network for optimisation purposes.

[0071] The O-RAN of Figure 2 also includes a number of other entities in the RAN 210, including power supply unit (PSU) 214, power amplifier 215, Conf 216, eNB / gNB 217, and one or more other entities 218, where Conf 216 refers to one or more entities that handle changes to (or functions that change) configuration parameters such as cell frequency / bandwidth, TDD uplink / downlink slot pattern etc. However, in the example of Figure 2 these other entities do not communicate via an O-RAN- compliant interface (e.g. not via E2, 01) and therefore cannot be controlled by the RIC (i.e. they are non-O-RAN-compliant entities). In particular, the other entities 214-218 may communicate via one or more non-O-RAN-compliant interfaces (e.g. hardware / software specific interfaces) represented by interface 264 and the functions associated with these entities may be controlled via interfaces 265, whereinterface 264 may be, but is not limited to, Ethernet or USB, and interface 265 corresponds to a logical interface that is relevant to control (e.g. via software) of the functions by using appropriate APIs. Accordingly, one or more functions 250 associated with the non-O-RAN-compliant entities (i.e. non-standardised RAN functions) cannot be controlled / accessed by the RIC, where examples of the nonstandardised RAN functions include RU on / off 251 , PA on / off 252, gain control of the PA 253, energy measure 254, CU / DU on / off 255, cell type control 256, and one or more other functions 257. The RU 213 itself may also be a non-O-RAN- compliant entity.

[0072] In accordance with the present disclosure, in order to enable control of the non-O- RAN-compliant entities 214-218 (and thus the non-standardised RAN functions 250) by the RIC, the O-RAN includes an adaptation entity 230 (adaptation layer, adaptation function etc.) that is connected to the RIC via an O-RAN-compliant interface (e.g. E2 261) and allows the RIC to transmit and receive messages to and from the non-RAN-compliant entities and / order control functionalities (i.e. nonstandardised RAN functions) associated with the non-O-RAN-compliant entities. In particular, the adaptation entity receives a message from an application of the RIC (RICapp), that has an O-RAN-compliant format associated with the RIC (e.g. E2- compliant format), converts the message to a message having a non-O-RAN- compliant format associated with the (interface of) non-O-RAN-compliant RAN entity to be controlled, and transmits the converted message to the non-O-RAN- compliant entity via the interface associated with the non-O-RAN-compliant entity. This process may also operate in the reverse direction so that messages can be sent by the non-O-RAN-compliant entity to the RIC. Although the term conversion is used here, this encompasses processing such as the RIC indicating a function it wants to perform to the adaptation entity via an O-RAN-compliant interface and the adaptation entity generating a command that is appropriate for controlling or requesting the functionality from the non-O-RAN-compliant entity. For example RIC may indicate an index of a function and the adaption entity will translate the index into an appropriate command to be send to the non-O-RAN-compliant entity.

[0073] As shown in Figure 2, the adaptation entity 230 may include a collection of component APIs (API1 232, API2 233, API3 234) for interactions (e.g., monitoring, sensing and control functionality etc.) with all the non-O-RAN-compliant entities 214-218 (i.e. the single adaptation entity 230 provides RAN function adaptation for all the non-O-O-RAN-compliant entities). The adaptation entity may also include an E2 agent 231 which handles the messages from / to the RIC and effectively presentsa separate E2 node with a collection of non-standardised RAN functions to the RIC, such that the non-O-RAN-compliant nature of the entities that provide the nonstandardised RAN functions is effectively hidden from the RIC. More specifically, the E2 agent 231 will receive a message from the RIC and convert it into the appropriate from / include in a new message the appropriate commands for implementing the command / request of the RIC using (i.e. based on) the appropriate API of the non-O-RAN-compliant entity and vice versa for messages received from a non-O-RAN-compliant entity intended for the RIC. The conversion may also include appropriate control of voltage, frequency, and timing of the messages based on the non-O-RAN-compliant interface.

[0074] Given the maturity of the E2 interface compared with other interfaces such as A1 / O1, E2 is considered here but the same concept also applies to other interfaces in O-RANs or other networks. Similar to any O-RAN-compliant E2 nodes, the E2 agent uses E2 Service Model - Key Performance Measurement (E2SM- KPM) to send monitoring data to the xApp and uses E2 Service Model - RAN Control (E2SM-RC) to receive control commands from the xApp. In terms of the E2SM-KPM, the E2 agent allows the RICapp to subscribe to non-standardised KPMs (RICapp only needs to know the names of the KPMs, which are predefined by the adaptation layer) and the adaptation layer can query the requested monitoring data from the specific hardware via the hardware’s API. In terms of the E2SM-RC, the E2 agent allows the RICapp to configure non-standardised parameters (RICapp only needs to know the parameter IDs, which are predefined by the adaptation entity) and the adaptation layer can configure such hardware parameters via the hardware’s API.

[0075] In a specific example based on Figure 2, the RU is equipped with a non-O-RAN- compliant smart PSU 214 and a non-O-RAN-compliant external PA 215, where these have a least some non-standardised RAN functions 250 associated therewith. However, by virtue of the adaptation entity 230 acting as an intermediary, an RICapp (221-223) of the RIC 220 can achieve non-standardised KPM collection such as energy consumption monitoring 254, and controls of nonstandardised RAN functions such as RU / PA on / off switch 251, 252, RU output power and cell type (macro / small cell) reconfiguration 256. These functions, which would otherwise not be accessible to the RIC and / or able to be included in an O- RAN may enable the AI / ML algorithms at the RIC to have better monitoring of the RAN performance as well as more control options, therefore benefiting the overall RAN performance optimisation.

[0076] Figure 2 illustrates an implementation where an adaptation entity manages messaging / interactions between a RIC and multiple non-O-RAN-compliant entities; however, in accordance with another example of the present disclosure, multiple adaptation entities may be provided with each handling interactions with only some of the non-O-RAN-compliant entities and thus handling (i.e. exposing to a RIC) only some of the available non-standardised RAN functions.

[0077] Figure 3 illustrates a second implementation 300 of an adaptation entity in an O- RAN in accordance with the present disclosure. In particular, Figure 3 illustrates an implementation where multiple adaptation entities are provided with each handling messaging with only some (e.g. one) of the non-O-RAN-compliant entities. For simplicity, Figure 3 shows an O-RAN which focusses on the interactions between the RIC and the non-standardised RAN functions 250 provided by non-O-RAN- compliant entities and therefore, although not shown, the connections and entities shown in 210 of Figure 2 may also be present in Figure 3. Furthermore, those entities / interfaces / functions of Figure 3 with the same reference numerals as Figure 2 have similar characteristics and therefore may not be described in detail again with respect to Figure 3. The message conversion / processing that enables the RIC to communicate with / access functionality associated with the non-O-RAN- compliant entities that is performed by the adaptation entities of Figure 3 is equivalent to that described with reference to Figure 2.

[0078] More specifically with respect to Figure 3, rather than having one adaptation entity and therefore one E2 agent managing the E2 messages for all the non-O-RAN- compliant entities / non-standardised functions, each non-O-RAN-compliant entity has a dedicated adaption entity and E2 agent therein and each adaptation entity handles the non-standardised RAN functions (i.e. function adaptation) associated with the non-O-RAN-compliant entity i.e. the adaptation layer is formed from / includes multiple adaptation entities. For example, the PA adaptation entity 310 includes E2 agent 312 and handles the RAN functions (i.e. function adaptation) associated with the PA 215 such as PA on / off 252 and gain control 253 using PA API1 314 and PA API2 316, and is connected to the RIC 220 via E2 interface 318. Similarly, the PSU adaptation entity 320 includes E2 agent 322 and handles the RAN functions (i.e. function adaptation) associated with the RU 213 such as RU on / off 251 and measurement of energy consumption 254 using PUS API1 324 and PSU API2 326, and is connected to the RIC 220 via E2 interface 328.

[0079] The structure of Figure 3 effectively creates one E2 node per non-O-RAN- compliant entity and each node comes with a unique set of RAN functions (i.e.functions associated with the non-RAN-compliant entity). To implement this structure, each E2 agent (312, 322) can have a common E2 message engine (to handle code / decode of the E2 messages) with additional code to interact with hardware specific APIs. Compared with the structure of Figure 2, the structure of Figure 3 may provide more flexible deployment since different adaptation entities can be deployed to handle different types of hardware connections (e.g., non-IP based connections will not affect the deployment of adaptation functionality for IP based hardware). However, the RIC and RlCapp(s) thereon may need to establish multiple E2 connections (rather than just one) to interact with all the non-O-RAN- compliant entities and thus access all of the non-standardised functions, which may make the RIC and RICapp configuration more complex.

[0080] The adaptation entity / functionality described with respect to Figures 2 and 3 can sit in different points within the O-RAN system. In the case of Figure 2, it may sit within the RIC or as a standalone entity. In the case of Figure 3, the multiple adaptation entities may sit either in the RIC, as standalone entities, in the RU, or in each associated non-O-RAN-compliant entity. When the adaptation entities are within the RU and / or individual non-O-RAN-compliant entities, it may allow for nonstandard O-RAN equipment, with proprietary interfaces to be customised and packaged so that it can be equipped with the correct interfaces to allow it to be integrated into an O-RAN network with adaptation of the O-RAN itself. This may allow the adaptation functionality to serve different customer segments, including MNOs, equipment providers, and bespoke private network operators.

[0081] Figure 4 shows an example implementation 400 of an adaptation entity / layer in accordance with the structure of Figure 2 where non-O-RAN-compliant entities have been integrated into an O-RAN network. The entities inside the dotted line box 410 may take the form of hardware components and the components outside the dotted line box may be hardware, logical / software, and / or cloud-based entities. The RIC 402 communicates with the CU / DU via an interface 403 (E2 in the case of near-RT RIC) and xApp 406 for control / monitoring of energy saving that runs on the RIC 402 communicates with the adaptation entity 408 via the E2 interface 407. Internal communications of the RIC may take any suitable form are represented by interface 405. The adaptation entity 408 includes an IP-based connection 409 that allows it to communicate with non-O-RAN-compliant entities that may be remote to the adaptation entity. The entities within the box 410 are merely example entities and any selection of entities may be used in practice. Furthermore, in some examples, the entities within the box 410 may be provided in an aggregatedmanner (e.g. in a single housing) and / or one or more of the entities within the box 410 may be combined.

[0082] The non-O-RAN-compliant components requiring control by an adaptation entity include a Time-Division Multiplexing (TDD) PA 412 and a NETIO AC relay 414 (which has smart AC sockets and offers functions such as on / off and power consumption monitoring via Ethernet). The PA 412 requires communication using the RS485 interface (4-wire) 416 which is handled by a Yocto RS485 module 418 (which handles the RS485 communication protocol via a Python API, PA on / off and gain control are implemented through this). This module is further connected to a Yocto Ethernet Hub 420 so the control of the PA 412 becomes reachable via an IP network. Through using the Yocto RS485 module specific APIs, the adaptation entity can achieve (i.e. make available to the RIC) the PA relevant nonstandardised RAN functions such as PA status monitoring, PA on / off and gain control. The NETIO AC relay 414 is equipped with an Ethernet interface and can be reached via IP without the support of additional hardware. Through using the NETIO AC relay specific APIs and adaptation entity can conduct non-standardised RAN functions such as AC socket specific energy consumption measurements (e.g., RU / PA energy measurements), and socket specific on / off control which can turn on / off any hardware (e.g., the RU) which is connected to the NETIO AC relay’s sockets.

[0083] With respect to the other components of Figure 4, 411 is a connection (e.g. fibre) between the server hosting the CU / DU and the open source RU (Universal Software Radio Peripheral - USRP); 422 is a Yocto power relay which powers 418 and 430, and the power can be turned on / off via a Python API; 424 is a General Purpose Input-Output (GPIO) breakout board which connects to a 3V pin from the 426's GPIO output, this 3V powers the RF switch 430 via the relay 422; 426 in combination with 432 provides the USRP which acts as the split 8 O-RU in the O- RAN architecture; 428 is a cooling fan for components inside the housing (if aggregated into a housing); 430 is an RF switch which connects the output of 426 / 432 to the PA 412 when the PA is turned on, and switches the output of 426 / 432 directly to an antenna if the PA is turned off (bypass the PA); and 434 is a media converter which converts Ethernet connection from 420 and 414 to connection 409 to connect to adaptation entity 408. One or more of these other components may also be controlled via the adaptation entity 408.

[0084] The implementations described above with respect to Figures 2, 3, and 4 have focussed on the E2 interface and O-RAN control being performed by a near-RTRIO. However, in some examples, rather than using the E2 interface and the Near- RT RIC for all RAN functions, a Non-RT RIC may be used for controlling RAN functions with relatively loose latency requirements (e.g. one second or higher). In this case the interface between the non-RT RIC and the adaptation entity may be an 01 interface or any other O-RAN-compliant interface that the non-RT RIC is configured to operate with.

[0085] Figure 5 shows an example implementation 500 of an adaptation entity in an O- RAN which allows the non-O-RAN-compliant RAN functions to interact with a Near- RT RIC and a Non-RT RIC and thus allow the RICs to access the non-standardised functions associated with the non-O-RAN-compliant entities. Those entities / interfaces of Figure 5 with the same reference numerals as Figures 2 and 3 have similar characteristics and therefore will may not be described in detail again with respect to Figure 5. Furthermore, the message conversion / processing that enables the RICs to communicate with / access functionality associated with the non-O-RAN-compliant entities that is performed by the adaptation entities of Figure 5 is equivalent to that described with reference to Figures 2 and 3.

[0086] In a similar manner to Figure 3, Figure 5 shows an O-RAN which focusses on the interactions between the RIC and the non-standardised RAN functions 250 provided by non-O-RAN-compliant entities and therefore although not shown, the connections and entities shown in 210 of Figure 2 may also be present in Figure 5.

[0087] In Figure 5 a single adaptation entity 510 communicates with the near-RT RIC 220 (and the xApps running thereon) via an E2 interface 532 and communicates with the non-RT RIC 520 (and the rApps 522, 524, 526 running thereon) via an 01 interface 531. In particular, the E2 agent 511 handles the message conversion between the E2 interface format (i.e. messages received from / intended for the near-RT RIC 220) and the interface format required for communicating with and accessing the functionality of the non-O-RAN-compliant entities using the appropriate APIs from the APIs PA API1 512, PA API2 513, PSU API1 514, PSU API2 515 DU config API 516. Likewise, the 01 agent 517 handles the message conversion between the 01 interface format (i.e. messages received from / intended for the non-RT RIC 520) and the interface format required for communicating with and accessing the functionality of the non-O-RAN-compliant entities using the appropriate APIs from the APIs PA API1 512, PA API2 513, PSU API1 514, PSU API2 515 DU config API 516.

[0088] Compared with Figure 2, the RAN functions (standardised and non-standardised) in Figure 5 are appropriately associated with the Near-RT RIC 220 or the Non-RTRIO 520 according to the latency requirements. In particular, the faster functions are associated with the E2 interface (near-RT RIC), and the slower functions are associated with the 01 interface (non-RT RIC). For example, the faster PA functions (PA on / off 252, gain control 253) are associated with the E2 interface, and the slower PSU and DU related functions (energy measure 254, RU on / off 251 and DU reconfigure 504 are associated with the 01 interface. Furthermore, the near-RT RIC 220 and the non-RT RIC may access different non-standardised functionality of a single non-O-RAN-compliant entity. It can also bee seen from Figure 5 that the near-RT RIC and the non-RT RIC also have the similar standardised RAN functions appropriately associated with each, such as KPM collection 241 , cell config 242 and RAN control 243 associated with the near-RT RIC and KPM collection 241 and RRM policy 502 associated with the non-RT RIC.

[0089] Figure 6 shows an example implementation 600 of an adaptation entity which allows the non-O-RAN-compliant RAN functions to interact with a Near-RT RIC and a Non-RT RIC. In particular, Figure 6 illustrates an implementation where multiple adaptation entities are provided with each handling messaging associated with functionality of only some (e.g. one) of the non-O-RAN-compliant entities. Those entities / interfaces of Figure 6 with the same reference numerals as Figures 2, 3, and 5 have similar characteristics and therefore will may not be described in detail again with respect to Figure 6. Furthermore, the message conversion / processing that enables the RICs to communicate with / access functionality associated with the non-O-RAN-compliant entities that is performed by the adaptation entities of Figure 6 is equivalent to that described with reference to Figures 2, 3, and 5.

[0090] In a similar manner to Figures 3 and 5, Figure 6 shows an O-RAN which focusses on the interactions between the RICs and the non-standardised RAN functions 250 provided by non-O-RAN-compliant entities and therefore although not shown, the connections and entities shown in 210 of Figure 2 may also be present in Figure 6.

[0091] Equivalent to the differences between the structures of Figures 2 and 3 but with near-RT and non-RT RICs, the system of Figure 6 has a structure in which a separate adaptation entity is associated with each of the non-O-RAN-compliant entities and thus the non-standardised functions thereof. In particular, in Figure 6 there is an adaption entity 602 associated with the real-time functions of a PA, which has a E2 agent 512, an adaptation entity 604 associated with the non-real- time functions of the PSU, and an adaptation entity 606 associated with non-real- time aspects of the DU. Due to the presence of two non-real-time adaptation entities 604 and 606 the non-RT RIC 520 has two 01 connections 612 and 614.Each of the adaption entities 604 and 606 associated with the non-RT RIC may have its own 01 agent 608 and 610, respectively.

[0092] The structure of Figure 6 may, like the structure of Figure 3, be considered as a hardware-centric implementation which uses a dedicated E2 or 01 agent to manage the messages between the non-standardised functions and the appropriate RICs. It is also possible to have functions related to one hardware component associated with agents for multiple interfaces if these functions have vastly different latency requirements. However, as described with reference to Figure 3, There is a similar trade-off between deployment flexibility of the adaptation entities and the complexity of the RICapp connections.

[0093] Although the structures of Figures 2 to 6 have been described separately, they may be combined in any suitable manner. Furthermore, the allocation of nonstandardised functionality to particular adaptation entities may take any suitable form and is not limited to the allocations described above. For example, an adaptation entity may handle all RAN functionality messages communicated from / to a RIC (or Rl Capps thereon) and appropriately convert / forward messages depending on their intended target i.e. whether the target is a standardised or nonstandardised functions / O-RAN-compliant or non-O-RAN-compliant entities. In another example, an O-RAN system may have multiple adaptation entities, some of which are integrated into a RIC, some which are standalone entities, and / or some which are integrated into the non-O-RAN-compliant hardware itself. Likewise, an O- RAN system may have a mix of adaptation entities, some that interface with a single non-O-RAN-compliant entity / function and some that interface with multiple non-O-RAN-compliant entities / functions. In some examples, each RICapp of a RIC may have a dedicated adaptation entity or multiple RICapps may be associated with a single adaptation entity. Multiple adaptation entities may also be deployed in different locations within the O-RAN depending on connection characteristics of the non-O-RAN-compliant entities they are interacting with. The adaptation entity and the operation thereof described above may also be used in the context of nonterrestrial networks (NTNs), where the adaptation enables the use of O-RANs in combination with NTNs and entities / functions thereof. The adaptation entity may also be used in other non-standard architectures such as private networks, including factories for example, to enable interoperability between standardised and non-standardised or differently standardised networks / architectures.

[0094] In Figures 2, 3, 5, and 6 the adaptation entities have been described as including a separate interface agent (e.g. E2 agent or any other suitable interface agentdependent on the type of network); however, the internal structure of the adaptation entity may take any suitable form that provides the conversion functionality described above.

[0095] Certain examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Such an apparatus / device / network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g., a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor.

[0096] It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program.

[0097] Figure 7 is a block diagram of an exemplary network entity / function / processing entity that may be used in examples of the present disclosure, such as the techniques disclosed in relation to any of the preceding figures. For example, any of the network entities, network function etc. may be provided in the form of the network entity illustrated in Figure 7. The skilled person will appreciate that a network entity / function may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0098] The entity 700 comprises a processor (or controller) 701 , a transmitter 703 and a receiver 705. The receiver 705 is configured for receiving one or more messages from one or more other network entities, where the messages may include user plane data, control data, or programming data. The transmitter 703 is configured for transmitting one or more messages to one or more other network entities. Theprocessor 701 is configured for performing one or more operations, for example according to any of the operations as described above.

[0099] It will be appreciated that, in each example / embodiment / aspect etc. described above, one or more features or operations may be omitted, modified or moved (e.g., to change the order of the features or the operations), if desired and appropriate.

[0100] Additionally, where the figures illustrating example method flows include text in relation to a specific step / operation, it will be appreciated that this text is simply an example of the corresponding step / operation, where a more general definition (such as may be found in the description of the corresponding step) may apply for the step / operation.

[0101] Additionally, regarding all of the above, one or more features or operations etc. from any example / embodiment may be combined with features or operations from any other example / embodiment. That is, the present disclosure should be considered to include all combinations of examples / embodiments disclosed herein, as appropriate, as well as combinations of individual features within and between each example / embodiment, as appropriate.

[0102] The techniques described herein may be implemented using any suitably configured apparatus and / or system. Such an apparatus and / or system may be configured to perform a method according to any aspect, embodiment or example disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software.

[0103] It will be appreciated that examples of the present disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like.

[0104] It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment and / or aspect disclosed herein, and / or a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection.

[0105] While the disclosure has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the disclosure.

[0106] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.Acronyms and Definitions3GPP 3rdGeneration Partnership Project 5G 5thGeneration 5GC 5G Core 5QI 5G QoS Identifier 5GS 5G System 5GSM 5G System Session Management 5GMM 5G System Mobility Management AF Application Function Al Artificial Intelligence AM Acknowledged Mode AMF Access and Mobility Management Function AS Access Stratum ASP Application Service Provider ATG Air-To-Ground AUSF Authentication Server Function BBU Base Band Unit CDN Content Delivery Network CNF Container Network Function DCAF Data Collection Application Function DNAI Data Network Access Identifier DNN Data Network Name DNS Domain Name Server DRB Data Radio Bearer eNB Evolved Node B EPC Evolved Packet Core FEC Forward Error Correction FQDN Fully Qualified Domain Name GBR Guaranteed Bit Rate gNB Next generation Node B GPIO General Purpose Input / Output GPSI Generic Public Subscription Identifier HSS Home Subscriber Service IAB Integrated Access and Backhaul ID Identity / ldentifier lloT Industrial Internet of Things IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity IP Internet Protocol l-SMF Intermediate SMF KPM Key Performance Measurement LADN Local Area Data Network LL SSM Lower Layer SSM MBMS Multimedia Broadcast / Multicast Service MBS Multicast / Broadcast Service MBSF Multicast / Broadcast Service Function MBSTF Multicast / Broadcast Service Transport Function MB-SMF Multicast / Broadcast Session Management Function MB-UPF Multicast / Broadcast User Plane Function MCCH Multicast Control Channel MTCH Multicast Traffic Channel ML Machine Learning MME Mobility Management Entity MN Master Node MNF Monitoring Network Function MNO Mobile Network Operator MT Mobile Termination NAS Non-Access Stratum NEF Network Exposure Function NRF Network Repository Function NG-RAN Next Generation Radio Access NetworkNG-eNB Next Generation eNBNGAP Next Generation Application ProtocolNSA Non-StandaloneNSSF Network Slice Selection FunctionNTN Non-Terrestrial NetworksNW NetworkNWDAF Network Data Analytics FunctionO-RAN Open Radio Access NetworkOS Operating SystemOSAPP OS ApplicationPCF Policy Control FunctionPCO Protocol Configuration OptionsPDR Packet Detection RulePDU Protocol Data UnitPLMN Public Land Mobile NetworkPTM Point To MultipointPTP Point to PointQFI QoS Flow Identifier (ID)QoS Quality of ServiceRACH Random Access ChannelRAN Radio Access NetworkRRC Radio Resource ControlRSD Route Selection DescriptorSA StandaloneSDAP Service Data Adaptation ProtocolSDU Service Data UnitSGW Serving GatewaySIM Subscriber Identity ModuleSLA Service Level AgreementSM Session ManagementSMF Session Management FunctionSN Secondary NodeS-NSSAI Single Network Slice Selection Assistance InformationSSB Synchronization Signal BlockSSM Source Specific IP Multicast addressSSC Session and Service ContinuitySRB Signaling Radio BearerSUPI Subscription Permanent IdentifierTA Tracking AreaTAI Tracking Area IdentityTE Terminal EquipmentTM Transparent ModeTMGI Temporary Mobile Group IdentityTS Technical SpecificationUAV Unmanned Aerial VehicleUDM Unified Data ManagerUDR Unified Data RepositoryUE User EquipmentUL UplinkUM Unacknowledged ModeUP User PlaneUPF User Plane FunctionURLLC Ultra-Reliable and Low-Latency CommunicationURSP UE Route Selection PolicyUSRP Universal Software Radio Peripheral

Claims

1. CLAIMS1. An adaptation entity for an Open Radio Access Network (O-RAN) for interfacing between a Radio Access Network (RAN) Intelligent Controller (RIC) and a non-O-RAN- compliant RAN entity, wherein the adaptation entity is configured to: receive a first message from an application of the RIC (RICapp), the first message having an O-RAN-compliant format associated with the RIC; convert the first message to a second message having a non-O-RAN-compliant format associated with the non-O-RAN-compliant RAN entity; and transmit the second message to the non-O-RAN-compliant RAN entity.

2. The adaptation entity of claim 1 , wherein the first message is received via an O- RAN-compliant interface associated with the RIC.

3. The adaptation entity of claim 2, wherein the O-RAN-compliant interface is one of an E2 interface, an 01 interface, an A1 interface, and an Open Fronthaul interface.

4. The adaptation entity of any preceding claim, wherein the adaptation entity is configured to receive the first message and convert the first message to the second message based on a Application Programming Interface (API) associated with the non-O- RAN-compliant RAN entity.

5. The adaptation entity of any preceding claim, wherein the second message is transmitted via a non-O-RAN-compliant interface associated with the non-O-RAN- compliant RAN entity.

6. The adaptation entity of claim 5, wherein the converting includes configuring one or more of a voltage, frequency, and timing of the second message based on the non-O- RAN-compliant interface.

7. The adaptation entity of any preceding claim, wherein the adaptation entity interfaces with only the non-O-RAN-compliant RAN entity among one or more non-O-RAN- compliant RAN entities.

8. The adaptation entity of claim 7, wherein the adaptation entity is included in the single non-O-RAN-compliant RAN entity.

9. The adaptation entity of any of claims 1 to 6, wherein the adaptation entity is configured to interface with a plurality of non-O-RAN-compliant entities using messages having a non-O-RAN-compliant format.

10. The adaptation entity of claim 9, wherein each of the plurality of non-O-RAN- compliant entities has an associated API and the adaptation entity is configured to convert the first message to the second message based on the API associated with the non-O- RAN compliant entity.

11. The adaptation entity of claims 9 or 10, wherein the adaption entity is provided outside of the RIO and the plurality of non-O-RAN-compliant RAN entities.

12. The adaptation entity of claims 9 or 10, wherein the adaptation entity is included in the RIC.

13. The adaptation entity of any preceding claim, wherein the first message includes a monitoring identifier or a parameter identifier associated with the non-O-RAN-compliant RAN entity or a functionality of the non-O-RAN-compliant RAN entity, and the converting includes generating the second message based on the monitoring identifier or the parameter identifier and the API associated with the non-O-RAN-compliant RAN entity.

14. The adaptation entity of any preceding claim, wherein the RIC is a near-real-time RIC and the RICapp is an xApp of the RIC.

15. The adaptation entity of any of claims 1 to 13, wherein the RIC is a non-real-time RIC and the RICapp is an rApp of the RIC.

16. The adaptation entity of any preceding claim, wherein the first and second messages are for control of and / or monitoring of the non-O-RAN-compliant RAN entity and / or a function associated with the non-O-RAN compliant RAN entity.

17. The adaptation entity of any preceding claim, wherein the adaptation entity is at least partially implemented in hardware (e.g. ASIC, CPU, GPU etc.).

18. The adaptation entity of any preceding claim, wherein the non-O-RAN-compliant RAN entity includes at least one of a distributed unit (DU), a radio unit (RU), a central unit (CU), a power supply unit (PSU), a power amplifier (PA), and an eNB / gNB.

19. The adaptation entity of any preceding claim, wherein the second message is transmitted to the non-O-RAN-compliant RAN entity via an Internet Protocol (IP) network.

20. The adaptation entity of any preceding claim, wherein the adaptation entity is configured to: receive a third message from the non-O-RAN-compliant RAN entity, the third message having a non-O-RAN-compliant format associated with the non-O-RAN- compliant RAN entity; convert the third message to a fourth message having an O-RAN-compliant format associated with the RIC; and transmit the fourth message to an application of the RIC (e.g. RICapp).21 . A method of an adaptation entity of an Open Radio Access Network (O-RAN) for interfacing between a Radio Access Network (RAN) Intelligent Controller (RIC) and a non- O-RAN-compliant RAN entity, the method including: receiving a first message from an application of the RIC (RICapp), the first message having an O-RAN-compliant format associated with the RIC; converting the first message to a second message having a non-O-RAN-compliant format associated with the non-O-RAN-compliant RAN entity; and transmitting the second message to the non-O-RAN-compliant RAN entity.

22. An Open Radio Access Network (O-RAN) including a RAN Intelligent Controller (RIC), a non-O-RAN-compliant RAN entity, and an adaptation entity for interfacing between the RIC and the non-O-RAN-compliant RAN entity, wherein RIC includes an application (RICapp) and the RICapp is configured to generate and transmit a first message to the adaptation entity, the first message having an O-RAN-compliant format associated with the RIC; wherein the adaptation entity is configured to receive the first message; convert the first message to a second message having a non-O-RAN- compliant format associated with the non-O-RAN-compliant RAN entity; and transmit the second message to the non-O-RAN-compliant RAN entity, and wherein the non-O-RAN-compliant RAN entity is configured to receive the second message and perform a function based on the second message.

23. The RAN of claim 22, wherein the O-RAN the includes a distributed unit (DU), a radio unit (RU), a central unit (CU), and the non-O-RAN-compliant RAN entity is associated with the RU.

24. A method of operation of an Open Radio Access Network (O-RAN) including a RAN Intelligent Controller (RIC), a non-O-RAN-compliant RAN entity and an adaptation entity, the method comprising: generating, by the RIC, a first message, the first message having an O-RAN- compliant format associated with RIC; transmitting, by the RIC, the first message to the adaptation entity; receiving, by the adaptation entity, the first message; converting, by the adaptation entity, the first message to a second message having a non-O-RAN-compliant format associated with the non-O-RAN-compliant RAN entity; transmitting, by the adaptation entity, the second message to the non-O-RAN- compliant RAN entity; receiving, by the non-O-RAN-compliant RAN entity, the second message; and performing, by the non-O-RAN-compliant RAN entity, a function based on the second message.

25. The adaptation entity of any of claims 1 to 20, the method of claim 21 , the O-RAN of claims 22 and 23, or the method of claim 24, wherein the non-O-RAN-compliant RAN entity is a RAN entity that provides at least one RAN function that is not supported by / not directly accessible by the RIC via an O-RAN-compliant interface.

26. A computer-readable recording medium having stored thereon computer-readable instructions which when executed by a computer cause the computer to perform the method of claims 21 or 24.

Images