SYSTEM AND METHOD FOR PROVISIONING A PORTABLE VIRTUAL RAN ACROSS MULTIPLE RAN HARDWARE PLATFORMS - Patent application

Abstract

A virtual radio access network (vRAN) system 300 for provisioning a portable virtual radio access network (RAN) on one or more RAN hardware platforms is provided. The virtual radio access network (vRAN) system 300 includes a waveform development kit (WDK) 302 and a waveform execution environment 304. The waveform development kit 302 defines at least one portable radio access network (RAN) application to be instantiated on RAN hardware 326. The waveform execution environment 304 (i) monitors real-time schedulable resources in real time, and (ii) collects and monitors one or more statistics for network automation. The waveform execution environment 304 includes a RAN hypervisor 314. The RAN hypervisor 314 virtualizes at least one attribute of spectrum resources required for provisioning the portable RAN on at least one of the one or more RAN hardware platforms in the RAN hardware.

Description

[Technical field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims priority to Indian Non-provisional Patent Application No. 202041020746, filed on May 16, 2020, the complete disclosure of which is incorporated herein by reference.

[0002] FIELD Embodiments herein relate generally to portable Radio Access Network (RAN) modem and digital signal processing (DSP) applications, and more particularly to systems and methods for provisioning a portable virtual Radio Access Network (RAN) across multiple RAN hardware platforms. [Background technology]

[0003] Digital signal processing, or the application of digital computation to signal processing, is the backbone of wireless communications. Digital signal processors are specialized microprocessor chips whose architecture is optimized to perform digital signal processing operations. Such specialized hardware utilizes special CPU architectures and hardware accelerators that can significantly speed up signal processing applications. Traditionally, DSP software has been designed and developed to run on such specialized hardware.

[0004] A Radio Access Network (RAN) is a part of a mobile communication system that connects wireless devices to the core network. Traditional mobile network infrastructure uses vendor-specific or bundled network technologies that lock users into a specific vendor, resulting in problems managing the various devices present in the same network. The Radio Access Network (RAN) provides access to core network services over a wireless medium. These services are implemented by one or more types of core elements. Operators are working hard to streamline their networks by virtualizing the Radio Access Network (RAN) into a Virtual Radio Access Network (vRAN). A virtualized RAN or cloud RAN runs the baseband functions as VNFs (Virtual Network Functions) in a telecom or public data center. The vRAN can run as a vendor-specific appliance-type base station or can be pooled and run as Virtual Network Function software hosted on standard servers in a data center. In a vRAN, the baseband functions run as virtual machines.

[0005] Figure 1 is a block diagram of a conventional Radio Access Network (RAN) architecture according to the prior art. A conventional RAN includes one or more towers 102A-102N, one or more cell site cabinets 104A-104N, a backhaul 110, and a core network 112. Each cell site cabinet 104A includes a set of radio units (RUs) 106A-106B and a baseband unit (BBU) 108A. In some embodiments, the RUs 106N can be connected to the tower 102N and communicate with the baseband unit (BBU) 108N over a common public radio interface (CPRI) fiber.

[0006] FIG. 2 is an exemplary system diagram of a conventional virtual radio access network (vRAN) architecture according to the prior art. The vRAN includes one or more towers 102A-102N, a fronthaul 202A, a backhaul 202B, a virtual server 205 including one or more virtual base stations 206A-206N, and a core network 112. Referring to FIG. 1 and FIG. 2, in the vRAN, base station software runs as a virtual machine on the virtual server. However, the conventional virtual radio access network (vRAN) as shown in FIG. 1 and FIG. 2 has some limitations.

[0007] In a conventional RAN, the baseband unit (BBU) 108A is implemented based on a custom ASIC or FPGA, whereas in a vRAN, the baseband unit (BBU) 108A is implemented as a software component running on a standard server, e.g., a virtual server 205. In a vRAN, the baseband unit is communicatively coupled to a set of radio units (RUs) 106A-106B mounted on one or more towers 102A-102N via a fronthaul 202A, and to a core network 112 via a backhaul 202B.

[0008] Traditional servers used in vRAN implementations are implemented using CPU architectures built and optimized for various enterprise IT tasks. Using such servers for vRAN implementations requires additional budgetary resources to execute vRAN signal processing-oriented workloads, resulting in increased cost and power requirements. Traditional vRANs sometimes rely on field programmable gate array (FPGA) acceleration, which also increases power consumption. Such purpose-built vRAN software is usually not portable across various hardware skews. Sometimes vRAN software is not even portable across homogeneous instruction set architecture implementations due to vendor-specific constraints. Furthermore, once instantiated, there is no dynamic sharing of RAN workloads across processing elements (PEs).

[0009] Traditional virtual radio access networks (vRANs) are unable to create software-based virtual representations or optimal virtualization of processing elements, and RAN computational resources tend to be highly hardware-dependent. Furthermore, the processing elements themselves are not ''signal aware''. This means that they cannot dynamically reconfigure based on the state of the signal, and therefore cannot achieve substantial power savings without sacrificing performance. The implementation and management of network slices is at the core of 5G RAN development. To effectively implement slicing, radio resources such as spectrum, interference in the spectrum, and other attributes of the spectrum must be virtualized along with the computational resources required for RAN implementation. Currently, containerization of RAN is limited to functions that can be fully specified as VNFs (Virtual Network Functions). In the case of RAN implementation, custom hardware solutions are either not possible or are very difficult to containerize. Also, RAN orchestration is non-existent or functionally limited.

[0010] Existing RAN hardware platforms used in vRAN and RAN that are deployed in existing communication systems include FlexRAN from Intel, SoCASIC based solutions from Marvell, NXP, and TI, and FPGA based solutions from Xilinx and Altera. Each of these solutions has drawbacks, such as lack of openness, limited scalability, excessive power consumption, complex software development, high operational costs, and lack of RAN AI acceleration. All of the aforementioned solutions lack flexibility for independent hardware vendors. In the case of FlexRAN, the ISA is open, but the microarchitecture is closed as the SoCASIC solution is closed. In terms of scalability, the FlexRAN solution is only suitable for data center type deployments. SoCASIC based solutions are typically sized for small or macro cells and do not easily aggregate when scaling up or down. FPGA solutions can be scaled up by aggregating more devices, but require resizing and regeneration of FPGA bitfile / netlist compatibility based on the deployment characteristics, e.g., small cell vs. macro cell.

[0011] Regarding power consumption, (i) the FlexRAN® solution consumes huge amounts of power. Although the SoCASIC® solution consumes less power compared to the FlexRAN and FPGA-based solutions, it cannot dynamically scale power consumption based on the RAN workload. Regarding ease of software development, (i) FlexRAN® software development is cumbersome, platform-dependent, written using a combination of C and assembly, and optimized for a specific processor family, making it difficult to make the implementation portable across platforms. For SoCASIC®, software development is cumbersome and mostly closed with very specific primitives based on the SoC architecture. It is not easy to write for general users and is not portable. For FPGA-based solutions, software development is cumbersome and mostly closed with very specific primitives based on the selected FPGA platform, it is not easy for general users to write, and there is only portability at the register transfer level. Furthermore, platforms such as FlexRAN® have very high operational costs.

[0012] Thus, there is a need to mitigate and / or overcome the deficiencies associated with current systems and methods for designing and developing DSP software, particularly vRAN architectures deployed by carriers. Summary of the Invention

[0013] Embodiments herein provide a virtual radio access network (vRAN) system for provisioning a portable virtual radio access network (vRAN) on one or more RAN hardware platforms. The virtual radio access network (vRAN) system includes a waveform development kit and a waveform execution environment. The waveform execution environment includes a RAN hypervisor. The waveform development kit defines at least one portable radio access network (RAN) application to be instantiated on the RAN hardware. The waveform execution environment (i) monitors schedulable resources in real time, and (ii) collects one or more statistics for network automation and monitors the one or more statistics. The RAN hypervisor virtualizes at least one attribute of spectrum resources required for provisioning the portable virtual radio access network (vRAN) on at least one hardware platform of the one or more RAN hardware platforms on the RAN hardware based on the description of the at least one hardware computational resource on the RAN hardware.

[0014] In some embodiments, a waveform development kit includes: (i) a defined Domain Specific Language (DSL) that captures at least one domain specific pattern for describing functions related to the Radio Access Network (RAN); and (ii) a compiler that converts platform independent (PI) signal processing algorithms, written in the defined Domain Specific Language (DSL), into bytecode or intermediate representation (IR) for execution on RAN target hardware.

[0015] In some embodiments, the defined domain-specific language (DSL) includes (i) stream processing functions that operate on at least one of a number of incoming streams of frames, packets, symbols, or samples, and (ii) control processing functions that emit signals that indicate conditions when processing streams of that type. The stream processing functions (i) take a stream type and transform it into another stream type, or (ii) perform operations on each element of a stream type. Such signals are used by at least one of the (i) other control processing functions, or (ii) the stream processing functions, to perform another action or change the execution path.

[0016] In some embodiments, the RAN hypervisor includes: (i) a RAN compute hypervisor that provides a platform for virtual machines (VMs) on which RAN modem instances run; and (ii) a RAN spectrum hypervisor that virtualizes the RF hardware used to build the radio units and modem-independent RF attributes that are stored in an RF attribute database.

[0017] In some embodiments, the RAN hypervisor distributes and manages dynamic loads associated with virtualized Radio Access Networks (RANs) to Processing Elements (PEs) by scheduling multiple RAN modem instances in a Radio Access Network (RAN) and Digital Signal Processing (DSP) flow graph on the heterogeneous processing elements.

[0018] In some embodiments, a virtual Radio Access Network (vRAN) system includes a RAN orchestrator that creates, deletes, or modifies one or more Radio Virtual Machine (RVM) RAN modem instances for RAN containers running on a RAN hypervisor. The RAN orchestrator instantiates and coordinates various modem entities created on the RAN hypervisor by understanding scheduling information and runtime specifications bundled with the RAN modem instances.

[0019] In some embodiments, a virtual radio access network (vRAN) system includes a modem store that is a cache of intermediate representations of different waveforms generated by a waveform development kit, or RAN modem instances. The intermediate representations are set with scheduling information and runtime specifications derived from constraints in at least one domain-specific pattern specified in a defined Domain Specific Language (DSL) model for execution on target hardware. The intermediate representations are hosted on the modem store together with the scheduling information and runtime specifications.

[0020] In some embodiments, the modem store is connected to a RAN orchestrator to enable provisioning of modems and resources required to run a virtual radio access network (RAN).

[0021] In some embodiments, each runtime specification is a configuration database that describes various runtime and code generation specific aspects that allow the RAN hypervisor to properly map an intermediate representation (IR) of a RAN modem instance to the RAN hardware.

[0022] In some embodiments, the RAN hypervisor manages the use of computing elements on the RAN hardware. Security capabilities provided by the RAN hardware and policies provided in the RAN orchestrator are used by the RAN hypervisor to manage at least one attribute associated with the computing elements.

[0023] In some embodiments, the mapper maps each RAN modem instance to an actual physical processing element in the RAN hardware by (i) analyzing a detailed description of the computing, storage, and interconnect resource elements in each RAN hardware, (ii) correlating that detailed description with a number of constraints provided in the runtime specification of each modem instance, and (iii) creating a mapping of the RAN modem instance across the processing elements of the underlying RAN hardware. The detailed description is described in a Hardware Resource Description (HRD).

[0024] In some embodiments, the multiple tiers of the hypermonitor function include at least one of: (a) a hardware function block that provides an interface function to monitor selectable hardware signals and move data at wire speed to the hypermonitor function for storage; (b) a lower level software function block that interacts with the RAN hardware and sets control signals for monitoring the function groups; and (c) software functions located within the RAN hypervisor for storing and querying a database created by the hypermonitor function. The lower level software function block operates within a small inference engine to determine the control signals. The lower level software function block provides filter signals to reduce unnecessary data transfers. The software block performs inferences on the stored data for use by the automation and radio interface controller (RIC).

[0025] In some embodiments, a virtual radio access network (vRAN) system slices radio frequency channels and virtualizes the channels in at least one of the time, frequency, or spatial domains, enabling implementation of the slicing concept in 5G and other communications modes.

[0026] In some embodiments, the RAN spectrum hypervisor uses an artificial intelligence (AI) prediction engine against an RF attribute database to design RF attribute aware waveforms to leverage spectrum resources.

[0027] In another aspect, a method for provisioning a portable virtual radio access network (RAN) on one or more RAN hardware platforms is provided, the method including: (i) defining, by a waveform development kit, at least one portable radio access network (RAN) application to be instantiated on RAN hardware, (ii) monitoring, by a waveform execution environment, schedulable resources in real time, (iii) collecting, by the waveform execution environment, one or more statistics and monitoring the one or more statistics for network automation, and (iv) virtualizing, by a RAN hypervisor, at least one attribute of spectrum resources necessary for provisioning the portable radio access network (RAN) on at least one hardware platform of the one or more RAN hardware platforms on the RAN hardware based on the description of the at least one hardware computational resource on the RAN hardware.

[0028] In some embodiments, the method includes scheduling multiple RAN modem instances in a RAN flow graph such that the RAN workload is dynamically shared among multiple processing elements (PEs) using a RAN hypervisor.

[0029] In some embodiments, the method includes using hyper-observability to enable dynamic reconfiguration of RAN hardware based on RF and signal conditions.

[0030] In some embodiments, the method includes auto-learning based on past decisions and inputs from a hypermonitor for spectral resource utilization.

[0031] In some embodiments, the method includes mapping each RAN modem instance to actual physical processing elements throughout the RAN hardware by: (i) analyzing a detailed description of the computing, storage, and interconnect resource elements within each RAN hardware; (ii) correlating the detailed description with a number of constraints provided in a runtime specification for each modem instance; and (iii) creating a mapping of the RAN modem instance across the processing elements of the underlying RAN hardware.

[0032] In some embodiments, the method includes (a) providing an interface function that monitors selectable hardware signals and moves data at wire speed to a hypermonitor function for storage; (b) interacting with the RAN hardware to set control signals for functional group monitoring; and (c) storing and querying in a database created by the hypermonitor function. Filter signals are provided to reduce unnecessary data transfers. Inference is performed on the stored data for use in the automation and radio interface controller (RIC). A small inference engine operates to determine the control signals.

[0033] The Domain Specific Language (DSL) model of the virtual Radio Access Network (vRAN) system combined with the runtime system is hardware independent and does not rely on static mapping to hardware. The DSL model describes (i) various RAN related configurations such as number of carriers, pilot modes, and definition of new pilot modes, (ii) RAN specific invariants such as noise figure, timing constraints, (iii) definition of feedback loops associated with the RAN, and (iv) definition of fast and slow paths in the RAN environment. In some embodiments, the RAN paths include broadcast paths. The DSL model allows the user to define stream processors. The waveform development kit translates the DSL model into bytecode. The bytecode is mapped onto the underlying hardware by the RAN hypervisor. The RAN hypervisor virtualizes compute and RF resources together. The RAN hypervisor virtualizes spectrum resource attributes such as interference, fading, etc. The RAN hypervisor facilitates load balancing of virtual RAN modems.

[0034] An Al-first architecture that extends from the dynamic data path in the hardware to the RAN hypervisor and the RAN modem itself. An example is an Al-driven monitoring path that helps with load balancing and reporting of key statistics for optimization and load balancing by the RAN hypervisor. The virtual Radio Access Network (vRAN) system enables clean abstraction for new RAN hardware, enabling portability without the need to change the waveform execution environment. The virtual Radio Access Network (vRAN) system efficiently implements the vRAN architecture. The virtual Radio Access Network (vRAN) system includes the ability to introduce microservices for the RAN by allowing new components to be added on-the-fly to the signal processing pipeline and dynamic monitors to be added. The virtual Radio Access Network (vRAN) system virtualizes both radio and compute resources to enable optimal implementation of network slices and optimal utilization of radio resources. The virtual Radio Access Network (vRAN) system collects real-time data, performs inference for the Radio Interface Controller (RIC), and provides architectural constructs to enforce good design practices such as problem isolation. The vRAN system reduces debug and provisioning time during vRAN deployment. The virtual Radio Access Network (vRAN) system contains a highly scalable hardware architecture for efficiently running RAN modem and DSP applications.

[0035] These and other aspects of the embodiments herein will be better understood when considered in conjunction with the following description and the accompanying drawings. While the following description sets forth preferred embodiments and many specific details relating to the embodiments, it should be understood that these are presented by way of example and not by way of limitation. Many changes and modifications can be made to the embodiments herein without departing from the spirit thereof and within the scope of the embodiments herein, and the embodiments herein are intended to include all such modifications. [Brief description of the drawings]

[0036] The embodiments herein will be better understood from the following detailed description taken in conjunction with the following drawings, in which:

[0037] [Figure 1] FIG. 1 is a block diagram of a conventional Radio Access Network (RAN) architecture according to the prior art.

[0038] [Diagram 2] FIG. 1 is an exemplary system diagram of a conventional virtual radio access network (vRAN) architecture according to the prior art.

[0039] [Figure 3A] FIG. 3 is a block diagram illustrating a virtual radio access network (vRAN) system 300 for provisioning a portable virtual radio access network (vRAN) across one or more RAN hardware platforms, in accordance with some embodiments herein.

[0040] [Figure 3B] FIG. 3B is an exploded view of the virtual radio access network (vRAN) system of FIG. 3A, in accordance with certain embodiments herein.

[0041] [Figure 3C] FIG. 3C is an exploded view of the RAN hypervisor of FIG. 3B, in accordance with certain embodiments herein.

[0042] [Figure 4] FIG. 2 is a graph illustrating a relationship between an Orthogonal Frequency Division Multiplexing (OFDM) signal and Orthogonal Frequency Division Multiplexing (OFDM) subcarriers, in accordance with some embodiments herein.

[0043] [Diagram 5]3B, an example block diagram of a hypermonitor function 504 for recording and optimizing inputs to at least one of (i) the RAN orchestrator or (ii) the RAN hypervisor is shown, in accordance with certain embodiments herein.

[0044] [Figure 6A] FIG. 1 is an example diagram illustrating a mapping of the signal chain to RAN hardware 326 including processing elements (PEs) of a typical COTS processor such as an Intel Xeon, digital signal processor (e.g., from TI) or field programmable gate array (FPGA) environment, in accordance with some embodiments herein. [Figure 6B] Same as above [Figure 6C] Same as above

[0045] [Figure 7] 1 is a flowchart illustrating a method for provisioning a portable virtual Radio Access Network (vRAN) across one or more RAN hardware platforms, in accordance with some embodiments herein.

[0046] [Figure 8] FIG. 1 is a schematic diagram of a computer architecture according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0047] The following detailed description illustrates embodiments of the disclosure and ways in which it can be practiced. Although several ways of practicing the disclosure are disclosed, those skilled in the art will recognize that other embodiments are possible for practicing or implementing the disclosure.

