A method for facilitating one or more application processes in a network function of an open radio access network, a framework for performing the method, and a computer program

Abstract

A method of facilitating one or more application processes in a network function of an Open Radio Access Network, Open RAN, is provided. Each of the one or more application processes is allocated hardware resources from a plurality of hardware resources available to the network function. The method comprises defining an interface between the one or more application processes and the allocated hardware resources. The interface is configured to communicate instructions and data between each of the one or more application processes and the allocated hardware resources via one or more underlying physical interfaces. The interface defines one or more methods for carrying out the instructions. Each instruction invokes a method defined by the interface. The interface comprises a plurality of rules for translating the instructions and data. Each rule is associated with a method and one or more corresponding hardware resources for performing the method.

Description

A method for facilitating one or more application processes in a network function of an Open Radio Access Network, a framework for performing the method, and a computer programField of the invention

[0001] The present invention relates to management of resources in network function deployments of an Open Radio Access Network. In particular, the invention relates to methods of facilitating application processes in network function deployments where hardware resources having particular processing capabilities are available.GlossaryRAN - Radio Access NetworkMNO - Mobile Network OperatorGPU - Graphics Processing UnitO-RAN - Open RAN AllianceO-DU - Open Distributed UnitO-CU - Open Central UnitO-RU - Open Radio UnitPHY - Physical LayerMAC - Medium Access ControlRLC - Radio Link ControlPDCP - Packet Data Convergence ProtocolRRC - Radio Resource ControlSDAP - Service Data Adaptation ProtocolOS - Operating SystemAPI - Application Programming InterfaceSMO - Service Management and OrchestrationDMS - Deployment Management ServicesNF - Network FunctionIMS - Infrastructure Management Services vRAN - virtualized RANCPU - Central Processing UnitNAS - Non-Access StratumLLC - Logical Link ControlSNDCP - Sub Network Dependent Convergence Protocol PCIe - Peripheral Component Interconnect Express OCP - Open Core ProtocolRIC - RAN Intelligent ControllerUE - User EquipmentBS - Base StationABS - Advanced Base StationBTS - Base Transceiver StationBSS - Basic Service SetESS - Extended Service SetAP - Access PointNB - Node B (Radio Base Station Receiver) eNB - Evolved Node B gNB - Next-Generation Node BTRP - Transmission and Reception PointPS - Processing ServerTE - Terminal EquipmentMS - Mobile StationMT - Mobile TerminalUT - User TerminalSS - Subscriber StationPDA - Personal Digital AssistantCDMA - Code Division Multiple AccessFDMA - Frequency Division Multiple AccessTDMA - Time Division Multiple AccessOFDMA - Orthogonal Frequency Division Multiple Access SC-FDMA - Single Carrier Frequency Division Multiple Access MC-FDMA - Multicarrier Frequency Division Multiple Access UTRA - Universal Terrestrial Radio AccessGSM - Global System for Mobile Communications (2G)GSMA - GSM AssociationGPRS - General Packet Radio ServiceEDGE - Enhanced Data Rates for GSM EvolutionIEEE - Institute of Electrical and Electronics Engineers E-UTRA - Evolved UTRAUMTS - Universal Mobile Telecommunications System (3G)E-UMTS - Evolved UMTS3GPP - 3rd Generation Partnership Project DL - Downlink UL - UplinkLTE - Long Term Evolution (4G)LTE-A - LTE-AdvancedNR - New Radio (5G)FDD - Frequency Division DuplexTDD - Time Division DuplexCRS - Cell-specific Reference SignalCSI-RS - Channel State Information Reference Signal FPGA - Field-Programmable-Gate-Array ASIC - Application-Specific-lntegrated-Circuit DSP - Digital-Signal-ProcessorCD-ROM - Compact Disc Read-Only MemoryDVD-ROM - Digital Versatile Disc Read-Only Memory ROM - Read-Only MemoryRAM - Random-Access MemoryEEPROM - Electrically Erasable Programmable Read-Only Memory EPROM - Erasable Programmable Read-Only MemoryBackground

[0002] Open RAN is a technology architecture concept directed to decoupling the hardware and software components of a Radio Access Network (RAN). It is a RAN that includes open interoperable interfaces and virtualization. In prior art (Non-Open) RANs, the hardware and software components are typically proprietary. Non-Open RAN equipment is generally obtained from a single vendor to ensure seamless functionality, security, and efficiency. In contrast, Open RAN introduces open standards for both hardware and software, enabling interoperability among various network elements. For Mobile Network Operators (MNOs), Open RAN holds strategic importance as it promotes vendor diversity, allowing the integration of new suppliers and enhancing supply chain resilience. It also brings energy efficiency gains by enabling targeted improvements in specific areas of the RAN. Furthermore, Open RAN facilitates innovation and competition by providing a more dynamic and efficient network environment. Additionally, it provides an opportunity for collaboration with specialist suppliers and facilitates resource optimization by allowingupgrades to software, without necessitating hardware replacements. Open RAN is important in the long-term network innovation strategy of MNOs, offering energy efficiency, supply chain diversification, resilience enhancement, and facilitating innovation and competition.

[0003] Fig. 1 illustrates some of the elements of an example Open RAN system 100, which is implemented as a cloud computing platform (O-Cloud). The system 100 may be described with reference to different hardware and software layers of the platform.

[0004] At the O-Cloud Node layer 110, the system comprises one or more physical infrastructure nodes 120A, 120N that meet O-RAN requirements. Each physical infrastructure node 120A comprises computing 121 , networking 122, GPU 123, and storage 124 components, alongside acceleration technologies 125 for RAN operations (such as forward error correction and other computationally intensive operations that are offloaded to dedicated hardware). Each physical infrastructure node 120A, 120N is configured to host the relevant O-RAN network functions 150, 160, which are implemented at the Open RAN application layer 140. The network functions 150, 160 implemented at the Open RAN application layer 140 may include O-CU 160, O-DU 150, and O-RU.

[0005] The O-CU, O-DU and O-RU network function deployments comprise functional elements for processing different protocols in the RAN protocol stack. The O-DU 150 comprises:• a High-PHY component 151 to perform the scrambling, modulation, layer mapping, precoding, resource element mapping, and I / O compression elements of the PHY layer;• a MAC component 152; and• a RLC component 153.

[0006] The O-CU comprises:• a PDCP component 161 ; and• a RRC / SDAP component 162.

[0007] The O-DU 150 may further comprise an Open RAN fronthaul interface to connect the O-DU to one or multiple O-RUs.

[0008] At the O-Cloud hypervisor or containers I OS layer 130, there exists a collection of cloud functions to enable the Open RAN applications 150, 160 to run on the one or more O-Cloud hardware nodes 120A. The cloud functions may comprise supporting software components, such as an operating system, Containers (stand-alone executable software packages), a Container Orchestration Platforms (such as Kubernetes), a container runtime, and the like. The cloud functions may also include the corresponding management and orchestration functions.

[0009] The O-Cloud serves as a fundamental component for facilitating cloud computing capabilities within the context of RAN network functions. It comprises both hardware and software elements. In particular, its software exposes open APIs, fostering interoperability and flexibility across various vendor solutions. With a decoupled architecture, the O-Cloud allows for sourcing hardware from different vendors, promoting neutrality and flexibility in hardware selection. It supports Service Management and Orchestration (SMO), enabling homing decisions and selecting Deployment Management Services (DMS) for Network Function (NF) Deployments. The DMS handles workload placement, lifecycle management, and resource allocation within O-Cloud Node Clusters, while Infrastructure Management Services (IMS) ensure the infrastructure's availability, reliability, and performance. Moreover, the O-Cloud offers automation capabilities, enhancing efficiency and reducing manual intervention, ultimately supporting efficient resource utilization and scalability for RAN network functions in a cloud-native environment.

[0010] US2023318904A1 describes cross-platform programmable network communication in a Radio Access Network. However, this document does not address the issue of efficiently allocating the available hardware resources to the network function applications. The present disclosure aims to address this issue.Summary

[0011] The present disclosure provides an interface for facilitating application processes in an Open Radio Access Network.

[0012] A method of facilitating one or more application processes in a network function of an Open Radio Access Network, Open RAN, is provided. Each of the one or more application processes is allocated hardware resources from a plurality of hardware resources available to the network function. The method comprises defining an interfacebetween the one or more application processes and the allocated hardware resources. The interface is configured to communicate instructions and data between each of the one or more application processes and the allocated hardware resources via one or more underlying physical interfaces. The interface defines one or more methods for carrying out the instructions. Each instruction invokes a method defined by the interface. The interface comprises a plurality of rules for translating the instructions and data. Each rule is associated with a method and one or more corresponding hardware resources for performing the method.

[0013] The proposed method provides a flexible way of defining an interface for brokering communications between application processes running on a network function and the underlying hardware resources allocated to the network function. The interface may be configured to manage the sending of the instructions and data via the underlying physical interface so that the application process is not required to manage hardware communications over a physical layer interface for a variety of different hardware types. To facilitate this, the interface definition comprises rules for translating the instructions from the application process to a format understood by the corresponding hardware resource.

[0014] The one or more application processes may be application threads. Each application process may comprise a plurality of instructions. Each application process may be executed as part of an application (also referred to as a computer program, e.g., an Open RAN application). The application may be defined in human-readable source code that is compiled to generate machine code. The machine code may be executed by one or more of the plurality of hardware resources to carry out the instructions.

[0015] The “methods” (defined in the interface) may also be referred to as “procedures”.

[0016] In one example, the interface may define a method to start channel coding. The interface may receive an instruction invoking the method from an application process and configure the appropriate hardware to carry out the instruction.

[0017] The method may further comprise communicating instructions and data between each of the plurality of application processes and the allocated hardware resources.

[0018] Each rule may be associated with one or more templates for formatting data to perform the associated method using the one or more hardware resources and / or providedata to the application process. Each template may correspond to a respective hardware resource.

[0019] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may comprise translating the instructions and data by identifying, for each instruction, a rule associated with the method invoked by the instruction, identifying a hardware resource for carrying out the instruction, and formatting data associated with the instruction according to a template associated with the rule and corresponding to the identified hardware resource.

[0020] The one or more underlying physical interfaces may comprise one or more of:PCIe;OCP; and ethernet.

[0021] The plurality of hardware resources may comprise one or more compute kernels and / or RAN processing units, RPUs. Each compute kernel and / or RPU may comprise a plurality of physical hardware elements.

[0022] The plurality of physical hardware elements may comprise one or more: memory units;Central Processing Units, CPUs;CPU cores;Digital Signal Processors, DSPs;Field Programmable Gate Arrays, FGPAs;Application-Specific-lntegrated-Circuits, ASICs;Graphics Processing Units, GPUs; and / or accelerators.

[0023] Each compute kernel and / or RPU may be configured to implement a Hardware Abstraction Layer, HAL, to communicate instructions and data with the plurality of physical hardware elements.

[0024] The instructions and data may comprise a plurality of instructions and data associated with each instruction. The data may provide details of how the instructionshould be carried out. In other words, the instruction may be a reference to an method defined by the interface and the data may be parameters provided to the method.

[0025] Each of the plurality of hardware resources may be associated with an address space particular to a physical location of the respective hardware resource. Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may comprise communicating instructions and data with the application process using an address space of the application process. Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise communicating instructions and data with each of the plurality of hardware resources using the address space particular to the physical location of the respective hardware resource.

[0026] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise establishing a remote connection between the application process and each of the plurality of hardware resources.

[0027] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise serializing and / or deserializing the data for communication via the one or more underlying physical interfaces.

[0028] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise marshalling and / or demarshalling the data.

[0029] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise performing network address translation to facilitate communication between the one or more application processes and the allocated hardware resources, so that the allocated hardware resources appear to the respective application processes as if they are in the same address space (i.e., in the same location).

[0030] The interface may be used for facilitating communication between a network function (such as a DU) and the L1 platform. Nevertheless, the interface is not restricted toonly communicating between network function and hardware platform and may also be used for inter-process communication. For example, the interface may provide a means for application processes to utilise other application services, which may be provided locally or elsewhere in the network.

[0031] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise performing network address translation to facilitate communication between the one or more application processes and the allocated hardware resources, so that the allocated hardware resources appear to the respective application processes as if they are in the same address space (in the same location).

[0032] Each application process may be allocated hardware resources from the plurality of hardware resources based on one or more processing requirements of the respective application process and one or more processing capabilities of the allocated hardware resources.

[0033] The processing capabilities may comprise one or more of: an instruction set of the hardware resource; signal processing capabilities of the of the hardware resource; packet processing capabilities of the of the hardware resource; one or more communications protocols for which processing capabilities are supported; and one or more technology standards for which processing capabilities are supported.

[0034] The method may further comprise receiving, from each of the one or more application processes, a request for hardware resources. The request may comprise an indication of the processing requirements of the respective application process. The method may further comprise dynamically allocating the hardware resources to the respective application process in response to the request.

[0035] The method may further comprise dynamically configuring hardware resources from the plurality of hardware resources, based on the one or more processing capabilities of the respective hardware resource and the one or more processing requirements of one or more application processes to which the hardware resource has been allocated.

[0036] Defining the interface may comprise parsing an interface definition comprising source code. The source code of the interface definition may be written in a human- readable programming language and may define the plurality of rules for translating instructions and data communicated from the one or more application processes via the interface to the one or more allocated hardware resources via the one or more underlying physical interfaces. Defining the interface may further comprise generating machine code for execution by one or more of the plurality hardware resources, wherein executing the machine code causes the respective hardware resource to carry out the instructions.

[0037] In other words, the rules may be for formatting data to carry out the instruction on a corresponding hardware resource of the one or more hardware resources. The rules may be for translating the instructions and data according to one or more templates.

[0038] The process of generating the interface from the interface definition source code may be referred to as “compiling” the interface. The interface may be compiled by a compiler. The compiler may be written in any one or a number of programming languages, such as C++ or Python.

[0039] The application may be an OpenRAN application.

[0040] The machine code generated for each of the rules may comprise a different version of the machine code for each of the hardware resources.

[0041] The machine code generated for each of the rules may be based on the processing capabilities of the hardware resource.

[0042] Each rule may be associated with one or more templates. Each different version of the machine code may correspond to a respective template.

[0043] The processing capabilities of a first hardware resource of the plurality of hardware resources may be different to the processing capabilities of a second hardware resource of the plurality of hardware resources.

[0044] The network function may comprise one or more applications and each application may comprise a plurality of the application processes. Each application may be generated by compiling application source code written in a human-readable programming language.

[0045] The method may further comprise automatically generating a client-side stub based on the source code of the interface definition. The one or more methods may be defined in the client-side stub. The client-side stub may define one or more proxies for invoking the associated methods via the interface.

[0046] The method may further comprise automatically generating one or more server-side skeletons based on the source code of the interface definition. Each server-side resource may comprise a driver comprising a server-side skeleton. Each server-side skeleton may define one or more proxies for carrying out instructions communicated via the interface.

[0047] In some examples, the server-side skeleton may include interactions with compute kernels / RPUs (hardware resources) on specialized hardware. In such scenarios, the generated server-side skeleton code may interface with hardware services. The server-side client may refer to the server-side code generated by the interface compiler that defines how the server should handle incoming requests (which may be invocations of methods translated by the interface to remote procedure calls, RPCs, on remote hardware resources). The server-side skeleton may also be referred to as a "hardware skeleton". This skeleton code may include the methods defined in the interface (e.g., service base classes) but without the actual implementation. The application developer may then fill in the logic for these methods.

[0048] A specific example of a specialized hardware device, such as a crypto RAN Processing Unit, which exposes its capabilities via an interface, is provided. The interface definition file could be RAN_crypto_service.idl, which may define crypto operations with crypto service interfaces. There may be auto generated definitions of the interface and data structures for the crypto operations and service interface definitions. There may be automatically generated crypto service stubs and skeletons. Serialization / deserialization of data may be performed for crypto messages.

[0049] An interface compiler may generate stubs and skeletons based on the interface definitions. The server-side skeleton may include methods that developers would need to implement. The interface compiler may generate server skeletons (or service base classes), in the form of abstract methods that correspond to the methods defined by the interface. Developers may then implement these methods in a derived class, withoutmodifying the auto generated skeleton code itself. The client-side application may call the remote methods using the client-side stubs.

[0050] Each client-side stub may correspond to a different programming language. In some examples, the interface definition file may be processed by an interface compiler. Here the compiler may generate both the client-side stubs and server-side skeletons in the target programming languages (e.g., C / C++, Python, Java, and the like).

[0051] Each server-side skeleton may correspond to a different hardware resource. As mentioned above, the interface compiler may generate both stubs and skeletons based on the interface definition (e.g., in one or more interface definition files). The server skeletons (service base classes) may include abstract methods that correspond to the methods defined by the interface. Developers may then implement these methods in a derived class, without modifying the generated skeleton code itself.

[0052] In the case of the crypto example provided above, the interface may define crypto methods with crypto service interfaces. The auto generated client-side stub code may define the methods that may be invoked by the application processes to perform remote crypto processing on a corresponding crypto hardware resource (compute kernels / RPUs) in the target programming language. The automatically generated server-side skeleton may include abstract crypto methods (service base classes for crypto operations) in the target programming language that correspond to the crypto methods defined in the interface. Developers then implement these methods in a derived class, without modifying the generated skeleton code itself.

[0053] In some examples, each interface is domain-specific. In other words, a different interface is provided for each application. In other examples, different applications may each use a common interface.

[0054] The interface definition may be applicable to multiple different programming languages and may be used to generate different stubs for each programming language. In this way, the applications are not restricted to one particular programming language and a broader range of applications may be able to run on the network function, making use of the underlying hardware resources via the interface.

[0055] In some examples, a flexible interface may be provided that facilitates invocation of methods in the opposite direction, i.e. the one or more hardware resources may invoke methods that are implemented by the application processes. In other words, the client-side nodes may also offer server capabilities, and server-side nodes (hardware resources, e.g. crypto compute kernel) may implement both server and client nodes. This may offer a more flexible architecture that could address several use cases, such as those described below. The approach may lead to a more complex distributed architecture but may also provide practical benefits in some scenarios.

[0056] One example of a practical use case in which the above option may provide benefits is for receiving responses on the client-side. Typically, a straightforward method used in most remote procedure call frameworks would be for client-side stub to directly handle the server's responses as part of the remote procedure call interactions. However, in scenarios where a RAN compute kernel / hardware resource requires a significant amount of time to perform an operation, it might be more efficient to process the response asynchronously. In order to do so, the client would send a request to the server (the hardware resource) and then acts as a server itself to receive a callback with the results, once the hardware resource has completed the operation.

[0057] Another example of a practical use case in which the above option may provide benefits is for service discovery / registration. As part of dynamic discovery, as a new hardware resource becomes available, it may register itself with the RAN controller. This node could implement a server that other clients can query to discover available services.

[0058] The method may further comprise automatically generating one or more server-side stubs and / or client-side skeletons, based on the source code of the interface definition. Each server-side stub may define one or more proxies for the hardware resources to invoke methods via the interface and each client-side skeleton may define one or more proxies for causing the application processes to carry out instructions communicated via the interface.

[0059] The interface definition may comprise one or more interface definition files.

[0060] An interface compiler may process the interface definition (e.g., interface definition file) where the compiler would generate both the client-side stubs and server-sideskeletons in the target programming language. This language binding could be to any of the target languages such as C / C++, Python, Java, and the like.

[0061] By providing an interface definition written in a human-readable programming language, the proposed methods may provide a way for application developers to flexibly define parameters of the interface so that the applications running on the network functions can effectively use the interface to access the underlying hardware resources.