[0048] Definition:

[0049] Hypervisor: A hypervisor is a module that runs on a computing device and virtualizes the underlying resources for the purpose of creating and managing virtual machines. In some embodiments, a hypervisor is a module that presents a unified view of RAN hardware resources to the virtual machines. A virtual machine is a modem that runs as a module in or on the hypervisor and uses RAN hardware resources. The RAN hardware resources are at least one of a cluster of DSPs or FPGAs, or any other computing element. In some embodiments, a RAN virtual machine is considered a RAN OS. The RAN OS in a virtual machine can run one or more instances of a modem. In some embodiments, the hypervisor schedules to provide time slices for guest RAN OS to run on processor cores.

[0050] Container: A container allows several instances of an application to run on the same operating system. In some embodiments, a container virtualizes the operating system in the same way that a virtual machine virtualizes hardware.

[0051] VNF (Virtual Network Function): A VNF (Virtual Network Function) is a network element implemented as a software component and running on a virtual machine or container. In some embodiments, the allocation of resources to a VNF is performed by an orchestrator.

[0052] Flow Graph: A flow graph is a set of interconnected processing nodes that perform a one-way modem function. In a RAN modem implementation, at least two flow graphs are required, one for each direction (downlink and uplink). A RAN flow graph is a flow graph that implements a RAN function.