[0062] The interface definition may be used to define how underlying hardware resources are accessed and which methods (the methods in the auto generated stub that are invoked by the application) can access the resources. The interface definition may provide a way to link the methods to the underlying hardware by binding the two together and defining the rules for translating between the application process and the hardware resources. In this way, the interface may abstract implementation details of the underlying physical hardware away from the application processes. This may make development of applications more straightforward and may enhance interoperability of the applications with different underlying hardware resources.

[0063] In the context of the above interface definition methods and remote procedure calls, linking a method defined by the interface to an underlying hardware resource may be referred to as “resource binding”. Resource binding may be used to describe the process of associating high-level interface constructs like methods or services (e.g., defined in an interface definition file) with specific low-level resources or implementations, which can include hardware resources. The resource binding may comprise the rules and templates that link a method defined by the interface to an underlying hardware resource.

[0064] On the other hand, the term “language binding” may be used to refer to the how interface constructs translate to the syntax and semantics of the target programming language.

[0065] In summary, resource binding could be used to specify how the methods defined by the interface (also referred to as “operations” or “procedures”) translate to operations on the underlying resources. Language binding refers to how interface constructs translate to the syntax and semantics of the target programming language.

[0066] The interface definitions may be adapted in a straightforward manner to extend operability of the defined methods to new types of hardware resource. Moreover, new methods can be added to existing interfaces to make use of the hardware resources already supported by the interface. For example, when new technical specifications are released (e.g., 5G / 6G) the interface definitions may be updated to support new methods required by these specifications.

[0067] Communicating instructions and data between each of the plurality of application processes and the allocated hardware resources may comprise receiving instructions and data from an application process via a client-side stub, translating the instructions and data according to a rule corresponding to the client-side stub and a template corresponding to the server-side skeleton and sending the instructions and data to the hardware resource via the server-side skeleton. In some examples, the application processes may call the remote methods using the client-side stubs. Developers of applications running on the network function may use the client-side stubs in their client applications to make remote calls.

[0068] Communicating instructions and data between each of the plurality of application processes and the allocated hardware resources may comprise receiving data from a hardware resource via a server-side skeleton, translating the data according to a template corresponding to the server-side skeleton and a rule corresponding to a client-side stub, and sending data to an application process via the client-side stub.

[0069] As well as receiving instructions from the application and sending instructions to the hardware, the interface may also operate in the opposite direction. Data from the hardware may be formatted and returned to the application process.

[0070] A framework for facilitating one or more application processes in a network function of an Open Radio Access Network, Open RAN, is provided. The framework is configured to perform any of the methods described above.

[0071] A computer program is also provided. The computer program comprises instructions that, when executed on a processor, cause the processor to perform the any of the methods described above.

[0072] Another method of facilitating one or more application processes in a network function of an Open Radio Access Network, Open RAN, is provided. Each of the one or more application processes is allocated hardware resources from a plurality of hardware resources available to the network function. Each of the plurality of hardware resources is associated with an address space particular to a location of the respective hardware resource. The method comprises communicating instructions and data between each of the one or more application processes and the allocated hardware resources by sending instructions and data to each of the plurality of hardware resources via one or more underlying physical interfaces using the address space particular to the location of the respective hardware resource, so that instructions and data from the application process are routed to the allocated hardware resources, without requiring the application process to be aware of the address space particular to the location of the respective hardware resource.

[0073] The proposed method allows the Open RAN framework to seamlessly integrate remote hardware with application processes running on network functions, as if the remote hardware is located on the same physical hardware platform as the network function. The framework communicates with the application processes via a local address space and communicates with remote hardware resources via a remote address space (and via the underlying physical interfaces). The framework facilitates seamless communication, so that the application process is not aware that the hardware resources are remote.

[0074] As a result of the functionality provided, the client application may be agnostic of the server's address space. The server is providing some service / hardware resource (e.g. RAN crypto processing) that may be invoked by the client application. The service that the application is invoking may or may not exist in the same address space. This means that the client interacts with the server as though the server's methods are local to the client's address space, even though, in reality, the server may be running on a different machine, in a different address space.

[0075] The proposed inter-process communication framework may make use of the remote procedure call mechanism described above to abstract the complexities of network communication, so that the application processes are not required to be aware of these complexities. The client application calls a method on the client-side stub as if it were a local procedure call. The inter-process communication framework may make use of the remote procedure call mechanism to handle the serialization of the call, transmission overthe interface / network (could be on same machine or elsewhere), execution on the server, and return of the results.

[0076] The address space for the hardware resource may be the same as the address space of the application process. This may be case where the hardware resource (e.g., a compute kernel) is located in the same physical location as the Open-RAN application.

[0077] The location of the hardware resource may be a geographic location.

[0078] The address space of the hardware resource may be a remote address space. The geographic location of the hardware resource may be anywhere accessible via a network (e.g., the Internet).

[0079] The address space of the application process may be an address space of the network function. As a result, each of the application processes of the network function may each have the same address space.

[0080] In some examples, the method may comprise locally mounting a file system from a remote server, so that the remote file system may be accessed as if it were a local file system.

[0081] The application process is not aware of the location of the hardware resource and behaves the same whether the hardware resource is local or remote. The instructions could be executed by hardware resources on the same processor as the application process or could be running somewhere else in same machine, on another machine, across an ethernet boundary, or anywhere accessible via a network.

[0082] A client-side application (which may comprise one or more application processes) may interact with the server-side service (underlying hardware resources) through invoking methods defined in the auto-generated client-side stub. In other words, the client-side application may use the client-side stub code to invoke the method, which the interface then translates in order to execute a remote method towards the corresponding server providing the service (hardware resources, which may include compute kernels / RPUs).

[0083] In an Open-RAN system, a developer of a network function application (on the client-side) may define the desired remote service using an interface definition file. This file may specify the methods, parameters, and return types of the service.

[0084] The interface compiler (which may be provided as part of the Soft Fabric Processor) may be used to process the interface definition file and generate code in the target programming language (C / C++, Python, Java, etc.) to provide a client-side stub and one or more server-side skeletons.

[0085] The client-side stub is a piece of code resides on the client-side and provides a local interface for the remote service (the RAN hardware resources). The client-side stub includes method definitions that correspond to the service methods defined in the interface definition file.

[0086] The server-side skeleton is code that resides on the server-side and acts as a bridge between the client-side stub calls and the actual service implementation provided by the hardware resource (e.g., RAN compute kernel / RPU).

[0087] The interface definitions may be specific to Open-RAN domains and may be referred to as RAN interfaces defined in RAN interface definitions, which may be provided in one or more RAN interface definition files. The RAN interface definition files may be parsed by a RAN interface compiler to generate the stubs and skeletons.

[0088] The interface facilitates interaction between a “client” (application process of a network function) and a “server” (hardware resource, such as a compute kernel / RPU). When the client application (RAN network function) needs to make use of a remote service (or local service via the same interface), it may invoke methods on the client-side stub.These methods may look and behave like regular local function calls for the client program.

[0089] The client-side stub code may serialize (package) the method parameters into a message format suitable for transmission across the interface / network. Then, it may send the packaged message across the interface / network to the server-side.

[0090] Alternatively, the RPC framework may decide not to perform serialization if the client and server are on same processor address space (same hardware). This approach might come at the expense of not having a consistent programmer interface. Therefore, achoice of either approach may be provided to improve flexibility and the approach may be selected based on specific requirements.

[0091] On the server-side (RAN hardware resource / RAN compute kernel), the hardware resource receives the message containing the method call and parameters. The serverside stub may deserialize the message, extracting the method name and parameters.

[0092] The server stub may be described as essentially a bridge, invoking the actual service implementation on the server that corresponds to the called method serviced by the RAN compute kernel (hardware resource).

[0093] Service implementation executes the required functionality. After execution is complete, the server stub may send the message containing the return value back to the client (the return message may also get serialized).

[0094] The client stub may deserialize the message, extracting the return value and any data to make that available to the client application (network function).

[0095] The method may further comprise communicating instructions and data between each of the plurality of application processes and the allocated hardware resources.

[0096] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise receiving instructions and data from the application process using an address space of the application process.

[0097] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise establishing a remote connection between the application process and each of the allocated hardware resources.

[0098] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise serializing and / or deserializing the data for communication via the one or more underlying physical interfaces.

[0099] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise marshalling and / or demarshalling the data.

[0100] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may further comprise performing network address translation to facilitate communication between the one or more application processes and the allocated hardware resources, so that the allocated hardware resources appear to the respective application processes as if they are in the same address space (i.e., in the same location).

[0101] The instructions and data may be communicated via an interface between each of the one or more application processes and the hardware resources allocated to the respective application process. The interface may define one or more methods for carrying out the instructions. Each instruction may invoke a method defined by the interface. The interface may comprise a plurality of rules for translating the instructions and data. Each rule may be associated with a method and one or more corresponding hardware resources for performing the method.

[0102] Each rule may be associated with one or more templates for formatting data to perform the associated method using the one or more hardware resources and / or provide data to the application process. Each template may correspond to a respective hardware resource.

[0103] Communicating instructions and data between each of the one or more application processes and the allocated hardware resources may comprise translating the instructions and data by identifying, for each instruction, a rule associated with the method invoked by the instruction, identifying a hardware resource for carrying out the instruction, and formatting data associated with the instruction according to a template associated with the rule and corresponding to the identified hardware resource.

[0104] Defining the interface may comprise parsing an interface definition comprising source code. The source code of the interface definition may be written in a human- readable programming language and may define the plurality of rules for translating instructions and data communicated from the one or more application processes via the interface to the one or more allocated hardware resources via the one or more underlyingphysical interfaces. Defining the interface may further comprise generating machine code for execution by one or more of the plurality hardware resources. Executing the machine code may cause the respective hardware resource to carry out the instructions.

[0105] In other words, the rules may be for formatting data to carry out the instruction on a corresponding hardware resource of the one or more hardware resources. The rules may be rules for translating the instructions and data according to one or more templates.

[0106] The application may be an OpenRAN application.

[0107] The machine code generated for each of the rules may comprise a different version of the machine code for each of the hardware resources.

[0108] The machine code generated for each of the rules may be based on the processing capabilities of the hardware resource.

[0109] Each rule may be associated with one or more templates. Each different version of the machine code may correspond to a respective template.

[0110] The processing capabilities of a first hardware resource of the plurality of hardware resources may be different to the processing capabilities of a second hardware resource of the plurality of hardware resources.

[0111] The network function may comprise one or more applications and each application may comprise a plurality of the application processes. Each application may be generated by compiling application source code written in a human-readable programming language. The method may further comprise automatically generating a client-side stub based on the source code of the interface definition. The one or more methods may be defined in the client-side stub. The client-side stub may define one or more proxies for invoking the associated methods via the interface. The method may further comprise automatically generating one or more server-side skeletons based on the source code of the interface definition. Each hardware resource may comprise a driver comprising a server-side skeleton. Each server-side skeleton may define one or more proxies for carrying out instructions communicated via the interface.

[0112] In some examples, a single interface definition file with a single client-side generated stub is sufficient. However, there may be exceptions where multiple stubs could be generated from a single interface definition file (e.g., custom code generation where each stub is for a different type of crypto operations, such as one stub for AES-crypto and another for Snow3G crypto). Alternatively, different types of crypto operations could be structured with separate interface definition files with their corresponding single stubs for a simpler approach.

[0113] Each client-side stub may correspond to a different programming language.

[0114] Each server-side skeleton may correspond to a different hardware resource.

[0115] Communicating instructions and data between each of the plurality of application processes and the allocated hardware resources may comprise receiving instructions and data from an application process via a client-side stub, translating the instructions and data according to a rule corresponding to the client-side stub and a template corresponding to the server-side skeleton and sending the instructions and data to the hardware resource via the server-side skeleton.

[0116] Communicating instructions and data between each of the plurality of application processes and the allocated hardware resources may comprise receiving data from a hardware resource via a server-side skeleton, translating the data according to a template corresponding to the server-side skeleton and a rule corresponding to a client-side stub, and sending data to an application process via the client-side stub.

[0117] As well as receiving instructions from the application and sending instructions to the hardware, the interface may also operate in the opposite direction. Data from the hardware may be formatted and returned to the application process.

[0118] In some examples, the interface may be configured to operate in the opposite direction by facilitating invocation of methods on the server side for execution by the client side. The one or more hardware resources may invoke methods that are implemented by the application processes. In this way, the client-side nodes (application processes) may also offer server capabilities. Likewise, server-side nodes (hardware resources, e.g. crypto compute kernel) may implement some client methods, as well as server capabilities. Asdescribed above, this may be useful for receiving asynchronous responses on the clientside and / or for providing service discovery / registration.

[0119] The method may further comprise automatically generating one or more server-side stubs and / or client-side skeletons, based on the source code of the interface definition. Each server-side stub may define one or more proxies for the hardware resources to invoke methods via the interface and each client-side skeleton may define one or more proxies for causing the application processes to carry out instructions communicated via the interface.

[0120] The one or more underlying physical interfaces may comprise one or more of:PCIe;OCP; and ethernet.

[0121] The plurality of hardware resources may comprise one or more compute kernels and / or RAN processing units, RPUs. Each compute kernel and / or RPU may comprise a plurality of physical hardware elements

[0122] The plurality of physical hardware elements may comprise one or more: memory units;Central Processing Units, CPUs;CPU cores;Digital Signal Processors, DSPs;Field Programmable Gate Arrays, FGPAs;Application-Specific-lntegrated-Circuits, ASICs;Graphics Processing Units, GPUs; and / or accelerators.

[0123] Each compute kernel and / or RPU may be configured to implement a Hardware Abstraction Layer, HAL, to communicate instructions and data with the plurality of physical hardware elements.

[0124] The instructions and data may comprise a plurality of instructions and data associated with each instruction. The data may provide details of how the instructionshould be carried out. In other words, the instruction may be a reference to a method defined by the interface and the data may be parameters provided to the method.

[0125] Each application process may be allocated hardware resources from the plurality of hardware resources based on one or more processing requirements of the respective application process and one or more processing capabilities of the allocated hardware resources.

[0126] The processing capabilities may comprise one or more of: an instruction set of the hardware resource; signal processing capabilities of the of the hardware resource; packet processing capabilities of the of the hardware resource; one or more communications protocols for which processing capabilities are supported; and one or more technology standards for which processing capabilities are supported.

[0127] The method may further comprise receiving, from each of the one or more application processes, a request for hardware resources. The request may comprise an indication of the processing requirements of the respective application process. The method may further comprise dynamically allocating the hardware resources to the respective application process in response to the request.

[0128] The method may further comprise dynamically configuring hardware resources from the plurality of hardware resources, based on the one or more processing capabilities of the respective hardware resource and the one or more processing requirements of one or more application processes to which the hardware resource has been allocated.

[0129] A framework for facilitating one or more application processes in a network function of an Open Radio Access Network, Open RAN, is provided. The framework is configured to perform any of the methods described above.

[0130] A computer program is also provided. The computer program comprises instructions that, when executed on a processor, cause the processor to perform the any of the methods described above.

[0131] The present disclosure also provides a framework for managing resources and facilitating application processes in an Open Radio Access Network.

[0132] A method of managing resources in a network function of an Open Radio Access Network, Open RAN, is provided. The method comprises dynamically identifying a plurality of hardware resources available to the network function. Each hardware resource supports one or more processing capabilities. The method further comprises facilitating a plurality of application processes by: dynamically allocating hardware resources from the plurality of hardware resources to the plurality of application processes, based on one or more processing requirements of each of the plurality of application processes and the processing capabilities of each hardware resource; and communicating instructions and data between each of the plurality of application processes and the hardware resources allocated to the respective application process.

[0133] As described above, US2023318904A1 describes cross-platform programmable network communication in a Radio Access Network. While this document focusses on system optimization and automation, it does not provide a complete framework for dynamically identifying hardware resources, dynamically allocating resources to application processes and communicating between the application processes and the hardware resources.

[0134] By discovering hardware and facilitating application processes in the manner described, the proposed method may allow application processes to be executed by the network independently of the available hardware resources. Therefore, computer programs to implement the functionality of the network functions may be provided by any application vendor(s), may be written in a hardware agnostic manner, and may be inter-operable across different platforms. Likewise, hardware resources may be provisioned to the cloud platform and may be used to facilitate a range of different application processes, from different vendors and for different network functions.

[0135] By communicating instructions between the application processes and the allocated hardware resources, the proposed methods provide a framework for a more open and disaggregated system in which the software and hardware elements may be provided bydifferent vendors. In other words, software may be developed independently of the underlying hardware.

[0136] This provides a more flexible environment in which individual components of the network (hardware and / or software) may be universally interoperable and may be replaced / updated independently of each other. This may enable individual components of the network to be swapped for more efficient versions, which may improve the overall efficiency of the network. This may also encourage innovation in individual components (since the network is no longer tied to a particular vendor).

[0137] In the context of the method described above, managing “resources” may refer to managing processing resources (hardware), rather than radio resources.

[0138] In the context of the present disclosure, actions that are performed “dynamically” may be interpreted as being performed at runtime. In contrast, prior art Open RAN systems include static lists of hardware resources that are preconfigured and not determined at runtime.

[0139] Multiple application processes can share the same hardware resources. Therefore, dynamic hardware discovery may enable hardware sharing and improve efficiency.

[0140] Dynamic discovery and allocation of hardware may also enable suitable hardware to be provisioned for the specific environment (e.g., location) of the network functions. For example, a network function serving a rural environment may have different requirements to a network function serving an urban environment. The proposed methods enable the Open RAN to allocate the resources dynamically (i.e., at runtime), so that the requirements of the applications may be already known and can be met automatically. This may improve the performance and efficiency of the network functions.

[0141] Dynamic discovery and allocation of hardware based on the processing requirements of the application processes may also enable the network to respond to changing requirements of the application processes. For example, if the radio conditions change then different hardware may be more suitable for meeting the needs of the network functions.

[0142] The plurality of application processes may comprise one or more OpenRAN applications.

[0143] The plurality of applications may further comprise one or more virtualized RAN, vRAN, applications and / or one or more virtual RAN applications.

[0144] Dynamically identifying the plurality of hardware resources may comprise discovering the plurality of hardware resources and querying each of the hardware resources to determine the respective processing capabilities of each hardware resource.

[0145] The plurality of hardware resources may comprise one or more:RAN processing units; compute kernels; memory units;Central Processing Units, CPUs;CPU cores;Digital Signal Processors, DSPs;Field Programmable Gate Arrays, FGPAs;Application-Specific-lntegrated-Circuits, ASICs;Graphics Processing Units, GPUs; and / or accelerators.

[0146] As noted above, the “hardware resources” may comprise processing elements that are abstracted from the underlying hardware, such as RAN processing units and compute kernels. These processing elements may be provided by an underlying cloud platform. The way in which these resources are provided may be independent of the application running on the network function. For example, compute kernels for the cloud platform may be written independently of the applications.

[0147] The memory units may be silicon memory units. The other listed hardware resources may interact with the memory units, which may include CPU and system memory.

[0148] The processing capabilities may comprise one or more of: an instruction set of the hardware resource; signal processing capabilities of the of the hardware resource;packet processing capabilities of the of the hardware resource; one or more communications protocols for which processing capabilities are supported; and one or more technology standards for which processing capabilities are supported.

[0149] The one or more communications protocols for which processing capabilities are supported may include various components of the 4G and 5G protocol stacks for the RAN, such as:NAS;RRC;SDAP;PDCP;RLC;MAC; andPHY.

[0150] The one or more communications protocols for which processing capabilities are supported may further include components of other protocol stacks, such as:LLC; and SNDCP.

[0151] The one or more technology standards may include 3GPP standards, such as:GSM;GPRS;EDGE;UMTS;UTRA;CDMA2000;LTE;LTE-A;E-UMTS;E-UTRA;NR; and6G and other forthcoming technology standards.

[0152] The one or more technology standards may further include non-3GPP technology standards, such as:Wi-Fi; andWiMAX.