[0053] Hypermonitor: A hypermonitor is an entity that collects statistics on resource utilization and workload from the underlying processing elements to provide to the orchestrator for optimizing overall system efficiency. In some embodiments, the hypermonitor can provide input directly to the hypervisor. In some embodiments, there are two types of statistics: (i) statistics on resource usage, allocation, and other attributes of the processing elements, including the RAN hardware, and (ii) statistics on the baseband and RF functions of the modem, such as noise figure, CQI, and other attributes. In some embodiments, these two types of statistics allow instantiation of a dynamic component of the hypermonitor, which runs as software on the RAN hardware.

[0054] In some embodiments, the Radio Virtual Machine (RVM) or modem may instantiate a hypermonitor component specific to its function and provide an interface and input to the hypervisor for optimal resource allocation or other cost functions such as power and / or performance.

[0055] RAN functions need to be implemented in a virtualized manner independent of the RAN hardware platform to be portable. The present system enables the design and deployment of a portable RAN solution with RAN containerization. The present system relates to a) the software implementation of the physical layer of the baseband unit and the radio unit, and b) the design of the server on which the software runs. The portable RAN is designed and implemented by (i) building on and combining concepts of Domain Specific Languages ​​(DSLs) for describing and designing RAN software in a platform-independent manner, (ii) virtualization using a hypervisor that virtualizes the radio frequency (RF) and RAN computation resources, and (iii) utilizing RAN hardware onto which the RAN functions can be mapped (e.g., a platform capable of implementing Digital Signal Processing (DSP) functions).

[0056] In the present vRAN system, portability of RAN software across any hardware implementation is achieved by (i) describing DSP functions (for RAN and other applications) in a platform-independent manner using a Domain Specific Language (DSL), and (ii) executing one or more RAN functions on a given hardware while meeting the timing deadlines, latency, data consistency, and processing requirements of the described functions.