[0153] The method may further comprise receiving, from each of the plurality of application processes, a request for hardware resources. The request may comprise an indication of the processing requirements of the respective application process.

[0154] The method may further comprise dynamically configuring hardware resources from the plurality of hardware resources, based on the one or more processing capabilities of the respective hardware resource and the one or more processing requirements of one or more application processes to which the hardware resource has been allocated.

[0155] Each hardware resource may support one or more power management capabilities. The method may further comprise receiving, from each of the plurality of application processes, power management instructions. The method may further comprise implementing the power management instructions by controlling one or more of the hardware resources allocated to the respective application process, based on the power management capabilities of the respective hardware resource, to: operate in a power mode selected from a plurality of power modes defined by the power management capabilities of the hardware resource; perform frequency scaling; and / or perform voltage regulation.

[0156] Dynamically identifying the plurality of hardware resources may further comprise querying each of the hardware resources to determine the respective power management capabilities of each hardware resource.

[0157] Hardware discovery may notify the application of the power management capabilities are available for each hardware resource and enable the application to perform its own power management. Alternatively, power management policies may be set by another entity in the cloud platform, such as a Service Management and Orchestration framework. In either case, the framework may be responsible for implementing the power management by configuring the hardware resources.

[0158] The method may further comprise dynamically evaluating one or more power consumption and performance metrics. The method may further comprise dynamically adjusting allocation of hardware resources to the plurality of application processes to implement the power management instructions.

[0159] In other words, implementing the power management instructions may further comprise dynamically evaluating one or more power consumption and performance metrics and dynamically adjusting allocation of hardware resources to the plurality of application processes. In this way, the framework may evaluate power consumption and performance to achieve a compromise. This may also allow the network functions to flexibly reconfigure the hardware to meet performance requirements. This may improve overall efficiency and / or performance.

[0160] The method may further comprise configuring one or more compute kernels to improve performance and / or reduce energy consumption.

[0161] The method may further comprise defining an application-specific interface between each of the plurality of application processes and the hardware resources allocated to the respective application process. Communicating instructions and data between the application process and the allocated hardware resources may comprise communicating the instructions and data via the application-specific interface.

[0162] Communicating instructions and data via the application-specific interface may comprise: communicating instructions and data with the application process via the application-specific interface; translating the instructions and data, based on the application-specific interface defined for the application process; and communicating instructions and data with the plurality of hardware resources via one or more underlying physical interfaces.

[0163] In some examples, underlying hardware resources (e.g., compute kernels) may operate with different address spaces. By translating the instructions and data, the proposed methods may facilitate execution of code on the underlying resources, independently of the address spaces used by each component of the system.

[0164] The one or more underlying physical interfaces may comprise one or more of: Peripheral Component Interconnect Express, PCIe;Open Core Protocol, OCP; and ethernet.

[0165] In some examples, OCP may include the use of PCIe as an internal connection standard. Nevertheless, the physical form factor and connector may follow the OCP specification.

[0166] The proposed framework may facilitate a programmatic method for provisioning an interface between the hardware and software components and perform an orchestration role to mediate between them. In this way, the proposed framework may be used to flexibly manage different types of interfaces between hardware and software elements.

[0167] A framework for managing resources in a network function of an Open Radio Access Network, Open RAN, is also provided. The framework comprises a software- defined RAN controller, SDRC, configured to dynamically identify a plurality of hardware resources available to the network function, wherein each hardware resource supports one or more processing capabilities. The SDRC is further configured to dynamically allocate hardware resources from the plurality of hardware resources to a plurality of application processes, based on one or more processing requirements of each of the plurality of application processes and the processing capabilities of each hardware resource. The framework further comprises a RAN inter-process communication framework, RAN-IPC, configured to communicate instructions and data between each of the plurality of application processes and the hardware resources allocated to the respective application process.

[0168] The framework may further comprise a RAN programming language defining a plurality of functions comprising signal and packet processing functions for a plurality of communications protocols and / or technology standards.

[0169] For example, the RAN programming language may comprise signal and packet processing operations for 5G.

[0170] The RAN programming language may further comprise cryptography processing operations for encoding and decoding data.

[0171] The framework may further comprise a RAN compiler configured to receive instructions in accordance with the RAN programming language and provide instructions to control each of the plurality of hardware resources, based on the processing capabilities of the respective hardware resource.

[0172] The framework may further comprise a Hardware Abstraction Layer, HAL, configured to communicate instructions and data between the SDRC and the plurality of hardware resources via one or more underlying physical interfaces.

[0173] In prior art systems, hardware abstraction is fixed. For example, some systems provide a BaseBand driver mechanism to hide the underlying hardware. Moving from one hardware abstraction mechanism to another would be an extremely complex task in such systems. Therefore, these elements are rarely changed and can be a source of inefficiencies and limit flexibility of interoperability between hardware and software. In contrast, the proposed framework provide a highly programmable, more dynamic and transparent system in which individual elements may be introduced, substituted and / or removed.

[0174] A computer program comprising instructions that, when executed on a processor, cause the processor to perform any of the methods described above is also provided.

[0175] A method of compiling a computer program comprising instructions executable by a network function of an Open Radio Access Network, Open RAN, is also provided. The method comprises identifying a plurality of hardware resources available to the network function, wherein each hardware resource supports one or more processing capabilities. The method further comprises parsing source code, wherein the source code comprises instructions written in a human-readable programming language. The method further comprises generating machine code for execution by one or more of the plurality hardware resources. Executing the machine code causes the respective hardware resource to carry out the instructions. The machine code is based on the processing capabilities of the hardware resource.

[0176] The proposed method may enable the computer program to be compiled independently of the underlying hardware on which it will eventually be executed (e.g., theCPU). Moreover, the source code may be written without committing to running the computer program on any particular hardware.

[0177] Prior art compilers produce software applications that use instructions specific to the CPU on which the program will be run. These computer programs are difficult to interoperate between platforms.

[0178] Advantageously, the proposed methods may exploit the benefits of the available hardware, while making the application agnostic to the underlying hardware.

[0179] The computer program may comprise instructions executable by a processing node, such as a network function of an Open Radio Access Network.

[0180] The source code may comprise one or more source code files.

[0181] The source code may be written in a RAN Programming Language, which comprises functions that are specific to Open RAN. Alternatively, the source code may be written in a well-known programming language, such as C++.

[0182] The computer program may be an OpenRAN application.

[0183] In some examples, the computer program may be a virtualized RAN, vRAN, application or a virtual RAN application.

[0184] Generating machine code for execution by one or more of the plurality of hardware resources may comprise generating a different version of machine code for each of the hardware resources, based on the processing capabilities of the hardware resource.

[0185] The processing capabilities of a first hardware resource of the plurality of hardware resources may be different to the processing capabilities of a second hardware resource of the plurality of hardware resources.

[0186] In other words, each hardware resource supports one or more processing capabilities that are different between hardware resources.

[0187] The processing capabilities of the hardware resources may be tailored to specific functions. When the computer program is executed by a network function, one or more application processes may be instigated. The one or more hardware resources may be allocated to the one or more application processes based on the requirements of the respective application process and the capabilities of the hardware resource.

[0188] The plurality of hardware resources may comprise one or more:RAN processing units; compute kernels; memory units;Central Processing Units, CPUs;CPU cores;Digital Signal Processors, DSPs;Field Programmable Gate Arrays, FGPAs;Application-Specific-lntegrated-Circuits, ASICs;Graphics Processing Units, GPUs; and / or accelerators.

[0189] The processing capabilities may comprise one or more of: an instruction set of the hardware resource; signal processing capabilities of the of the hardware resource; packet processing capabilities of the of the hardware resource; one or more communications protocols for which processing capabilities are supported; and one or more technology standards for which processing capabilities are supported.

[0190] Each hardware resource may support one or more power management capabilities. Executing the machine code may cause the respective hardware resource to operate in a power mode selected from a plurality of power modes defined by the power management capabilities of the hardware resource.

[0191] The one or more hardware resources may support frequency scaling. Executing the machine code may cause the respective hardware resource to adjust a CPU frequency of the hardware resource based on a workload of the hardware resource.

[0192] For example, if the CPU is busy, the frequency may be increased to increase the work rate of the CPU. If workload is low, the frequency may be reduced to increase efficiency and stability.

[0193] In prior art methods, frequency scaling is very specific to the underlying hardware and the code is not functionally portable between different CPU types. In contrast, the proposed methods generate machine code based on the processing capabilities of the underlying hardware resource (i.e., it can be tailored to any hardware). Moreover, the proposed invention may provide different versions of the executable code for different hardware requirements. In this way, frequency scaling may be performed on a variety of hardware without the application programmer having to know in advance what hardware will be available or write different versions of the code to account for the different possibilities. The compiler will take care of this.

[0194] Executing the machine code may cause the respective hardware resource to adjust a supply voltage of the hardware resource based on the CPU frequency of the hardware resource.

[0195] Power mode selection, frequency scaling and / or voltage regulation may be implemented with a hysteresis mechanism to inhibit changes within a threshold period following a previous change.

[0196] The method may further comprise defining an application-specific interface between the computer program executable by the network function and the plurality of hardware resources. The computer program may comprise rules for translating instructions and data communicated from the network function via the application-specific interface to the plurality of hardware resources via one or more underlying physical interfaces.

[0197] The one or more underlying physical interfaces may comprise one or more of: Peripheral Component Interconnect Express, PCIe;Open Core Protocol, OCP; and ethernet.

[0198] The computer program may be configured to run in a cloud environment or on a physical server. The computer program may be run on a containerised operating system or a non-containerised operating system.

[0199] A computing device configured to perform any of the methods described above is also provided.

[0200] A computer program (e.g., a compiler) comprising instructions that, when executed on a processor, cause the processor to perform any of the methods described above is also provided.Brief description of the drawings

[0201] Fig. 1 illustrates an example cloud platform.

[0202] Fig. 2 illustrates the differences between Single (Non-Open) RAN and Open RAN.

[0203] The invention will be described with reference to the non-limiting examples illustrated in the following Figures.

[0204] Fig. 3 illustrates an overview of the RAN abstraction framework with layered components.

[0205] Fig. 4 illustrates the process flow for the interface definitions.Detailed description

[0206] Prior to Open RAN, mobile networks were built by a small number of vendors with tightly coupled hardware and software. Interoperability between equipment from different vendors was restricted and this arrangement resulted in limited flexibility and innovation. It is an aim of Open RAN to improve the traditional model by decoupling hardware and software components. This enables greater flexibility, innovation, and cost-effectiveness in building and operating mobile networks.

[0207] As described above, the Open RAN system decouples hardware and software in the RAN network and allows hardware and software components to be provisioned separately. In order to do so, new standards for interactions between the hardware and software components of the Open RAN system have been provided by the Open RANAlliance (the term “O-RAN” generally refers to standards specified by the Open RAN Alliance).

[0208] Fig. 2 illustrates the differences between Single (Non-Open) RAN and Open RAN. By moving from a Single RAN to an Open RAN, the following benefits may be achieved:Disaggregation;Decoupling HW from SW;Open Ecosystem;Open Interfaces; and Intelligent Management.

[0209] Open RAN enables interoperability for hardware and software elements provided by different suppliers. By doing so, Open RAN also provides resilience for the MNO by promoting supplier diversity in the network. If elements from a specific supplier cease to function correctly or need to be removed permanently or temporarily (e.g., due to security or performance requirements), elements from another supplier may be relied upon instead, without major disruption to the network.

[0210] Open RAN also offers potential energy efficiency improvement, for example through flexible provisioning of hardware to meet network requirements.

[0211] Open RAN enables Functional Block Separation where the baseband processing functions are separated into distinct blocks, allowing various vendors to contribute and innovate. To achieve true interoperability and innovation, this however requires solutions from different vendors to work together seamlessly. Ensuring seamless interoperability between hardware and software components across competing vendors is crucial for the success of Open RAN. The disaggregation of RAN functions into software-based components that can be hosted on different processor architectures introduces interoperability challenges while managing and orchestrating these functions.

[0212] The cloud platform, which is sometimes referred to as the “O-Cloud”, serves as a fundamental component of the Open RAN system. The cloud platform comprises hardware and software components. The hardware components of the cloud platform include physical infrastructure nodes arranged in one or more node clusters, which are referred to as “server nodes”. These provide the hardware resources that are needed to support the network function deployments (e.g., O-RU, O-DU and O-CU), which are implemented insoftware applications running on the cloud platform hardware. The software applications are referred to in this document as “client nodes”.

[0213] The network function deployments are sometimes referred to as “managed elements” or “logical nodes” in related literature. “Logical nodes” are not to be confused with the physical infrastructure nodes of the cloud platform (server nodes). In this disclosure, the software applications that implement the network functions are referred to as “client nodes”. The physical infrastructure nodes of the cloud platform (server nodes) comprise the physical hardware resources required to support the network function deployments, while the software applications (client nodes) define the functionality of the network function deployments. Neither of these are to be confused with a 3GPP base station, which is referred to as a “Node B”.

[0214] To facilitate interoperability and create an environment for competition and innovation, one characteristic of virtualized and open RAN is that multiple hardware and software vendors can coexist within an operator’s RAN domain. Defining standards and interfaces that enable effective innovations from the different competing vendors with their ensuing solutions remains an ongoing challenge for developers of Open RAN standards.

[0215] To ensure Open RAN applications in the O-DU, O-CU and O-RU platforms can make best use of the underlying resources of the processing hardware fabric, an abstraction framework is provided that enables both the application development and RAN component development from any vendor to become independent of the system hardware fabric. The overview of the RAN abstraction framework with layered components is illustrated in Fig. 3.

[0216] Fig. 3 illustrates an O-DU or O-CU vRAN Application running on an O-RAN DU or CU. Nevertheless, the O-DU or O-CU abstraction framework could equally apply to an O- RU application that may be built on bare metal (without a container engine).

[0217] The RPL, SDRC, RAN-IPC Framework and Interface Definitions provide new layers that together form the Soft Fabric Processor according to the present disclosure.

[0218] The Soft Fabric Processor also comprises a Hardware Abstraction Layer in some examples. A Hardware Abstraction Layer is provided in prior art O-RAN DU and CU arrangements and there are ongoing developments and discussions around the HAL in theO-RAN community. In some embodiments, the HAL of the Soft Fabric Processor may complement current ideas. Alternatively, the HAL of the Soft Fabric Processor in other embodiments may introduce a new conceptual model.

[0219] The main components of the Soft Fabric Processor (SFP) are described separately below. These are specific examples and are not intended to limit the scope of the present invention, which his defined in the appended claims.RAN Programming Language (RPL)

[0220] A high-level RAN Programming Language (RPL) provides a RAN specific syntax for expressing O-DU functionalities. This allows developers to focus on the O-DU processing logic without requiring knowledge of low-level hardware details. The following RAN Programming Language (RPL) framework provides abstraction of the 5G vRAN functions, enabling dynamic hardware discovery and configuration of discrete RAN Processing Units (RPUs) / compute kernels.

[0221] The RPL framework provides a simplified framework for development of highly flexible vRAN applications by providing a high-level, RAN-specific approach to express O- DU vRAN signal and packet processing functionalities.

[0222] The RPL framework enables dynamic configuration and utilization of available signal processing and hardware resources (e.g., accelerators and dedicated processing units) for optimal performance.

[0223] With runtime discovery of the processing resources, the RPL framework provides an effective framework for exploiting the signal processing and hardware capabilities at runtime to achieve optimal performance and energy efficiency.

[0224] The RPL framework comprises an RPL Language. The RPL Language is a core component with keywords, operators, and constructs designed for representing vRAN functionalities and interacting with the RAN signal / packet processing and hardware resources.

[0225] The RPL framework also comprises an RPL Compiler (SDK toolkit). The RPL Compiler forms part of the RPL SDK toolkit and may be used to generate actionablebehavioural output as runtime code. This component translates the RPL code into executable code for the target hardware platform.Software Defined RAN Controller (SDRC)

[0226] The SDRC runtime system performs dynamic discovery of the available processing units, detecting available processing units and their capabilities such as the supported services, methods / operations and performance characteristics.

[0227] The SDRC runtime system performs resource management by requesting and managing hardware resources for specific processing tasks.

[0228] The SDRC runtime system performs configuration / reconfiguration of the processing units with parameters based on the discovery information and vRAN application specific requirements communicated via the RPL framework.

[0229] The SDRC runtime system enables an application to perform platform independent power management operations to provide power saving modes, frequency scaling and voltage regulation. Platform independent abstraction of the power management policies and interfaces may enable the O-RAN compute platform (DU / O-CU / O-RU) to optimize energy efficiency across different CPU architectures while balancing performance and power consumption.RAN Inter-Process Communication (RAN-IPC) Framework

[0230] RAN-IPC Implements an “Ultra-Fast” RAN Inter-Process Communication (RAN-IPC) framework enabling communication mechanism for carrying messages and data between application and components and compute kernels via the defined interfaces with minimal latencies.

[0231] A Remote Procedure Call (RPC) approach is proposed to support the RAN-IPC framework. An RPC framework enables communication between the different application components using the abstract interfaces instantiated via the Interface Definitions. This allows for distributed processing and efficient utilization of RAN compute resources that are location independent (i.e., whether hosted on the native application processor or elsewhere on a different hardware system with its own address space).

[0232] The RPC middleware layer provides the communication mechanism between the O- RAN compute kernels providing the services (server nodes) and the applications requesting the services (client nodes). It handles functions such as establishing connections, serializing and deserializing data (where required), and managing seamless method invocations. The RPC middleware abstracts away the underlying transport, allowing the RPC framework to be independent of the specific transport communication protocol.

[0233] The proposed RPC middleware alongside the Interface Definition Language (IDL) framework may enable RPL (RAN Programming Language) operations or commands towards different compute kernels (e.g., signal processing functions) by providing a standardized way to define seamless interfaces and facilitating communication between the RPL application environment and the compute kernels.

[0234] In the context of an O-RAN compute platform of the O-DU / O-CU / O-RU, RPL operations / commands would typically be specified in an interface definition file to define the interfaces and methods that the system may use for communication and control. This would allow for a standardized way of invoking these commands across different implementations and ensure that the system components can interoperate effectively according to the O-RAN standards. The interface definition acts as a contract that specifies the structure of the data and the operations available, which can be used to generate code for different platforms and languages.

[0235] The RPC layer may be capable of supporting different transport protocols for communication between the O-RAN applications of the client nodes and the compute kernels of the server nodes. The RPC framework may be optimized for speed and latency.

[0236] The interface based approach enables the RPC framework to support different communication mechanisms. This may include specialized protocols optimized for low- latency communication in an O-RAN environment for compute kernels / hardware acceleration functions. For PCIe based hardware platforms, these protocols may leverage the low latency and bandwidth of PCIe while implementing functionalities specific to the compute kernel / acceleration needs. For compute kernels located in the same address space of the O-DU / O-CU / O-RU native processor platform, the RPC communication handling is performed using structures which are stored in shared memory. Thesestructures may represent the communication channels between communication entities of the server / client nodes.

[0237] To achieve platform independence, the RPC layer is built alongside the interface definition framework implemented using language and platform-neutral technologies while the framework abstracts away hardware-specific details, allowing it to run on different processor architectures seamlessly.

[0238] While facilitating the establishment and management of the RPC connections, including connection lifecycle management and control of the RPC nodes, the RPC framework may enable brokerless communication with a direct connection between the client and server nodes of the RPC system. The lightweight framework with brokerless communication may facilitate efficient and ultra-fast communication with minimal overhead for a direct connection without intermediaries.

[0239] To support the dynamic nature of radio networks and the diverse requirements of RAN signal processing functions, the RPC framework may support dynamic configuration of the compute kernels / RPUs. This includes the ability to dynamically add or remove processing nodes, reconfigure RAN signal processing pipelines, and adapt to changes in network conditions or traffic patterns.