[0057] In the vRAN system, dynamic sharing of RAN workload among processing elements (PEs) is achieved through the use of a RAN hypervisor using methods to schedule multiple instances of a RAN flow graph across heterogeneous processing elements (e.g., but not limited to, CPUs, acceleration units, or FPGAs), data holding memories, data forwarding engines, and communication buses.

[0058] The vRAN system relies on a highly scalable hardware architecture for efficient execution of DSP functions for RAN and other applications. The vRAN system maximizes the pooling gain described in vRAN by scaling DSP processing. The vRAN system includes hyper-observability, which allows dynamic reconfiguration of the hardware based on RF and signal conditions. The vRAN system further includes RAN AI acceleration engines at each level of the computational hierarchy, from the hardware datapath forming the processing elements, to other processing elements such as digital signal processors or FPGAs, to hypervisor software and virtual machine software.

[0059] The vRAN system includes hardware and software features such as a hypervisor that allows for faster and improved RAN functions and improves the hypervisor's ability to better virtualize resources such as PEs. Another aspect of the hypervisor is its ability to auto-learn based on past decisions and inputs from the hypermonitor. All decisions on how resources are partitioned and distributed are stored in the hypermonitor database. An inference engine runs partly on the hypervisor and partly on the RAN hardware to optimally use the various cost functions defined. The hypermonitor collects data to infer workload conditions and dynamically reconfigures the processing elements (PEs) according to specific triggers set on the PEs. The collected parameters are used to optimize performance with respect to various cost functions (e.g., but not limited to, power consumption, die size, etc.).

[0060] In this vRAN system, the definition and design of signal processing algorithms is separated from their actual execution on the platform. This allows the signal processing functions designed for the RAN and other modems / communication receivers to be abstracted into two main components: (i) platform independent (PI) parts and (ii) platform dependent (PD) functions.

[0061] The platform independent (PI) part describes the algorithm or "what" part and is usually done by those skilled in the art without hardware knowledge, for example by prototyping in frameworks such as MATLAB® and Octave.

[0062] Platform-dependent (PD) functions transform signal processing algorithms for implementation on specific hardware, optimizing the power and cost of the implementation. These tend to be done using special combinations of software and hardware.

[0063] The vRAN system includes a method for describing platform-dependent and platform-independent functions of a signal processing application to achieve cross-platform portability.

[0064] Details of the embodiments of the present specification and various features and effects thereof will be more fully described with reference to the non-limiting embodiments shown in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as not to unnecessarily obscure the embodiments of the present specification. The examples used in the present specification are intended only to facilitate understanding of the manner in which the embodiments of the present specification can be implemented and to enable those skilled in the art to implement the embodiments of the present specification. Therefore, the examples should not be interpreted as limiting the scope of the embodiments of the present specification.

[0065] As noted above, a need remains for systems and methods for designing portable Radio Access Network (RAN) modems and digital signal processing (DSP) applications. Referring now to the drawings, and more particularly to Figures 3A-8, a preferred embodiment is shown, with like reference characters indicating corresponding features consistently throughout the drawings.

[0066] FIG. 3A is a block diagram illustrating a virtual radio access network (vRAN) system 300 for provisioning a portable virtual radio access network (vRAN) across one or more RAN hardware platforms, according to some embodiments herein. The virtual radio access network (vRAN) system 300 executes components and modules of the virtual radio access network (vRAN) system 300 on a computing device 301 to design virtual RAN modem and DSP applications related to the functions of the radio units 106A-106B and the virtual base stations 206A-206N. In some embodiments, such components may include a hypervisor, an orchestrator, and containers associated with an execution environment. In some embodiments, the orchestrator is responsible for the control and life cycle management of the virtual machines. In some embodiments, the computing device 301 is selected from at least one of a compute server, a personal computer, a tablet, a laptop, or an e-notebook. In some embodiments, the one or more RAN hardware platforms include, but are not limited to, an ISA or DSP-based platform, a FlexRAN platform, a SoCASIC-based platform, and an FPGA-based platform.

[0067] 3B illustrates an exploded view of the virtual radio access network (vRAN) system 300 of FIG. 3A according to some embodiments herein. The virtual radio access network (vRAN) system 300 includes a waveform development kit (WDK) 302, a waveform execution environment 304, a RAN orchestrator 312, and a hardware resource description 324. The WDK 302 includes a defined domain specific language (DSL), a compiler or interpreter (not shown) for describing functions associated with portable RAN modems and DSP applications (not shown), as well as a modem store 308 and runtime specifications for each DSP application. The waveform execution environment 304 includes a RAN hypervisor 314, one or more modems 320A-320N from within the modem store 308, and respective RAN containers 332A-332N and radio virtual machines (RVMs) 322A-322B. The Radio Virtual Machines (RVMs) 322A-322B perform the basic functions of a typical operating system, such as scheduling and address space isolation, to allow each modem to operate as an independent slice.

[0068] The Waveform Development Kit (WDK) 302 is a development environment for defining portable RAN applications and translating the portable RAN applications into a form that is instantiated on the RAN hardware 326. RAN signal processing applications are directed flow graphs that operate on streams of data. The defined DSL captures these domain specific patterns (e.g., flow graphs). In some embodiments, if new patterns are coded in a procedural language such as C, they are cumbersome and time consuming to develop and understand, and increase the representation of the system's complexity. The ability to describe patterns and abstractions within a domain allows complex systems to be built much faster and easier.

[0069] The defined DSL provides abstractions for the description of modem flow graphs for building complex RAN modems and DSP applications making their development faster and easier. In some embodiments, the defined DSL provides built-in types for domain-specific operations such as FFT, filtering, convolution, etc. In some embodiments, the defined DSL allows for the addition of other built-in types derived from at least one of the base types or new operations. The defined DSL natively handles fixed-point types, allowing developers to focus on abstracting the functionality required for the modem flow graph without digging into implementation details. In some embodiments, the defined DSL is at least one of a new language or one implemented in any host language such as C++, Rust, etc. The defined DSL includes stream processing functions, control processing functions, and additional mechanisms to connect different stream processing functions and schedule their execution based on each function. The stream processing functions operate on at least one of the incoming streams of frames, packets, symbols, or samples. A stream processing function (i) takes a stream type and converts it to another stream type, or (ii) performs an operation on each element of a stream type. For example, a scrambler takes a bit stream and produces another bit stream. In some embodiments, a symbol mapper takes a bit stream and produces a symbol stream. A DSL provides built-in functions to perform the aforementioned operations. In some embodiments, a DSL allows users to create generic or built-in stream processing functions.

[0070] The control processing function emits a signal indicating a condition in processing the stream. For example, a synchronization process that emits a signal when a symbol or frame boundary is detected. In some embodiments, the signal is used by at least one of (i) another control processing function, or (ii) a stream processing function to perform another action or change the execution path. The defined DSL includes one or more mechanisms for connecting multiple stream processing functions using data ports with appropriately specified input or output directions. The defined DSL includes one or more mechanisms for scheduling the activities of the stream processing functions in parallel or serial time. The defined DSL includes configurations for specifying timing, data rate, or any other constraints on either the input or output ports of the stream processing functions. These are examples of DSLs used herein, and are intended only to facilitate an understanding of how the embodiments of the present specification may be implemented, and to enable one of ordinary skill in the art to implement the embodiments of the present specification. Thus, the examples should not be construed as limiting the scope of the embodiments of the present specification.

[0071] A compiler or interpreter converts platform independent (PI) signal processing algorithms written in a DSL, called a DSL model, into bytecode or intermediate representation (IR) 310 for execution on target hardware. In some embodiments, the IR 310 is bundled with scheduling information and runtime specifications 330A-N derived from constraints in the flow graph specified in the DSL model. The IR 310 is hosted on the modem store 308 along with the scheduling information and runtime specifications 330A-N. The modem store 308 is a cache or one or more instances of intermediate representations of different waveforms generated by the WDK 302. In some embodiments, the bytecode can be executed on any platform of a virtual machine (VM) or RAN container 332A-N that partitions the execution of multiple instances of the modem.

[0072] In some embodiments, the RAN container 332A-332N virtualizes operating system resources, allowing the RAN hardware 326 to be virtualized by multiple instances of an application on the same operating system, or by multiple instances of the RAN container 332A-332N on multiple operating systems if virtual machines are present. Each runtime specification 328A-328N is a configuration database that describes various runtime and code generation specific aspects that allow the RAN hypervisor 314 to properly map the IR of the modem instance 306 to the RAN hardware 326. Each runtime specification 328A-328N specifies at least one of the following parameters, which may be part of the runtime specification 328A-328N: (i) the width of the data types mentioned in the defined DSL model; (ii) the numerical representations that are automatically identified as part of the simulation process; (iii) the overall noise filter or constraints on digital noise; (iv) support for specifying all types of simulation environments such as Matlab, Octave, FlexRAN, NXP, and other platforms; (v) the buffer management type and IQ sample buffer type, which may be at least one of interleaved or collocated; (vi) the width of the data types mentioned in the DSL model may be applied per block of the pipeline or for the entire chain.

[0073] In some embodiments, the RAN orchestrator 312 is responsible for creating, deleting, or modifying instances of the virtual machines of the RAN containers 332A-N that run on the RAN hypervisor 314. This includes scaling the instances up and down. In some embodiments, the hardware resource description 324 is at least one of: (i) processing elements on the line of cores, a hierarchy of processing elements, etc.; (ii) memory access latencies and storage hierarchy; (iii) details of each processing element such as performance, power, data, code size requirements, etc.; (iv) the number of processing tiles, the number and type or characteristics of processors within a tile, and (v) a description of the network of interconnect buses connecting the various processing elements and their properties and protocols such as topology, tile connectivity graph, data width, and transfer rates. In some embodiments, the modem store 308 is connected to the RAN orchestrator 312 and enables the provisioning of modems and resources required to perform the RAN modems and DSP functions.

[0074] The RAN orchestrator 312 provides the flexibility to run Radio Virtual Machines (RVMs) 322A-322B from different vendors. The RAN orchestrator 312 instantiates and coordinates between various modem entities created on the RAN hypervisor 314 through understanding the scheduling information and runtime specifications 328A-328N bundled with each modem instance 306.

[0075] The RAN hypervisor 314 virtualizes the attributes of the spectrum resources 338 as well as the computations required to provision RAN functions on the spectrum resources 338 (e.g., spectrum). In some embodiments, the RAN hypervisor 314 distributes and manages the dynamic load associated with the RAN modem and DSP applications among the processing elements by scheduling multiple instances of the RAN and DSP flow graphs on the heterogeneous processing elements. In some embodiments, the RAN containers 332A-332N are host applications directly associated with the RAN modem and DSP applications on the RAN hypervisor 314. In some embodiments, the RAN virtual machines run instances associated with the RAN modem and DSP applications in bare metal containers or in radio virtual machines (RVMs) 322A-322B.

[0076] The waveform execution environment 304 includes a hypermonitor (bookkeeping) function that performs at least one of: (i) monitoring schedulable resources in real time to determine a cost function associated with their utilization; (ii) collecting one or more statistics required by the RAN hypervisor 314 for network automation; or (iii) storing data for offline inference to improve the performance of the RAN hypervisor 314. In some embodiments, the RAN and DSP statistics include at least one of constellation, channel impulse response, interference, bit error rate (BER), received signal strength indicator (RSSI), or other radio frequency channel quality indicators. The virtual server 205 (shown in FIG. 3A) represents the waveform execution environment 304, where the modem instances created by the waveform development kit (WDK) 302 are executed. These modem instances represent the virtual base stations 206A-206N as shown in FIG. 3A. The RAN orchestrator 312 on the virtual server 205 manages the instantiation and lifecycle management of the virtual base stations 206A-206N.

[0077] The RAN hardware 326 includes one or more RAN hardware platforms 340A-340N, including, but not limited to, ISA or DSP-based platforms, FlexRAN platforms, SoC ASIC-based platforms, and FPGA-based platforms.

[0078] In some embodiments, the multiple tiers of the hypermonitor function include at least one of hardware function blocks, lower level software functions, or software functions. The hardware function blocks provide an interface function to monitor selectable hardware signals and move data at wire speed to the hypermonitor function for storage. The lower level software function blocks interact with the hardware and set control signals for monitoring functions. The lower level software function blocks may operate within a small inference engine to determine the control signals. In some embodiments, the lower level software function blocks provide filter signals to reduce unnecessary data transfers. Software functions located within the RAN hypervisor 314 may be used to store and query the database created by the hypermonitor function. The software blocks may perform inference on the stored data for use by the automation and radio interface controller (RIC).

[0079] In some embodiments, the trigger condition can range from (i) a simple pattern match condition with the data / signal in the modem or a measured statistical characteristic of a signal or event, to (ii) the output of a predefined finite state machine with a state transition sequence. In some embodiments, the storage condition includes (i) storing a specified number or all samples of the signal after the trigger condition is met, and (ii) storing samples at specific discrete events generated by the state machine. The hardware supports the implementation of programmable state machines to allow detection of specific predefined statistical characteristics of the signal. The statistical characteristics can be, for example, median, standard deviation, dynamic range of the signal, programmable state transitions of states based on the value of the signal, etc. Such hardware-based mechanisms allow wire-speed data processing to extract characteristics in real time.

[0080] FIG. 3C is an exploded view of the RAN hypervisor 314 of FIG. 3B according to some embodiments herein. The RAN hypervisor 314 optimizes the use of computing elements on the RAN hardware 326 using constraints on the overall NF or digital noise. The RAN hypervisor 314 includes a RAN compute hypervisor 316 and a RAN spectrum hypervisor 318. The RAN compute hypervisor 316 provides a platform for virtual machines (VMs). RAN modems may run on it. The RAN compute hypervisor 316 includes a load balancer unit 342, a mapper unit 344, a monitor unit 346, a router unit 348, a virtualizer unit 350, and a provisioning unit 352. The load balancer unit 342 tracks the hardware processing elements (PEs) and assigns the processing elements (PEs) to virtual machines of the virtual RAN. The load balancer unit 342 manages abstract variables (e.g., data buffers), their lifetimes and mapping to memory, scheduling of data transfers, and avoiding the risk of data overflow or underflow. In some embodiments, the load balancer unit 342 tracks the load of each RAN instance and uses statistical multiplexing of the processing load to resize the virtual machines. In some embodiments, the load balancer unit 342 includes a hypermonitor function associated with each RAN instance. Each RAN instance tracks scheduled Radio Bearers (RBs) and dynamic load associated with the RAN instance.