[0240] In the context of an O-RAN compute platform of the O-DU / O-CU / O-RU, the proposed interface-based remote procedure call framework alongside the RPL environment provides a holistic approach for an effective abstraction of the O-RAN compute kernels and applications by serving as a standardized interface for defining the procedures and data structures that are used for communication between different components of the O-RAN system.

[0241] The holistic approach described provides a number of advantages over prior art systems. One such advantage is standardization. Interface definition files may define the interfaces and methods in a standardized format, ensuring consistency across different implementations and vendors.

[0242] Another advantage is abstraction. By abstracting the underlying compute kernels / RAN Processing Units (RPUs) and the application layers, developers can work witha simplified model of the system, focusing on the higher-level operations without worrying about the low-level details.

[0243] A third advantage is interoperability. A common interface-based remote procedure call framework would facilitate interoperability between RAN components (compute kernels and applications) developed by different O-RAN vendors, while ensuring they would all adhere to the same interface specifications. This may enable a much wider competition landscape with rapid on-boarding of new features and designs in the O-RAN ecosystem.

[0244] A fourth advantage is automation. Soft Processor Framework (SFP) SDK / tools can automatically generate stubs and skeletons for various platforms and programming languages from the interface definition files, speeding up the development process.

[0245] Another advantage is flexibility. The RAN Programming Language (RPL) operations / commands specified in the interface definition as methods would allow for flexible and dynamic discovery, on-boarding, and control of the compute kernels / RPUs and applications, enabling the system to adapt more readily to new requirements or changes in the environment.Interface Definitions

[0246] Interface Definitions programmatically provide the abstract interfaces via HAL for different compute kernels forming part of the hardware components such as CPU, DSP, FPGA and ASIC

[0247] Interface Definitions may enable abstract interfaces over different underlying physical interfaces, native on the application processor system, PCIe, Ethernet, etc.

[0248] Development of the HAL implementation for each compute component may enable the translation of high-level commands from the application into compute kernel-specific instructions.

[0249] To accomplish standardized abstract interfaces between components and applications of an O-RAN compute platform (O-DU / O-CU / O-RU), an Interface Definition Language (IDL) framework is proposed that enables platform / processor / operating system(OS) and language implementation independent communication between the O-RAN components and applications.

[0250] The descriptive language of the interface definition framework describes the required data types and interfaces and captures their attributes, operation signatures and exceptions. The actual O-RAN compute algorithmic implementation of operations, however, is not required. In the case of O-DU for instance, the algorithmic implementation is provided by the compute kernels / RAN Processing Units (RPUs) of the server nodes serving the request submitted by the O-DU applications of the client nodes.

[0251] The interface definition framework provides the basis for platform / processor / OS and language implementation independence in the O-RAN compute platform environment. The framework includes an interface compiler to generate language-specific stubs (client nodes of the O-DU / O-CU / O-RU applications) and skeletons (server nodes providing the O-DU / O- CU / O-RU compute kernels). These stubs and skeletons serve as proxies on the client and server sides, respectively, allowing for seamless communication between the two ends.

[0252] The interface definition framework may enable seamless method invocations described in the Remote Procedure Call communication mechanism. For an O-RAN O- DU / O-CU / O-RU application, this interface definition includes methods for configuring and invoking compute kernels (e.g., 5G signal processing functions and other compute kernels and packet processing entities). The seamless method invocation means that this operation can be performed in a location independent manner, i.e., irrespective of whether the method is located locally on the native processor hardware in the same address space or on a different hardware platform, the application is unaware of the location.

[0253] The abstract interfaces defined by the interface may be independent of the underlying hardware platform and OS and may ensure that the interfaces remain consistent regardless of the deployment environment. By using a defined interface, developers can focus on the logic of their applications without worrying about the underlying communication protocols, as the interface handles the translation of method calls and data structures across the communication interface.Overall Interface Definitions and RPC Process Flow

[0254] In the context of an O-RAN ecosystem, the proposed framework enables application vendors to develop applications that may use the services provided by the compute kernels / RPUs (or potentially other applications). The service-requesting application needs to use a stub of the interface provided with the compute kernel / RPU. By using the interface definition file and the code generator, the developer of the application can generate the interface stub (also called “client-side stub”). The generated code of the interface stub allows the application to connect to the interface skeleton via the RPC framework. Once connected, the application can perform RPC calls on the servicing compute / kernel / RPU via the interface. The interface definition and code generation is performed by the host, whereas the applications are executed on the target O-DU / O-CU / O- RU compute platform.

[0255] Fig. 4 illustrates the process flow for the interface definitions. The interface compiler (also referred to as “Code Generator”) is a component of the Soft Fabric Processor (SFP). The RPC based RAN-IPC Framework is also a component of the SFP SDK. The file comprising the interface definitions (also referred to as a “.idl file”, written in an interface definition language, IDL) is provided by the Application(s) vendor(s). The O-DU / O-CU / O- RU Application(s) is / are also provided by the Application(s) vendor(s). The O-DU / O-CU / O- RD Compute kernels / RPUs are provided by the compute kernel(s) vendor(s). Based on the interface definitions, the compiler may be configured to generate the client-side stub and the server-side skeleton. The client-side stub and the server-side skeleton components are therefore auto generated.Hardware Abstraction Layer (HAL)

[0256] The HAL layer forms part of the overall SFP framework that provides an interface between the SFP components, including the RPL component, and the underlying hardware platform.C / C++ Language / Compiler Enhanced Operations

[0257] C / C++ Language / Compiler Enhanced Operations provide a high-level interface to the underlying CPU instructions, allowing developers to write hardware platform independent code while still leveraging specific optimizations of the underlying CPU hardware. They can form part of a more abstract level application programming framework to express operations that have efficient implementations on different architectures.Compiler intrinsics for instance can provide a standardized interface for accessing these features, which can improve code portability across different CPU platforms and compilers. By abstracting low-level CPU instructions into such abstract level operations, O-RAN components can achieve performance across different CPU architectures without direct dependency on assembly-level programming.

[0258] Some specific examples of abstract level operations that are applicable for vRAN applications are described below.

[0259] The Compiler Enhanced Operations may comprise vRAN workload based dynamic CPU frequency scaling with hysteresis. This may introduce a hysteresis mechanism to avoid frequent frequency switches. If the vRAN workload exceeds an upper threshold or falls below a lower threshold, the frequency may be adjusted to a new value given by the following formula:Min Frequency + (vRAN workload * (Max Frequency - Min Frequency))

[0260] The new frequency may be rounded to nearest frequency step value of the target CPU. The “vRAN workload” is a CPU core occupancy normalized between 0 and 1 .

[0261] The Compiler Enhanced operations may comprise abstraction of atomic operation to achieve consistent behaviour across different CPU architectures. The atomic functions to provide programmable priority levels to enable O-DU to manage its real time tasks of varying criticalities with their corresponding resources more efficiently. The abstract atomic operation may be used for thread synchronization and concurrency control with abstraction of synchronization constructs to ensure portability and performance on different CPU architectures.

[0262] The Compiler Enhanced Operations may comprise a random number generator with configurable entropy levels This platform independent function may provide a secure source of random numbers with adjustable entropy levels (measure of randomness) important for generating highly randomized keys for cryptographic algorithms used in O-DU vRAN applications.

[0263] The Compiler Enhanced Operations may comprise RAN workload encryption functions that provides a generic interface for the 3GPP mandated encryption algorithms.The generic behaviour may be mapped to CPU-specific instructions by the compiler (and optimised for the particular CPU).

[0264] The Compiler Enhanced Operations may comprise matrix operations with a generic interface to support different processor architectures. The generic behaviour is mapped to the CPU-specific matrix instructions for the underlying CPU (and optimised for the particular CPU). The matrix operations are used in vRAN application to perform key functions such as Channel Estimation, Equalization, Beamforming, Precoding and Combining amongst others.

[0265] The Compiler Enhanced Operations may comprise a vRAN packet processing function with a generic interface to abstract network protocol processing operations including packet parsing, checksum calculation and header management / handling supported with a common interface independent of the underlying CPU architecture.

[0266] Overall, the proposed soft fabric processor may provide significant benefits in several key areas, which are described below.

[0267] The proposed soft fabric processor may provide performance benefits. The effective abstraction of the processing components may enable targeted optimization of the overall system using a consistent and vendor neutral interface across the different competing platforms. Operators can target higher performance with increased throughput for certain network deployments or maximum energy efficiency for other network deployments. Based on user workload demands and traffic patterns, operators can dynamically adjust processing resources to achieve optimum performance across different hardware platforms.

[0268] The proposed soft fabric processor may provide cost benefits the holistic approach may enable effective decoupling of hardware and software components, promoting vendorneutral solutions across competing hardware architectures. This effective hardware and software separation may allow operators to potentially reduce costs by selecting components independently, leading to more competitive pricing.

[0269] The proposed soft fabric processor may enhance scalability. This may enable operators to adapt to changing network demands by mixing and matching components from different competing vendors. Operators may be able to perform this on demand inmuch less time. With the evolving network use cases and requirements, this holistic approach may enable efficient allocation and utilization of network resources.

[0270] The proposed soft fabric processor may enhance interoperability. Standardized interfaces across competing architectures and platforms may enable interoperability between components. This may promote faster innovation across a diverse ecosystem of O-RAN partners enabling them to bring their respective solutions to market more rapidly.

[0271] Although specific embodiments have been described above, the skilled person will understand that various modifications and variations are possible. For example, whilst the disclosure is described in relation to existing network architecture, it will be understood that changes to the architecture (and / or nomenclature) are possible, but the present disclosure may still be applicable in this case. Also, combinations of any specific features shown with reference to one embodiment or with reference to multiple embodiments are also provided, even if that combination has not been explicitly detailed herein.

[0272] Where this application refers to a server, for instance, this may actually be a pair of servers (primary and failover), for redundancy.

[0273] Where this application refers to a “network entity”, the skilled person would understand that the network entity may actually be provided by a plurality of servers that are geographically distributed.