[0081] The mapper unit 344 schedules and manages the RAN instances on the RAN hardware 326. Each RAN modem instance 306 created has a peak load and resource requirements. The mapper unit 344 maps each RAN modem instance 306 to an actual "physical processing element" in the RAN hardware 326. The mapper unit 344 analyzes detailed descriptions of the computational, storage, and interconnection resource elements in each RAN hardware 326. In some embodiments, the detailed descriptions are described in the Hardware Resource Description (HRD) 324. The mapper unit 344 correlates the detailed descriptions with a number of constraints provided by the run-time specification of each modem instance 306, thus creating the most efficient mapping of the RAN modem instance 306 to the processing elements of the underlying RAN hardware 326.

[0082] In some embodiments, the mapper unit 344 is designed to efficiently map a given modem instance 306 to any RAN hardware as long as an HRD description can be provided for the RAN hardware 326. The mapper unit 344 tracks the load and scales the processing power based on statistics about the actual execution. In some embodiments, when a new thread is introduced, peak demand resources are allocated to the instance. The monitor unit 346 obtains statistics and monitors the RAN modem for higher level functions. The router unit 348 sets up DMA from the fronthaul to various memories and also performs memory transfers between multiple memories and interconnect bus hierarchies. The virtualizer unit 350 virtualizes the RAN hardware resources. The provisioning unit 352 provisions new modem instances 306.

[0083] In some embodiments, the RAN hypervisor 314 uses hardware primitives or assistance provided by the hypermonitor or any similar functionality to speed up the mapping and scheduling process. The RAN hypervisor 314 uses security capabilities provided by the hardware and policies mentioned in the RAN orchestrator 312 to restrict access to certain aspects or attributes of the underlying RAN hardware 326. The RAN spectrum hypervisor 318 virtualizes spectrum resources 338 such as spectrum along with shared attributes such as unlicensed, licensed, interference, etc. In some embodiments, the RAN spectrum hypervisor 318 enables late binding of RAN modems to corresponding spectrum resources described by a Domain Specific Language (DSL). The RAN spectrum hypervisor 318 enables at least one of: (i) partitioning or sharing RF channels among multiple radios based on different cost of functionality, e.g., partitioning a single RF channel to run at least one of IoT radios, broadcast radios, and any type of modem; (ii) aggregating non-contiguous RF channels and presenting them as a single RF channel; or (iii) virtualizing a given portion of the spectrum and allowing it to be shared independently among multiple modems. In some embodiments, the slicing and virtualization of RF channels is performed in at least one of the time domain, frequency domain, or spatial domain (mapping to antennas) to enable efficient implementation of the concept of "slicing" in 5G and other communication modems.

[0084] In some embodiments, the RAN spectrum hypervisor 318 virtualizes the RF hardware 334 used to construct the radio units 106A-106B and modem independent RF attributes stored in an RF attribute database 336, such as interference and fading, adjacent channels, rejection, protection ratios, ACLR / ACPR, licensed bands, and unlicensed bands. Virtualizing RF resource specific attributes helps modems to concatenate and channelize multiple RF channels without worrying about RF specific characteristics. RF attributes of spectrum resources 338 are sensed by the RF hardware 334 and stored in the RF attribute database 336. The RAN hypervisor 314 uses the information to allocate physical RAN hardware resources and implement attribute specific corrections such as precoding, etc., that are independent of the modem implementation. The RAN hypervisor 314 can implement channel sounding signals that are independent of the modem standard. In another embodiment, the RAN spectrum hypervisor 318 uses an artificial intelligence (AI) prediction engine against the RF attribute database 336 to perform RF attribute aware waveform design to better utilize the spectrum resources 338.

[0085] FIG. 4 is a graphical diagram illustrating the relationship between an Orthogonal Frequency Division Multiplexing (OFDM) signal and an Orthogonal Frequency Division Multiplexing (OFDM) subcarrier according to some embodiments herein. The graphical diagram is mapped between frequency and time to analyze the OFDM subcarriers and OFDM symbols for purposes of determining an averaging window 402 associated with a hypermonitor. In some embodiments, an OFDM subcarrier may include one or more subbands 404A-404N. When designing portable RAN modems and DSP applications, the hypermonitor function enables at least one of dynamic range detection, noise power estimation, SNR estimation, or delay spread estimation. Dynamic range detection determines optimal scaling factors required for different types of programmatic operations in components of the signal processing chain.

[0086] The types of scaling factors used are (i) scaling by the sum of the impulse response values ​​(magnitude) (L1 norm), (ii) scaling by the square root of the sum of the squares of the impulse response values ​​(L2 norm), and (iii) scaling by the maximum frequency response (Chebyshev norm). Scaling by the sum of the impulse response values ​​(L1 norm) limits the magnitude of the digital system at any node to less than 1 for systems using the QM format. Here, M is equal to (P-1), where P is the number of bits used in the fixed-point representation. If the maximum input signal Xmax to the digital system is (1-2^(-M)), then the output of the digital system is limited to {y(n)}<1, provided that the scaling factor is limited by G<1 / {Xmax*Sigma[mod Hk]} for k in the range 0 to N-1}, where Hk is the impulse response of a filter of length N. The summation term Sigma[mod Hk], with k ranging from 0 to N-1, is called the L1 norm.

[0087] For scaling by the square root of the sum of the squares of the values ​​of the impulse response (L2 norm), the available scaling factors are: G<1 / {Xmax*Sqrt(Sigma[H(k)^2] for k in the range 0 to N-1)}. Said norm is called the L2 norm and is always smaller than L1. In some embodiments, scaling by the sum of the values ​​of the impulse response (L1 norm) and scaling by the square root of the sum of the squares of the values ​​of the impulse response (L2 norm) are used for wideband signals.

[0088] Scaling by maximum frequency response (Chebyshev norm) is used to determine the applicable scaling factors when the input is a narrowband signal. In this method, first the magnitude response at the input frequency is determined and then multiplied by the maximum input signal Xmax to determine the scaling gain: G<1 / {Xmax*max[H(wk)]} The term max[H(wk)] is known as the Chebyshev norm of the frequency response H(w). This ensures that the steady-state response of the system to a sinusoidal input never overflows.

[0089] Noise estimation is performed by collecting instantaneous noise statistics from OFDM carriers and averaging the noise statistics separately within multiple subgroups. Then, noise statistics from multiple Orthogonal Frequency Division Multiplexing (OFDM) symbols are averaged to enhance the noise power estimation. Based on these noise power estimates, both the color and the variance of the noise statistics are determined as short-term or long-term estimates. The SNR estimate is determined using various estimators (e.g., maximum likelihood (ML) estimator and minimum mean square estimator (MMSE), Boumard estimator, or Ren estimator). The SNR estimator requires probing of the received signal Y(n), the channel estimate H(n), and predefined pilot or training signal strengths based on which second moment is calculated. Another method utilizes a preamble symbol that can be probed. In some embodiments, the SNR is determined for both frequency selective and non-selective channels. The delay spread estimate is determined by using the channel frequency response and calculating the estimated correlation over multiple symbols.

[0090] 5 illustrates an example block diagram of a hypermonitor function 504 for recording and optimizing inputs to at least one of (i) the RAN orchestrator 312 or (ii) the RAN hypervisor 314 of FIG. 3B according to some embodiments herein. The hypermonitor function 504 probes the outputs of multiple signal processing stages 502A-502N operating based on corresponding configuration parameters. The probed outputs are analyzed to make estimates of signal statistics in terms of dynamic range, SNR, noise power, delay spread, etc., to determine appropriate stimuli for the next signal processing stage. In some embodiments, the output signal from the Nth signal processing stage is the final output.