[0274] An Open Radio Access Network as described above may be used to provide a cellular network serving one or more User Equipments, UEs. Examples of the UE include various fixed and mobile devices that transmit and receive user data and / or various kinds of control information to and from a base station. The UE may be referred to as a terminal equipment (TE), a mobile station (MS), a mobile terminal (MT), a user terminal (UT), a subscriber station (SS), a wireless device, a personal digital assistant (PDA), a wireless modem, a handheld device, etc.

[0275] Whilst the above examples are described in relation to specific radio access networks (e.g., 4G and 5G radio access networks), these methods, techniques, apparatuses, and systems may be applied to a variety of wireless multiple access systems. Examples of multiple access systems include CDMA, FDMA, TDMA, OFDMA, SC-FDMA, and MC-FDMA. CDMA may be embodied through radio technology such as UTRA orCDMA2000. TDMA may be embodied through radio technology such as GSM, GPRS, or EDGE. OFDMA may be embodied through radio technology such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or E-UTRA. UTRA is a part of a UMTS. 3GPP LTE is a part of E-UMTS using E-UTRA. 3GPP LTE employs OFDMA in DL and SC-FDMA in UL. LTE-A is an evolved version of 3GPP LTE. 3GPP NR employs OFDMA for both downlink and uplink and can operate in both FDD and TDD. For convenience of description, it is assumed that the present invention is applied to 3GPP NR. However, the technical features of the present invention are not limited thereto. For example, although the following detailed description is given based on a mobile communication system corresponding to a 3GPP NR system, aspects of the present invention that are not specific to 3GPP NR are applicable to other mobile communication systems. Moreover, the technical features of the present invention may be applied to future iterations of multiple access systems defined in 3GPP standards, such as (but not limited to) 6G.

[0276] The examples may be carried out on any suitable data processing device, such as a personal computer, laptop, mobile telephone, server, virtual machine, and the like. The above description of the systems and methods has been simplified for purposes of discussion, and is intended to provide a specific example to illustrate the invention. Different types of systems and methods may be used, as will be appreciated by the skilled person. It will be appreciated that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or elements, or may impose an alternate decomposition of functionality upon various logic blocks or elements.

[0277] It will be appreciated that the above-mentioned functionality may be implemented as one or more corresponding modules as hardware and / or software. For example, the above-mentioned functionality may be implemented as one or more software components for execution by a processor of the system. Alternatively, the above-mentioned functionality may be implemented as hardware, such as on one or more FPGAs, and / or one or more ASICs, and / or one or more DSPs, and / or other hardware arrangements. Method steps implemented in flowcharts contained herein, or as described above, may each be implemented by corresponding respective modules. Moreover, multiple method steps implemented in flowcharts contained herein, or as described above, may be implemented together by a single module.

[0278] Any of the methods described herein may be implemented as computer software or a “computer program”. The computer program may be configured to control a networkentity (e.g., a server or group of servers) to perform any method according to the disclosure. A network entity (e.g., a server or group of servers) within a cellular network may also be provided, configured to operate in accordance with certain methods disclosed herein. For example, the network entity may include a processor and at least one communication interface, particularly comprising one or both of a transmitter and receiver.

[0279] A storage medium and a transmission medium carrying the computer program are also provided. The computer program may comprise one or more instructions, or code, that, when executed by a computer, causes the methods described to be performed. A computer program may be a sequence of instructions designed for execution on a computer system, and may include a subroutine, a function, a procedure, a module, an object method, an object implementation, an executable application, an applet, a servlet, source code, object code, a shared library, a dynamic linked library, and / or other sequences of instructions designed for execution on a computer system. The storage medium may be a magnetic disc (such as a hard drive or a floppy disc), an optical disc (such as a CD-ROM, a DVD-ROM, or a Blu-ray disc), or a memory (such as a ROM, a RAM, EPROM, EEPROM, Flash memory or a portable / removable memory device), etc. The transmission medium may be a communications signal, a data broadcast, a communications link between two or more computers, etc.

[0280] Each feature disclosed in this specification, unless stated otherwise, may be replaced by alternative features serving the same, equivalent, or similar purpose. Thus, unless stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0281] As used herein, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as "a" or "an" (such as a UE, a network entity, a server or a cell) means "one or more” (for instance one or more UEs, one or more network entities, one or more servers, or one or more cells). Throughout the description and claims of this disclosure, the words "comprise", "including", "having" and "contain" and variations of the words, for example "comprising" and "comprises" or similar, mean "including", and are not intended to (and do not) exclude other components.

[0282] The use of any and all examples, or exemplary language ("for instance", "such as", "for example" and like language) provided herein, is intended merely to better illustrate the invention, and does not indicate a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any nonclaimed element as essential to the practice of the invention.

[0283] Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. Moreover, where a step is described as being performed after a step, this does not preclude intervening steps being performed.

[0284] All of the aspects and / or features disclosed in this specification may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. As described herein, there may be particular combinations of aspects that are of further benefit, such the aspects of determining a set of compensation parameters and applying a set of compensation parameters to measurements. In particular, the preferred features of the invention are applicable to all aspects of the invention and may be used in any combination. Likewise, features described in non- essential combinations may be used separately (not in combination).

[0285] A method of manufacturing and / or operating any of the devices disclosed herein is also provided. The method may comprise steps of providing each of the features disclosed and / or configuring or using the respective feature for its stated function.

Claims

CLAIMS:1 . A method of facilitating one or more application processes in a network function of an Open Radio Access Network, Open RAN, wherein each of the one or more application processes is allocated one or more hardware resources from a plurality of hardware resources available to the network function, the method comprising: defining an interface between the one or more application processes and the allocated hardware resources, wherein the interface is configured to communicate instructions and data between each of the one or more application processes and the allocated hardware resources via one or more underlying physical interfaces, wherein the interface defines one or more methods for carrying out the instructions, wherein each instruction invokes a method defined by the interface, wherein the interface comprises a plurality of rules for translating the instructions and data, wherein each rule is associated with a method and one or more corresponding hardware resources for performing the method.

2. The method of claim 1 , wherein each rule is associated with one or more templates for formatting data to perform the associated method using the one or more hardware resources and / or provide data to the application process, wherein each template corresponds to a respective hardware resource.

3. The method of claim 2, wherein communicating instructions and data between each of the one or more application processes and the allocated hardware resources comprises translating the instructions and data by identifying, for each instruction, a rule associated with the method invoked by the instruction, identifying a hardware resource for carrying out the instruction, and formatting data associated with the instruction according to a template associated with the rule and corresponding to the identified hardware resource.

4. The method of any preceding claim, wherein the one or more underlying physical interfaces comprise one or more of:PCIe;OCP; and ethernet.

5. The method of any preceding claim, wherein the plurality of hardware resources comprises one or more compute kernels and / or RAN processing units, RPUs, wherein each compute kernel and / or RPU comprises a plurality of physical hardware elements.

6. The method of claim 5, wherein the plurality of physical hardware elements comprises one or more: memory units;Central Processing Units, CPUs;CPU cores;Digital Signal Processors, DSPs;Field Programmable Gate Arrays, FGPAs;Application-Specific-lntegrated-Circuits, ASICs;Graphics Processing Units, GPUs; and / or accelerators.

7. The method of claim 5 or claim 6, wherein each compute kernel and / or RPU is configured to implement a Hardware Abstraction Layer, HAL, to communicate instructions and data with the plurality of physical hardware elements.

8. The method of any preceding claim, wherein each of the plurality of hardware resources is associated with an address space particular to a physical location of the respective hardware resource, wherein communicating instructions and data between each of the one or more application processes and the allocated hardware resources comprises: receiving instructions and data from the application process using an address space of the application process; and sending instructions and data to each of the plurality of hardware resources via one or more underlying physical interfaces using the address space particular to the location of the respective hardware resource.

9. The method of claim 8, wherein communicating instructions and data between each of the one or more application processes and the allocated hardware resources further comprises one or more of: establishing a remote connection between the application process and each of the plurality of hardware resources; serializing and / or deserializing the data for communication via the one or more underlying physical interfaces; andperforming network address translation to facilitate communication between the one or more application processes and the allocated hardware resources, so that the allocated hardware resources appear to the respective application processes as if they are in the same address space.

10. The method of any preceding claim, wherein each application process is allocated hardware resources from the plurality of hardware resources based on one or more processing requirements of the respective application process and one or more processing capabilities of the allocated hardware resources.11 . The method of claim 10, wherein the processing capabilities comprise one or more of: an instruction set of the hardware resource; signal processing capabilities of the of the hardware resource; packet processing capabilities of the of the hardware resource; one or more communications protocols for which processing capabilities are supported; and one or more technology standards for which processing capabilities are supported.

12. The method of any preceding claim, wherein defining the interface comprises: parsing an interface definition comprising source code, wherein the source code of the interface definition is written in a human-readable programming language and defines the plurality of rules for translating instructions and data communicated from the one or more application processes via the interface to the one or more allocated hardware resources via the one or more underlying physical interfaces; generating machine code for execution by one or more of the plurality hardware resources, wherein executing the machine code causes the respective hardware resource to carry out the instructions.

13. The method of claim 12, wherein the network function comprises one or more applications and each application comprises a plurality of the application processes, wherein each application is generated by compiling application source code written in a human-readable programming language, wherein the method further comprises: automatically generating a client-side stub based on the source code of the interface definition, wherein the one or more methods are defined in the client-side stub,wherein the client-side stub defines one or more proxies for invoking the associated methods via the interface; and automatically generating one or more server-side skeletons based on the source code of the interface definition, wherein each hardware resource comprises a driver comprising a server-side skeleton, wherein each server-side skeleton defines one or more proxies for carrying out instructions communicated via the interface.

14. A framework for facilitating one or more application processes in a network function of an Open Radio Access Network, Open RAN, the framework configured to perform the method of any preceding claim.

15. A computer program comprising instructions that, when executed on a processor, cause the processor to perform the method of any of claims 1 to 13.

Images