[0091] 6A-6C are exemplary diagrams illustrating the mapping of a signal chain to RAN hardware 326, including processing elements (PEs) of a typical COTS processor, such as an Intel Xeon, digital signal processor (e.g., from TI), or field programmable gate array (FPGA) environment, according to some embodiments herein. In some embodiments, schedulable resources for mapping the signal chain to processing elements in a digital signal processor or FPGA environment include at least one of tiles or groups of processors, memory hierarchy and latency associated with each memory, and DMA and other IO mechanisms shared and virtualized across RAN modems and DSP functions. In some embodiments, the processing elements can use schedulable resources spatially or temporally, or a combination of both. FIG. 6A is an example of mapping two OFDM streams to different tiles over time. In some embodiments, separate streams are dynamically mapped to different tiles. The allocation to the processing elements is done at OFDM symbol boundaries or with finer time resolution. FIG. 6B shows an example in which signals are time-multiplexed within a symbol time and mapped to processing elements within the same processing tile.

[0092] Figure 6C is an example of statically mapping different tasks to different tiles. In some embodiments, the RAN hypervisor 314 performs the spatial or temporal mapping depending on the execution of the network slice. The RAN hypervisor 314 understands memory latency attributes and power consumption attributes. These attributes can be additional cost functions in determining how to map signal processing chain blocks to processing elements.

[0093] 7 is a flow chart illustrating a method for provisioning a portable virtual radio access network (RAN) on one or more RAN hardware platforms, according to some embodiments herein. At step 702, at least one portable radio access network (RAN) application is defined in a form to be instantiated on the RAN target hardware. At step 704, real-time monitoring of schedulable resources is performed. At step 706, one or more statistics are collected and monitored for network automation. At step 708, at least one attribute of spectrum resources required for provisioning a portable virtual radio access network (vRAN) on at least one hardware platform of the one or more RAN hardware platforms is virtualized based on the description of at least one hardware computational resource in the RAN hardware 326.

[0094] In some embodiments, the method includes scheduling multiple RAN modem instances 306 in a RAN flow graph using a RAN hypervisor 314 such that the RAN workload is dynamically shared among multiple processing elements (PEs).

[0095] In some embodiments, the method includes using hyper-observability to enable dynamic reconfiguration of the RAN hardware 326 based on RF and signal conditions.

[0096] In some embodiments, the method includes auto-learning based on past decisions and input from a hyper monitor for utilization of the spectral resources 338 .

[0097] In some embodiments, the method includes mapping each RAN modem instance 306 to actual physical processing elements on the RAN hardware 326 by: (i) analyzing a detailed description of the computational, storage, and interconnect resource elements in each RAN hardware 326; (ii) correlating the detailed description with a number of constraints provided by a run-time specification of each modem instance 306; and (iii) creating a mapping of the RAN modem instance 306 on the processing elements of the underlying RAN hardware 326.

[0098] In some embodiments, the method includes (i) providing an interface function that monitors selectable hardware signals and moves data at wire speed to a hypermonitor function for storage, (ii) interacting with RAN hardware 326 to set control signals for functional group monitoring, and (iii) storing and querying in a database created by the hypermonitor function. In some embodiments, a small inference engine operates to determine the control signals. In some embodiments, filter signals are provided to reduce unnecessary data transfers. In some embodiments, inference is performed on the stored data for use in the automation and radio interface controller (RIC).

[0099] Embodiments herein may include computer program products configured to include pre-configured instructions that, when executed, can perform operations as described in connection with the methods described above. In one example, the pre-configured instructions can be stored on a computer-readable, tangible, non-transitory medium or program storage device. In one example, the computer-readable, tangible, non-transitory medium can be configured to include instructions that, when executed by the device, can cause the device to perform operations as described herein. Embodiments herein may also include computer-readable, tangible and / or non-transitory storage media for carrying or storing computer-executable instructions or data structures.

[0100] Generally, as used herein, program modules include routines, programs, components, data structures, objects, and functions specific to the design of a special purpose processor or the like to perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules are examples of the program code means for executing steps of the methods disclosed herein. A particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.

[0101] The embodiments herein may include both hardware and software elements, and a software implemented embodiment may include, but is not limited to, firmware, resident software, microcode, etc.

[0102] A data processing system suitable for storing and / or executing program code includes at least one processor coupled directly or indirectly via a system bus to storage elements which may include local memory for use in the actual execution of the program code, mass storage devices, and cache memory for temporarily storing at least portions of the program code to reduce the number of times the code must be retrieved from the mass storage devices during execution.

[0103] Input / output (I / O) devices (including but not limited to keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or through intermediary I / O controllers. Additionally, network adapters may be coupled to the system to enable the data processing system to be coupled to other data processing systems, remote printers, or storage devices through intermediary private or public networks. Modems, cable modems, and Ethernet cards are just a few of the types of network adapters currently available.

[0104] FIG. 8, with reference to FIGS. 3A-7, illustrates a representative hardware environment for implementing the embodiments herein. The schematic diagram illustrates a hardware configuration of a computing device 301 according to the embodiments herein. The computing device 301 includes at least one processor device 10. The special-purpose CPU 10 is interconnected to various devices, such as a random access memory (RAM) 14, a read-only memory (ROM) 16, and an input / output (I / O) adapter 18, via a system bus 12. The I / O adapter 18 allows connection to peripheral devices, such as a disk unit 11 and a tape drive 13, and other program storage devices readable by the system. The computing device 301 can read instructions of the present invention on the program storage device and execute the methodology of the embodiments herein according to the instructions. The computing device 301 further includes a user interface adapter 19 that connects other user interface devices, such as a keyboard 15, a mouse 17, a speaker 24, a microphone 22, and / or a touch screen device (not shown) to the bus 12 to collect input from a user. Further, a communications adapter 20 connects the bus 12 to a data processing network 25. A display adapter 21 connects the bus 12 to a display device 23. The display device presents a graphical user interface (GUI) 29 of output data according to embodiments herein. The display device may be embodied as an output device such as, for example, a monitor, a printer, or a transmitter. Further, a transceiver 26, a signal comparator 27, and a signal converter 28 may be connected to the bus 12 for processing, transmitting, receiving, comparing, and converting electrical or electronic signals.

[0105] The foregoing description of specific embodiments fully reveals the general nature of the embodiments herein, and by applying current knowledge, others may easily modify and / or adapt such specific embodiments to various applications without departing from the general concept. Therefore, such adaptations and modifications should and are intended to be understood within the meaning and range of equivalents of the disclosed embodiments. It should be understood that the expressions or terms used herein are for the purpose of description and not for the purpose of limitation. Thus, although the embodiments herein have been described with respect to preferred embodiments, those skilled in the art will recognize that the embodiments herein can be modified and practiced within the spirit and scope of the appended claims.

Claims

1. A virtual radio access network (vRAN) system (300) for provisioning a portable virtual radio access network (vRAN) among multiple RAN hardware platforms, comprising: a waveform development kit (302) for defining at least one portable radio access network (RAN) application to be instantiated on RAN hardware (326); (i) a waveform execution environment (304) configured to monitor schedulable resources in real time; and (ii) collect and monitor a plurality of statistics for network automation, The waveform execution environment (304) includes a RAN hypervisor (314) that virtualizes at least one attribute of spectrum resources required to provision a portable virtual radio access network (vRAN) on at least one hardware platform of the plurality of RAN hardware platforms in the RAN hardware (326) based on a description of at least one hardware computation resource in the RAN hardware (326); A virtual Radio Access Network (vRAN) system (300) that uses hyper-observability to enable dynamic reconfiguration of the RAN hardware (326) based on RF and signal conditions.

2. The waveform development kit (302) comprises: a defined Domain Specific Language (DSL) capturing at least one domain specific pattern for describing functionality related to said Radio Access Network (RAN); a compiler that converts platform independent (PI) signal processing algorithms written in the defined domain specific language (DSL) into bytecode or intermediate representation (IR) (310) for execution on RAN target hardware; 2. The virtual radio access network (vRAN) system (300) of claim 1, comprising:

3. The defined Domain Specific Language (DSL) comprises: (i) a stream processing function operating on at least one of an incoming stream of frames, packets, symbols, or samples, the stream processing function (i) taking an arbitrary stream type and converting said stream type to another stream type, or (ii) performing an operation on each element of the arbitrary stream type; (ii) a control processing function that issues a signal indicating a condition for processing the stream type; 2. The virtual radio access network (vRAN) system (300) of claim 1, wherein the signal is used by at least one of: (i) other control processing functions; or (ii) stream processing functions to perform another operation or change an execution path.

4. The RAN hypervisor (314) a RAN compute hypervisor (316) that provides a platform for a virtual machine (VM) on which the RAN modem instance (306) runs; 2. The virtual radio access network (vRAN) system (300) of claim 1, comprising: a RAN spectrum hypervisor (318) that virtualizes RF hardware (334) used to construct the radio units (106A-106B); and modem-independent RF attributes that are stored in an RF attribute database (336).

5. 2. The virtual radio access network (vRAN) system (300) of claim 1, wherein the RAN hypervisor (314) distributes and manages dynamic loads associated with a virtual radio access network (RAN) to processing elements (PEs) by scheduling multiple RAN modem instances and digital signal processing (DSP) flow graphs of the RAN on heterogeneous processing elements.

6. 2. The virtual radio access network (vRAN) system (300) of claim 1, comprising a RAN orchestrator (312) that creates, deletes, or modifies RAN modem instances of multiple wireless virtual machines (322A-322N) for RAN containers (332A-332N) running on the RAN hypervisor (314), wherein the RAN orchestrator (312) instantiates and coordinates various modem entities created on the RAN hypervisor (314) by interpreting scheduling information and runtime specifications (328A-328N) bundled with each RAN modem instance (306).

7. 2. The virtual radio access network (vRAN) system (300) of claim 1, comprising a modem store (308) which is a cache of intermediate representations of different waveforms or RAN modem instances (306) generated by the waveform development kit (302), the intermediate representations being combined with scheduling information and runtime specifications (328A-328N) derived from constraints in at least one domain-specific pattern specified in a defined domain-specific language (DSL) model for execution on target hardware, the intermediate representations being hosted on the modem store (308) together with the scheduling information and runtime specifications (328A-328N).

8. The virtual radio access network (vRAN) system (300) of claim 1, wherein a modem store (308) connects with a RAN orchestrator (312) to enable provisioning of modems and resources required to run the virtual radio access network (RAN).

9. 7. The virtual radio access network (vRAN) system (300) of claim 6, wherein each runtime specification (328A-328N) is a configuration database that describes various runtime and code generation specific aspects, said description enabling a RAN hypervisor (314) to properly map an intermediate representation (IR) of a RAN modem instance (306) to the RAN hardware (326).

10. 2. The virtual radio access network (vRAN) system (300) of claim 1, wherein the RAN hypervisor (314) manages use of computing elements on the RAN hardware (326), and security features provided by the RAN hardware (326) and policies provided in the RAN orchestrator (312) are used by the RAN hypervisor (314) to manage the at least one attribute associated with the computing elements.

11. 5. The virtual radio access network (vRAN) system (300) of claim 4, wherein the mapper (344) maps each RAN modem instance (306) to actual physical processing elements in the RAN hardware (326) by: (i) analyzing detailed descriptions of the computing, storage, and interconnect resource elements in each RAN hardware (326); (ii) correlating the detailed descriptions with a number of constraints provided by a runtime specification of each modem instance (306); and (iii) creating a mapping of the RAN modem instance (306) on the underlying processing elements of the RAN hardware (326), the detailed descriptions being provided by a hardware resource description (HRD) (324).

12. The multiple hierarchies of the hyper monitor function include: a hardware function block providing an interface function for monitoring selectable hardware signals and moving data at wire speed to said hypermonitor function for storage; a low level software function block that interacts with the RAN hardware (326) and sets control signals for monitoring functional groups, the low level software function block operating within a small inference engine to determine the control signals and providing filter signals to reduce unnecessary data transfers; and (b) a software function located within the RAN hypervisor (314) for storing and querying a database created by the hypermonitor function, the software block performing inference on stored data for use by an automation and radio interface controller (RIC).

13. 10. The virtual radio access network (vRAN) system (300) of claim 1, wherein the virtual radio access network (vRAN) system (300) performs radio frequency channel slicing and virtualization in at least one of the time domain, the frequency domain, or the spatial domain, thereby enabling implementation of the slicing concept in 5G and other communication modems.

14. 5. The virtual radio access network (vRAN) system (300) of claim 4, wherein the RAN spectrum hypervisor (318) uses an artificial intelligence (AI) prediction engine on the RF attribute database (336) to design RF attribute aware waveforms to leverage spectrum resources (338).

15. 1. A method for provisioning a portable virtual radio access network (vRAN) among multiple RAN hardware platforms, comprising: defining, via a waveform development kit (302), at least one portable radio access network (RAN) application to be instantiated on RAN hardware (326); monitoring resources schedulable by a waveform execution environment (304) in real time; collecting a plurality of statistics for network automation and monitoring the plurality of statistics by the waveform execution environment (304); virtualizing, by a RAN hypervisor (314), at least one attribute of spectrum resources required for provisioning a portable virtual radio access network (vRAN) on at least one of the plurality of RAN hardware platforms in the RAN hardware (326) based on a description of at least one hardware computation resource in the RAN hardware (326); using hyper-observability to enable dynamic reconfiguration of the RAN hardware (326) based on RF and signal conditions.

16. 16. The method of claim 15, further comprising: using the RAN hypervisor (314) to schedule multiple RAN modem instances (306) in a RAN flow graph such that RAN workload is dynamically shared among multiple processing elements (PEs).

17. 16. The method of claim 15, further comprising: auto-learning based on past decisions and inputs from a hypermonitor for utilization of spectral resources (338).

18. (i) analyzing detailed descriptions of the computing elements, storage elements, and interconnect resource elements within each RAN hardware (326); (ii) correlating said detailed description with a number of constraints provided in the run-time specification of each modem instance (306); (iii) mapping each RAN modem instance (306) to an actual physical processing element in the RAN hardware (326) by creating a mapping of the RAN modem instance (306) on an underlying processing element of the RAN hardware (326); The method of claim 15.

19. providing an interface function for monitoring selectable hardware signals and transferring data at wire speed to a hypermonitor function for storage; a small inference engine that interacts with the RAN hardware (326) and operates to determine the control signals for functional group monitoring, the control signals being provided with filter signals to reduce unnecessary data transfer; and performing queries on the database created by said hypermonitor function, where inferences are made on the stored data for use by an automation and radio interface controller (RIC). The method of claim 15.

Images