Message pass-through in the accelerator of the distributed unit

Abstract

Various aspects of the present disclosure generally relate to wireless communications. In some aspects, an open radio access network (O-RAN) distributed unit (O-DU) may generate a first message in an O-DU application running on the O-DU that does not utilize an O-DU accelerator of an O-DU that is inline with the O-DU application. The O-DU may transmit a first message from the O-DU application to an O-RAN radio unit (O-RU) via a pass-through of the O-DU accelerator, where the first message does not utilize the O-DU accelerator based at least in part on the payload of the first message being forwarded to the O-RU unaltered by the O-DU accelerator. Numerous other aspects are described.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application claims priority to U.S. Provisional Patent Application No. 63 / 261,507, filed September 22, 2021, entitled "PASSTHROUGH OF CONTROL PLANE MESSAGES IN AN ACCELERATOR OF A DISTRIBUTED UNIT," and U.S. Nonprovisional Patent Application No. 17 / 933,651, filed September 20, 2022, entitled "PASSTHROUGH OF MESSAGES IN AN ACCELERATOR OF A DISTRIBUTED UNIT," which are expressly incorporated herein by reference. [Background technology]

[0002] Aspects of the present disclosure relate generally to wireless communications and to techniques and apparatus for message pass-through in an accelerator of a distributed unit.

[0003] introduction Wireless communication systems have been widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may utilize multiple access technologies capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, etc.). Examples of such multiple access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, time division synchronous code division multiple access (TD-SCDMA) systems, and Long Term Evolution (LTE). LTE / LTE-Advanced is a set of extensions to the Universal Mobile Telecommunications System (UMTS) mobile standard promulgated by the Third Generation Partnership Project (3GPP®).

[0004] A wireless network may include one or more base stations that support communication for a user equipment (UE) or multiple UEs. A UE may communicate with a base station via downlink and uplink communications. "Downlink" (or "DL") refers to the communication link from a base station to a UE, and "uplink" (or "UL") refers to the communication link from the UE to the base station.

[0005] The above multiple access technologies have been adopted in various telecommunications standards to provide a common protocol that allows different UEs to communicate on a city, national, regional, and / or global scale. New Radio (NR), sometimes referred to as 5G, is a set of enhancements to the LTE mobile standard promulgated by 3GPP. NR is designed to better support mobile broadband Internet access by improving spectral efficiency, lowering costs, improving services, taking advantage of new spectrum, and using orthogonal frequency division multiplexing (OFDM) with cyclic prefix (CP) (CP-OFDM) on the downlink and CP-OFDM and / or single-carrier frequency division multiplexing (SC-FDM) (also known as discrete Fourier transform spread OFDM (DFT-s-OFDM)) on the uplink, as well as better integration with other open standards supporting beamforming, multiple-input multiple-output (MIMO) antenna technology, and carrier aggregation. As the demand for mobile broadband access continues to grow, further improvements in LTE, NR, and other radio access technologies remain useful. Summary of the Invention

[0006] In some implementations, an apparatus for wireless communication in an open radio access network (O-RAN) distributed unit (O-DU) includes a memory and one or more processors coupled to the memory, where the one or more processors are configured to generate, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of an O-DU that is inline with the O-DU application, and transmit the first message from the O-DU application to an O-RAN radio unit (O-RU) via a pass-through of the O-DU accelerator, where the first message does not utilize the O-DU accelerator based at least in part on a payload of the first message being forwarded to the O-RU without being modified by the O-DU accelerator.

[0007] In some implementations, a method of wireless communication performed by an O-DU includes generating, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of an O-DU that is inline with the O-DU application, and transmitting the first message from the O-DU application to an O-RU via a pass-through of the O-DU accelerator, wherein the first message does not utilize the O-DU accelerator based at least in part on a payload of the first message being forwarded to the O-RU without modification by the O-DU accelerator.

[0008] In some implementations, a non-transitory computer-readable medium storing a set of instructions for wireless communication includes one or more instructions that, when executed by one or more processors of an O-DU, cause the O-DU to generate, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of the O-DU that is inline with the O-DU application, and send the first message from the O-DU application to an O-RU via a pass-through of the O-DU accelerator, based at least in part on a payload of the first message being forwarded to the O-RU without modification by the O-DU accelerator.

[0009] In some implementations, an apparatus for wireless communication includes means for generating, in an application executing on the apparatus, a first message that does not utilize an accelerator of the apparatus that is inline with the application, and means for transmitting the first message from the application to an O-RU via a pass-through of the accelerator, the first message not utilizing the accelerator based at least in part on a payload of the first message being forwarded to the O-RU unaltered by the accelerator.

[0010] Aspects generally include methods, apparatus, systems, computer program products, non-transitory computer readable media, user equipment, base stations, network nodes, wireless communication devices, and / or processing systems as fully described herein with reference to and as illustrated in the drawings and this specification.

[0011] The foregoing has outlined rather broadly the features and technical advantages of embodiments according to the present disclosure in order that the following Detailed Description may be better understood. Additional features and advantages will be described hereinafter. The concepts and examples disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Such equivalent structures do not depart from the scope of the appended claims. The nature of the concepts disclosed herein, both their organization and method of operation, together with associated advantages, will be better understood from the following description when considered in conjunction with the accompanying figures. Each of the figures is provided for the purpose of illustration and explanation, and not as a definition of the limits of the claims.

[0012] Although aspects are described in this disclosure by illustrating some examples, those skilled in the art will appreciate that such aspects can be implemented in many different configurations and scenarios. The techniques described herein can be implemented using different platform types, devices, systems, shapes, sizes, and / or packaging configurations. For example, some aspects can be implemented via integrated chip embodiments or other non-modular component-based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, and / or artificial intelligence-enabled devices). Aspects can be implemented in chip-level components, modular components, non-modular components, non-chip-level components, device-level components, and / or system-level components. Devices incorporating the described aspects and features can include additional components and features for the implementation and practice of the claimed and described aspects. For example, the transmission and reception of wireless signals may include one or more components for analog and digital applications (e.g., hardware components including antennas, radio frequency (RF) chains, power amplifiers, modulators, buffers, processors, interleavers, adders, and / or summers). It is contemplated that aspects described herein may be practiced in a wide variety of devices, components, systems, distributed configurations, and / or end-user devices of various sizes, shapes, and configurations.

[0013] So that the above-listed features of the present disclosure can be understood in detail, a more detailed description, briefly summarized above, may be had by referring to embodiments, some of which are shown in the attached drawings. However, it should be noted that the attached drawings show only some typical embodiments of the present disclosure, and therefore should not be considered as limiting its scope, since the present description may admit of other equally effective embodiments. The same reference numbers in different drawings may identify the same or similar elements. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 illustrates an example of a wireless network in accordance with the present disclosure. [Diagram 2] FIG. 1 illustrates an example of a base station in communication with a user equipment (UE) in a wireless network in accordance with the present disclosure. [Diagram 3] FIG. 1 illustrates an example of an open radio access network (O-RAN) architecture in accordance with the present disclosure. [Figure 4] FIG. 1 illustrates an example of an open radio access network (O-RAN) architecture in accordance with the present disclosure. [Diagram 5] FIG. 1 illustrates an embodiment associated with accelerator pass-through for control plane messages in an O-RAN distributed unit (DU) (O-DU) according to the present disclosure. [Figure 6] FIG. 1 illustrates an embodiment associated with accelerator pass-through for control plane messages in an O-RAN distributed unit (DU) (O-DU) according to the present disclosure. [Figure 7] FIG. 1 illustrates an embodiment associated with accelerator pass-through for control plane messages and user plane messages in an O-DU according to the present disclosure. [Figure 8] FIG. 1 illustrates an example associated management plane architecture in an O-DU according to the present disclosure. [Figure 9] FIG. 2 illustrates an example process associated with passing through a message in an accelerator of a distributed unit in accordance with the present disclosure. [Figure 10] FIG. 1 is a diagram of an example apparatus for wireless communication in accordance with the present disclosure. [Figure 11] FIG. 1 illustrates an example of a non-aggregated base station architecture in accordance with the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Various aspects of the present disclosure are described more fully below with reference to the accompanying drawings. However, the present disclosure may be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout the present disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Those skilled in the art should understand that the scope of the present disclosure is intended to encompass any aspect of the present disclosure disclosed herein, whether implemented independently of or in combination with any other aspect of the present disclosure. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects described herein. In addition, the scope of the present disclosure is intended to encompass such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the present disclosure described herein. It should be understood that any aspect of the present disclosure disclosed herein may be embodied by one or more elements of a claim.

[0016] Several aspects of a telecommunications system are now presented with reference to various apparatus and techniques, which are described in the detailed description that follows and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as "elements"). These elements may be implemented using hardware, software, or a combination thereof. Whether such elements are implemented as hardware or software depends on the particular application and design constraints imposed on the overall system.

[0017] Although aspects may be described herein using terminology commonly associated with 5G or New Radio (NR) radio access technology (RAT), aspects of the disclosure may be applicable to other RATs, such as 3G RATs, 4G RATs, and / or post-5G (e.g., 6G) RATs.

[0018] 1 illustrates an example of a wireless network 100 in accordance with the present disclosure. Wireless network 100 may be or include elements of a 5G (e.g., NR) network and / or a 4G (e.g., Long Term Evolution (LTE)) network, among other examples. Wireless network 100 may include one or more base stations 110 (shown as BS 110a, BS 110b, BS 110c, and BS 110d), user equipment (UE) 120 or multiple UEs 120 (shown as UE 120a, UE 120b, UE 120c, UE 120d, and UE 120e), and / or other network entities. Base station 110 is an entity that communicates with UE 120. The base stations 110 (sometimes referred to as BSs) may include, for example, NR base stations, LTE base stations, Node Bs, eNBs (e.g., in 4G), gNBs (e.g., in 5G), access points, and / or transmission reception points (TRPs). Each base station 110 may provide communication coverage for a particular geographic area. In the Third Generation Partnership Project (3GPP), the term "cell" can refer to the coverage area of ​​a base station 110 and / or a base station subsystem serving that coverage area, depending on the context in which the term is used.

[0019] A base station 110 may provide communication coverage for a macro cell, a pico cell, a femto cell, and / or another type of cell. A macro cell may cover a relatively large geographic area (e.g., a radius of several kilometers) and may allow unrestricted access by UEs 120 with a service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by UEs 120 with a service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access by UEs 120 with an association with the femto cell (e.g., UEs 120 in a closed subscriber group (CSG)). A base station 110 for a macro cell may be referred to as a macro base station. A base station 110 for a pico cell may be referred to as a pico base station. A base station 110 for a femto cell may be referred to as a femto base station or an in-home base station. 1, BS 110a may be a macro base station for a macro cell 102a, BS 110b may be a pico base station for a pico cell 102b, and BS 110c may be a femto base station for a femto cell 102c. A base station may support one or more (e.g., three) cells.

[0020] In some aspects, the term "base station" (e.g., base station 110) or "network entity" may refer to an aggregated base station, a non-aggregated base station, an integrated access and backhaul (IAB) node, a relay node, and / or one or more components thereof. For example, in some aspects, a "base station" or a "network entity" may refer to a central unit (CU), a distributed unit (DU), a radio unit (RU), a near-real time (Near-RT) RAN intelligent controller (RIC), or a non-real time (Non-RT) RIC, or a combination thereof. In some aspects, the term "base station" or a "network entity" may refer to one device configured to perform one or more functions, such as the functions described herein with respect to base station 110. In some aspects, the term "base station" or a "network entity" may refer to multiple devices configured to perform one or more functions. For example, in some distributed systems, several different devices (which may be located at the same geographic location or different geographic locations) may each be configured to perform at least a portion of the functions or to replicate the performance of at least a portion of the functions, and the term "base station" or "network entity" may refer to any one or more of those different devices. In some aspects, the term "base station" or "network entity" may refer to one or more virtual base stations and / or one or more virtual base station functions. For example, in some aspects, two or more base station functions may be instantiated on a single device. In some aspects, the term "base station" or "network entity" may refer to one of the base station functions and not another base station function. In this manner, a single device may include two or more base stations.

[0021] In some embodiments, the cells may not necessarily be stationary and the geographic area of ​​the cells may move according to the location of the base station 110 that is mobile (e.g., a mobile base station). In some embodiments, the base stations 110 may be interconnected to each other and / or to one or more other base stations 110 or network nodes (not shown) in the wireless network 100 through various types of backhaul interfaces, such as direct physical connections or virtual networks, using any suitable transport network.

[0022] The wireless network 100 may include one or more relay stations. A relay station is an entity that can receive a transmission of data from an upstream station (e.g., a base station 110 or a UE 120) and send a transmission of data to a downstream station (e.g., a UE 120 or a base station 110). A relay station may be a UE 120 that can relay a transmission for another UE 120. In the embodiment shown in FIG. 1, a BS 110d (e.g., a relay base station) may communicate with a BS 110a (e.g., a macro base station) and a UE 120d to facilitate communication between the BS 110a (e.g., a macro base station) and the UE 120d. A base station 110 that relays communication may be referred to as a relay station, a relay base station, a relay, etc.

[0023] The wireless network 100 may be a heterogeneous network including different types of base stations 110, such as macro base stations, pico base stations, femto base stations, relay base stations, etc. These different types of base stations 110 may have different transmit power levels, different coverage areas, and / or different susceptibility to interference in the wireless network 100. For example, a macro base station may have a high transmit power level (e.g., 5-40 watts), while the pico base stations, femto base stations, and relay base stations may have lower transmit power levels (e.g., 0.1-2 watts).

[0024] A network controller 130 may couple to or communicate with a set of base stations 110 and may provide coordination and control for these base stations 110. The network controller 130 may communicate with the base stations 110 via backhaul communication links. The base stations 110 may communicate with each other directly or indirectly via wireless or wired backhaul communication links.

[0025] The UEs 120 may be dispersed throughout the wireless network 100, and each UE 120 may be fixed or mobile. The UEs 120 may include, for example, an access terminal, a terminal, a mobile station, and / or a subscriber unit. The UEs 120 may be a cellular telephone (e.g., a smartphone), a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet, a camera, a gaming device, a netbook, a smartbook, an ultrabook, a medical device, a biometric device, a wearable device (e.g., a smart watch, smart clothing, smart glasses, a smart wristband, smart jewelry (e.g., a smart ring or a smart bracelet)), an entertainment device (e.g., a music device, a video device, and / or a satellite radio), a vehicle component or sensor, a smart meter / sensor, industrial manufacturing equipment, a global positioning system device, and / or any other suitable device configured to communicate over a wireless medium.

[0026] Some UEs 120 may be considered as machine-type communication (MTC) UEs or evolved or enhanced machine-type communication (eMTC) UEs. MTC UEs and / or eMTC UEs may include, for example, a robot, a drone, a remote device, a sensor, a meter, a monitor, and / or a location tag that may communicate with a base station, another device (e.g., a remote device), or some other entity. Some UEs 120 may be considered as Internet-of-Things (IoT) devices and / or may be implemented as NB-IoT (narrowband IoT) devices. Some UEs 120 may be considered as customer premises equipment. The UE 120 may be included within a housing that houses components of the UE 120, such as a processor component and / or a memory component. In some embodiments, the processor component and the memory component may be coupled to each other. For example, a processor component (e.g., one or more processors) and a memory component (e.g., memory) may be operatively coupled, communicatively coupled, electronically coupled, and / or electrically coupled.

[0027] In general, any number of wireless networks 100 may be deployed in a given geographic area. Each wireless network 100 may support a particular RAT and may operate on one or more frequencies. The RAT may be referred to as a radio technology, an air interface, etc. The frequencies may be referred to as a carrier, a frequency channel, etc. Each frequency may support a single RAT in a given geographic area to avoid interference between wireless networks of different RATs. In some cases, NR networks or 5G RAT networks may be deployed.

[0028] In some embodiments, two or more UEs 120 (e.g., shown as UE 120a and UE 120e) may communicate directly (e.g., without using base station 110 as an intermediary to communicate with each other) using one or more sidelink channels. For example, UEs 120 may communicate using peer-to-peer (P2P) communications, device-to-device (D2D) communications, vehicle-to-everything (V2X) protocols (which may include, e.g., vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or vehicle-to-pedestrian (V2P) protocols), and / or mesh networks. In such embodiments, UEs 120 may perform scheduling operations, resource selection operations, and / or other operations described elsewhere herein as being performed by base station 110.

[0029] The devices of the wireless network 100 may communicate using an electromagnetic spectrum that may be subdivided by frequency or wavelength into various classes, bands, channels, etc. For example, the devices of the wireless network 100 may communicate using one or more operating bands. In 5G NR, two initial operating bands have been identified with frequency range designations FR1 (410 MHz-7.125 GHz) and FR2 (24.25 GHz-52.6 GHz). It should be understood that FR1 is often referred to (interchangeably) as the "sub-6 GHz" band in various documents and papers, although a portion of FR1 is higher than 6 GHz. Similar nomenclature issues may arise with respect to FR2, which is often referred to (interchangeably) as the "millimeter wave" band in documents and papers, even though it is different from the extremely high frequency (EHF) band (30 GHz-300 GHz) identified as the "millimeter wave" band by the International Telecommunications Union (ITU).

[0030] Frequencies between FR1 and FR2 are often referred to as mid-band frequencies. Recent 5G NR studies have identified operating bands for these mid-band frequencies as frequency range designation FR3 (7.125 GHz to 24.25 GHz). Frequency bands that fall within FR3 may inherit FR1 and / or FR2 characteristics, and thus may in effect extend the features of FR1 and / or FR2 to the mid-band frequencies. Additionally, higher frequency bands are currently being explored to extend 5G NR operation beyond 52.6 GHz. For example, three higher operating bands have been identified as frequency range designations FR4a or FR4-1 (52.6 GHz to 71 GHz), FR4 (52.6 GHz to 114.25 GHz), and FR5 (114.25 GHz to 300 GHz). Each of these higher frequency bands falls within the EHF band.

[0031] With the above examples in mind, it should be understood that unless otherwise specified, terms such as "sub-6 GHz" as used herein may broadly refer to frequencies that may be below 6 GHz, may be within FR1, or may include mid-band frequencies. Additionally, unless otherwise specified, it should be understood that terms such as "millimeter wave" as used herein may broadly refer to frequencies that may be within FR2, FR4, FR4-a or FR4-1, and / or FR5, which may include mid-band frequencies, or may be within the EHF band. It is contemplated that the frequencies included in these operating bands (e.g., FR1, FR2, FR3, FR4, FR4-a, FR4-1, and / or FR5) may be modified, and the techniques described herein are applicable to those modified frequency ranges.

[0032] In some aspects, an open radio access network (O-RAN) distributed unit (DU) (O-DU) (e.g., base station 110) may include a communications manager 150. As described in more detail elsewhere herein, the communications manager 150 is capable of generating, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of an O-DU that is inline with the O-DU application, and transmitting the first message from the O-DU application to an O-RAN radio unit (O-RU) via a pass-through of the O-DU accelerator, the first message not utilizing the O-DU accelerator based at least in part on the payload of the first message being forwarded to the O-RU unaltered by the O-DU accelerator. Additionally or alternatively, the communications manager 150 may perform one or more other operations described herein.

[0033] As noted above, Figure 1 is provided as an example. Other examples may differ from that described with respect to Figure 1.

[0034] 2 illustrates an embodiment 200 of a base station 110 in communication with a UE 120 in a wireless network 100 in accordance with the present disclosure. The base station 110 may be equipped with a set of antennas 234a through 234t, such as T antennas, where T≧1. The UE 120 may be equipped with a set of antennas 252a through 252r, such as R antennas, where R≧1.

[0035] At the base station 110, a transmit processor 220 may receive data destined for a UE 120 (or set of UEs 120) from a data source 212. The transmit processor 220 may select one or more modulation and coding schemes (MCS) for the UE 120 based at least in part on one or more channel quality indicators (CQI) received from the UE 120. The base station 110 may process (e.g., encode and modulate) data for the UE 120 based at least in part on the MCS(es) selected for the UE 120 and provide data symbols to the UE 120. The transmit processor 220 may process system information (e.g., for semi-static resource partitioning information (SRPI)) and control information (e.g., CQI requests, grants, and / or higher layer signaling) and provide overhead symbols and control symbols. The transmit processor 220 may generate reference symbols for a reference signal (e.g., a cell-specific reference signal (CRS) or a demodulation reference signal (DMRS)) and a synchronization signal (e.g., a primary synchronization signal (PSS) or a secondary synchronization signal (SSS)). A transmit (TX) multiple-input multiple-output (MIMO) processor 230 may perform spatial processing (e.g., precoding) on ​​the data symbols, control symbols, overhead symbols, and / or reference symbols, if applicable, and may provide a set of output symbol streams (e.g., T output symbol streams) to a corresponding set of modems 232 (e.g., T modems), denoted as modems 232a through 232t. For example, each output symbol stream may be provided to a modulator component (denoted as MOD) of modem 232.Each modem 232 may process a respective output symbol stream using a respective modulator component (e.g., for OFDM) to obtain an output sample stream. Each modem 232 may further process (e.g., convert to analog, amplify, filter, and / or upconvert) the output sample stream using a respective modulator component to obtain a downlink signal. Modems 232a through 232t may transmit a set of downlink signals (e.g., T downlink signals) via a corresponding set of antennas 234 (e.g., T antennas), which are denoted as antennas 234a through 234t.

[0036] At the UE 120, a set of antennas 252 (depicted as antennas 252a through 252r) may receive downlink signals from the base station 110 and / or other base stations 110 and may provide a set of received signals (e.g., R received signals) to a set of modems 254 (e.g., R modems) depicted as modems 254a through 254r. For example, each received signal may be provided to a demodulator component (depicted as DEMOD) of the modems 254. Each modem 254 may condition (e.g., filter, amplify, downconvert, and / or digitize) the received signal using a respective demodulator component to obtain input samples. Each modem 254 may further process the input samples (e.g., for OFDM) using the demodulator component to obtain received symbols. A MIMO detector 256 may obtain received symbols from the modems 254, perform MIMO detection on the received symbols, if applicable, and provide detected symbols. The receive processor 258 may process (e.g., demodulate and decode) the detected symbols, provide decoded data for the UE 120 to a data sink 260, and provide decoded control and system information to a controller / processor 280. The term "controller / processor" may refer to one or more controllers, one or more processors, or a combination thereof. The channel processor may determine a reference signal received power (RSRP) parameter, a received signal strength indicator (RSSI) parameter, a reference signal received quality (RSRQ) parameter, and / or a CQI parameter, among other examples. In some embodiments, one or more components of the UE 120 may be included within a housing 284.

[0037] The network controller 130 may include a communication unit 294, a controller / processor 290, and a memory 292. The network controller 130 may include, for example, one or more devices in a core network. The network controller 130 may communicate with the base stations 110 via the communication unit 294.

[0038] One or more antennas (e.g., antennas 234a-t and / or antennas 252a-r) may include or be contained within one or more antenna panels, one or more antenna groups, one or more sets of antenna elements, and / or one or more antenna arrays, among other examples. An antenna panel, antenna group, set of antenna elements, and / or antenna array may include one or more antenna elements (in a single housing or multiple housings), a set of coplanar antenna elements, a set of non-coplanar antenna elements, and / or one or more antenna elements coupled to one or more transmitting and / or receiving components, such as one or more components of FIG.

[0039] On the uplink, at the UE 120, the transmit processor 264 may receive and process data from the data source 262 and control information (e.g., for reports including RSRP, RSSI, RSRQ, and / or CQI) from the controller / processor 280. The transmit processor 264 may generate reference symbols for one or more reference signals. The symbols from the transmit processor 264 may be precoded by the TX MIMO processor 266, if applicable, further processed by the modem 254 (e.g., for DFT-s-OFDM or CP-OFDM), and transmitted to the base station 110. In some embodiments, the modem 254 of the UE 120 may include a modulator and demodulator. In some embodiments, the UE 120 includes a transceiver. The transceiver may include any combination of the antenna(s) 252, the modem(s) 254, the MIMO detector 256, the receive processor 258, the transmit processor 264, and / or the TX MIMO processor 266. The transceiver can be used by a processor (e.g., controller / processor 280) and memory 282 to perform aspects of any of the methods described herein (e.g., with reference to Figures 5-10).

[0040] At the base station 110, uplink signals from the UE 120 and / or other UEs may be received by an antenna 234, processed by a modem 232 (e.g., a demodulator component of the modem 232, denoted as DEMOD), detected by a MIMO detector 236, if applicable, and further processed by a receive processor 238 to obtain decoded data and control information sent by the UE 120. The receive processor 238 may provide the decoded data to a data sink 239 and the decoded control information to a controller / processor 240. The base station 110 may include a communication unit 244 and may communicate with the network controller 130 via the communication unit 244. The base station 110 may include a scheduler 246 to schedule one or more UEs 120 for downlink and / or uplink communications. In some embodiments, the modem 232 of the base station 110 may include a modulator and a demodulator. In some embodiments, the base station 110 includes a transceiver. The transceiver may include any combination of antenna(s) 234, modem(s) 232, MIMO detector 236, receive processor 238, transmit processor 220, and / or TX MIMO processor 230. The transceiver may be used by a processor (e.g., controller / processor 240) and memory 242 to perform aspects of any of the methods described herein (e.g., with reference to FIGS. 5-10).

[0041] The controller / processor 240 of the base station 110, the controller / processor 280 of the UE 120, and / or any other component(s) of FIG. 2 may perform one or more techniques associated with passing through messages in the accelerator of the distributed unit, as described in more detail elsewhere herein. In some aspects, the O-DU described herein is the base station 110, is included within the base station 110, or includes one or more components of the base station 110 shown in FIG. 2. For example, the controller / processor 240 of the base station 110, the controller / processor 280 of the UE 120, and / or any other component(s) of FIG. 2 may perform or direct operations of, for example, process 900 of FIG. 9 and / or other processes as described herein. The memory 242 and the memory 282 may store data and program codes for the base station 110 and the UE 120, respectively. In some embodiments, memory 242 and / or memory 282 may include a non-transitory computer-readable medium that stores one or more instructions (e.g., code and / or program code) for wireless communication. For example, the one or more instructions, when executed by one or more processors of base station 110 and / or UE 120 (e.g., directly or after compiling, translating, and / or interpreting), may cause the one or more processors, UE 120, and / or base station 110 to perform or direct operations of, for example, process 900 of FIG. 9 and / or other processes described herein. In some embodiments, executing instructions may include executing instructions, translating instructions, compiling instructions, and / or interpreting instructions, among other examples.

[0042] In some aspects, the O-DU (e.g., base station 110) includes means for generating, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of the O-DU that is inline with the O-DU application, and / or means for transmitting the first message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator, the first message not utilizing the O-DU accelerator based at least in part on the payload of the first message being forwarded to the O-RU unaltered by the O-DU accelerator. In some aspects, the means for the O-DU to perform the operations described herein may include, for example, one or more of the communications manager 150, the transmit processor 220, the TX MIMO processor 230, the modem 232, the antenna 234, the MIMO detector 236, the receive processor 238, the controller / processor 240, the memory 242, or the scheduler 246.

[0043] 2 are shown as separate components, the functionality described above with respect to the blocks may be implemented in a single hardware, software, or combination component, or in various combinations of components. For example, functionality described with respect to transmit processor 264, receive processor 258, and / or TX MIMO processor 266 may be performed by or under the control of controller / processor 280.

[0044] As noted above, Figure 2 is provided as an example. Other examples may differ from that described with respect to Figure 2.

[0045] FIG. 3 is a diagram illustrating an embodiment of an O-RAN architecture 300 in accordance with the present disclosure.

[0046] As shown in Figure 3, the O-RAN architecture may include a control unit (CU) 310 that communicates with a core network 320 via a backhaul link. Furthermore, the CU 310 may communicate with one or more DUs 330 via respective midhaul links. Each of the DUs 330 may communicate with one or more RUs 340 via respective fronthaul links, and each of the RUs 340 may communicate with a respective UE 120 via an RF access link. The DUs 330 and RUs 340 may also be referred to as O-DUs 330 and O-RUs 340, respectively.

[0047] In some aspects, the DU 330 and the RU 340 may be implemented according to a functional split architecture in which the functionality of the base station 110 (e.g., eNB or gNB) is provided by the DU 330 and one or more RUs 340 communicating via a fronthaul link. Thus, as described herein, the base station 110 may include the DU 330 and one or more RUs 340, which may be co-located or geographically distributed. In some aspects, the DU 330 and associated RU(s) 340 may communicate via the fronthaul link to exchange real-time control plane information via a Lower Layer Split (LLS) Control Plane (LLS-C) interface, to exchange non-real-time management information via a LLS Management Plane (LLS-M) interface, and / or to exchange user plane information via a LLS User Plane (LLS-U) interface.

[0048] Thus, the DU 330 may correspond to a logical unit including one or more base station functions for controlling the operation of one or more RUs 340. For example, in some aspects, the DU 330 may host a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more upper physical (PHY) layers (e.g., forward error correction (FEC) encoding and decoding, scrambling, and / or modulation and demodulation), based at least in part on the lower layer functional division. Upper layer control functions such as a packet data convergence protocol (PDCP), a radio resource control (RRC), and / or a service data adaptation protocol (SDAP) may be hosted by the CU 310. The RU(s) 340 controlled by the DU 330 may correspond to a logical node hosting an RF processing function, and a lower PHY layer function (e.g., a fast Fourier transform (FFT), an inverse FFT (iFFT), digital beamforming, and / or a physical random access channel (PRACH) extraction and filtering), based at least in part on the lower layer functional division. Thus, in an O-RAN architecture, the RU(s) 340 handle all over-the-air (OTA) communications with the UE 120, and real-time and non-real-time aspects of the control and user plane communications with the RU(s) 340 are controlled by the corresponding DU 330, which enables the DU(s) 330 and CU 310 to be implemented in a cloud-based RAN architecture.

[0049] As noted above, Figure 3 is provided as an example. Other examples may differ from that described with respect to Figure 3.

[0050] FIG. 4 is a diagram illustrating an embodiment of an O-RAN architecture 400 in accordance with the present disclosure.

[0051] In an O-RAN architecture, an Access and Mobility Management Function (AMF) or User Plane Function (UPF) may be connected to one or more base stations (e.g., gNBs) via a Next Generation (NG) interface. The base stations may be connected to each other via an Xn interface. A base station may include a CU that may be connected to one or more DUs of the base station via an F1 interface.

[0052] The DU may include Layer 2 (L2) and Layer 3 (L3), which may be associated with a control layer, an RRC layer, a PDCP layer, an RLC layer, and a MAC layer. L2 / 3 may communicate with Layer 1 (L1) via a Functional Application Platform Interface (FAPI). The FAPI may enable per-slot operation. The FAPI may be stateless and may enable over-the-air transmission and reception. L1 may be associated with a PHY layer and a Front End Unit (FEU). The PHY layer may be associated with a baseband, which may include digital beamforming. The baseband may communicate with the FAPI via a P5 interface, which may be associated with PHY control, and via a P7 interface, which may be associated with PHY data. The FEU may be associated with a Digital Front End (DFE), an Analog-to-Digital Converter (ADC) and a Digital-to-Analog Converter (DAC), and an RF, which may be associated with analog beamforming. The DFE and RF may communicate with the FAPI via a P19 interface, which may be associated with FEU control.

[0053] As noted above, Figure 4 is provided as an example. Other examples may differ from that described with respect to Figure 4.

[0054] The O-RAN Fronthaul (FH) (OFH) may provide a stateless interface operating at symbol resolution between the high PHY layer associated with the O-DU and the low PHY layer associated with the O-RU. The O-RAN FH may be associated with a control plane (C-plane). The control plane may provide scheduling and beamforming commands, multiple numerologies, channel estimation to the O-RU, unlicensed access support, section extensions for updating beam weights, and / or non-contiguous resource block patterns. The O-RAN FH may be associated with a user plane (U-plane). The user plane may provide transport of samples scheduled on the control plane (or semi-statically configured on the management plane (M-plane)) and / or support for compression. The O-RAN FH may be associated with a synchronization plane, which may provide profiles of protocols and mechanisms for ensuring timely delivery of the control plane and the user plane.

[0055] The FAPI may be an interface between L2 / 3 and L1 in the O-DU, and the O-RAN FH may provide connectivity between the O-DU and the O-RU. The FAPI may be independent of the O-RAN FH.

[0056] The O-DU may employ accelerators (e.g., hardware accelerators and associated libraries / drivers) to improve the performance of the O-DU. The accelerators may be implemented by using the FAPI to support interactions in the O-DU. Because the FAPI has limited awareness of the O-RAN FH (which may provide connectivity between the O-DU and the O-RU), the accelerators may need to generate O-RAN FH messages for both the control plane and the user plane. However, the accelerators may be primarily beneficial for the user plane for generation and decoding of in-phase and quadrature (I / Q) signals, or for control plane generation of beamforming weights, and a particular O-DU implementation may not require the assistance of the accelerator to generate other control plane messages or fields. The accelerators may use high-performance hardware that is not well suited for complex data structures, but may be well suited for processing FH user plane messages (e.g., I / Q samples to and from the O-RU) or beam weights (e.g., complex-valued samples to and from the O-RU). As a result, generating or receiving O-RAN FH messages for every control plane and user plane message may not be worthwhile compared to focusing an accelerator on the hardware-intensive message generation or reception in the O-DU.

[0057] In various aspects of the techniques and apparatus described herein, the O-DU may generate (or receive) control plane messages in an O-DU application running on the O-DU. The O-DU may transmit control plane messages between the O-DU application and the O-RU via a pass-through of the accelerator of the O-DU, which is inline with the O-DU application. The O-DU accelerator of the O-DU may be inline between the O-DU application and the O-RU. The control plane messages may pass through the accelerator of the O-DU and may not be subject to hardware acceleration in the accelerator beyond possible transposition between the application message payload and the transport medium. Such transposition may involve compression or decompression of I / Q samples or beamform weights, or addition or removal of transport adaptation. In other words, in the case of pass-through, the message payload may be generated or interpreted entirely in the O-DU application, and the accelerator may be involved only in the compression / decompression transposition at most.

[0058] Furthermore, a control plane message may be the first message, and the O-DU may generate (or receive) a second control or user plane message (second message) at the accelerator based at least in part on the FAPI exchange between the accelerator and the O-DU application. The second message may be generated via hardware acceleration at the accelerator. The O-DU may transmit the second message to the O-RU via the accelerator. As a result, some messages generated at the O-DU (e.g., control plane messages such as the first message) may pass through the accelerator, and other messages (e.g., control plane messages and user plane messages such as the second message generated at the O-DU) may be directed to the accelerator for hardware acceleration, thereby potentially improving the performance of the accelerator.

[0059] In some aspects, some control plane messages may not terminate at the accelerator in the O-DU, which may result in improved control plane transparency of the accelerator. Some control plane messages may be generated or received at the O-DU application, and these control plane messages may pass through the accelerator and be exchanged with the O-RU. The pass-through of some control plane messages may minimize bookkeeping at the accelerator and minimize the amount of non-value-added transformations at the accelerator, thereby improving the performance of the accelerator. The pass-through of certain control plane messages at the accelerator may make additional cycles available at the accelerator for higher value functions. Furthermore, the management plane may terminate primarily at the O-DU application, rather than at the accelerator. As a result, the FAPI exchange may be used to extract exactly as much value from the accelerator as is needed by the O-DU application.

[0060] FIG. 5 is a diagram illustrating an embodiment 500 associated with accelerator pass-through for at least some control plane messages in an O-DU in accordance with the present disclosure.

[0061] In some aspects, the O-DU may generate (or expect) a control plane message in an O-DU application running on the O-DU. The O-DU may send (or receive) a control plane message between the O-DU application and the O-RU via a pass-through of an accelerator (or O-DU accelerator) in the O-DU that is inline with the O-DU application running on the O-DU. The O-DU accelerator in the O-DU may be inline between the O-DU application and the O-RU. The control plane message may pass through the accelerator in the O-DU and may not be subject to hardware acceleration in the accelerator in the O-DU. In some aspects, the accelerator may support multiple channels and the control plane message may be associated with a channel included in the multiple channels.

[0062] In some aspects, a control plane message may be the first message. The O-DU may generate a second message (control or user plane message) at the accelerator of the O-DU based at least in part on a functional application platform interface between the accelerator of the O-DU and an O-DU application running on the O-DU. The second message may be generated via hardware acceleration at the accelerator of the O-DU. The O-DU may send (or expect) the second message to the O-RU at the accelerator of the O-DU.

[0063] In some aspects, a control plane message partially or completely generated in an O-DU application running on the O-DU may be associated with (or adjusted by) at least one message payload generated in the accelerator of the O-DU in terms of data frames, beam indices and weights (e.g., implicit weights or dynamic weights), and / or time and frequency mapping to spatial streams. An implicit weight refers to a weight that may be calculated or known in the O-RU without explicit signaling in the considered message payload itself (e.g., due to prior semi-static configuration or dynamic signaling, or common knowledge of channel and precoder selection between the O-DU and O-RU).

[0064] In some aspects, the first control plane message may be associated with an implicit beam weight that may indicate that the first control plane message is to pass through the accelerator of the O-DU. The implicit beam weight may be known or assumed in an O-DU application running on the O-DU. The second message (control plane or user plane message) may be associated with a dynamic beam weight that may indicate that the second message is not to pass transparently through the accelerator of the O-DU, and the dynamic beam weight may be generated in the accelerator of the O-DU.

[0065] In some aspects, the O-DU may initiate signaling between an O-DU application running on the O-DU and the accelerator of the O-DU to negotiate the types of messages that pass through the accelerator of the O-DU and the types of messages that do not pass through the accelerator of the O-DU. In some cases, the type of message may be indicated by a scope (e.g., user plane, control plane, or dynamic beamforming), a controlled Uu direction (e.g., uplink or downlink), a fronthaul direction (e.g., upstream or downstream), a channelization (e.g., physical downlink shared channel (PDSCH) or physical uplink shared channel (PUSCH)), or an individual message identification (e.g., by section, slot, symbol, resource block (RB) or time, or other message identification or combination method). In some aspects, the O-DU may initiate signaling between an O-DU application running on the O-DU and an accelerator of the O-DU to negotiate parameters associated with fragmentation and compression to be performed by the O-DU application running on the O-DU or the accelerator of the O-DU. In some aspects, the O-DU may initiate management plane signaling in a management plane entity associated with the O-DU application running on the O-DU with a management plane entity associated with the O-RU, and the management plane signaling may be associated with O-RU initialization, discovery, or orchestration. In other aspects, the management plane entity may be associated with O-DU initialization, discovery, or orchestration.

[0066] In some aspects, the O-DU may generate (or expect to receive) section and header information in an O-DU application executing on the O-DU for a message passing through the accelerator of the O-DU without being subject to hardware acceleration. Alternatively, the O-DU may generate section and header information for a message in the accelerator of the O-DU based at least in part on input received from an O-DU application executing on the O-DU.

[0067] In some aspects, the O-DU may generate or expect a user or control plane message in an O-DU application running on the O-DU. The O-DU may transmit the user plane message from the O-DU application to the O-RU via a pass-through of the O-DU's accelerator based at least in part on the O-DU's accelerator not supporting a channel associated with the user plane message.

[0068] In some aspects, the O-DU may generate a first message in an O-DU application running on the O-DU that does not utilize an O-DU accelerator of an O-DU that is inline with the O-DU application. The O-DU may send the first message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator. The first message may not utilize the O-DU accelerator based at least in part on the payload of the first message being forwarded to the O-RU unaltered by the O-DU accelerator. The O-DU may generate a second message via hardware acceleration in the O-DU accelerator based at least in part on the FAPI between the O-DU accelerator and the O-DU application. The O-DU may send the second message from the O-DU accelerator to the O-RU. In some aspects, the first message may be a control plane message, and the second message may be a control plane message or a user plane message.

[0069] In some aspects, the O-DU may receive a third message from the O-RU at the O-DU application via a pass-through of the O-DU accelerator. The O-DU may interpret the third message at the O-DU application without utilizing the O-DU accelerator. The O-DU may receive a fourth message from the O-RU at the O-DU accelerator. The O-DU may interpret the fourth message at the O-DU accelerator based at least in part on a functional application platform interface between the O-DU accelerator and the O-DU application, and the fourth message may be subject to hardware acceleration at the O-DU accelerator. In some aspects, the first message and the second message may be associated with an O-DU transmit message, and the third message and the fourth message may be associated with an O-DU receive message.

[0070] In some aspects, the first and third messages may be accelerator-independent messages that may be generated or interpreted in the O-DU application and may pass transparently through the O-DU accelerator. The second and fourth messages may be accelerator engagement or accelerator awareness messages and may require that at least one parameter (e.g., beam weights or I / Q samples or decoded samples) is to be generated or interpreted by the O-DU accelerator.

[0071] In some aspects, the O-DU may support multiple channels, and the first message, the second message, the third message, and the fourth message may be associated with one or more channels included in the multiple channels. In some aspects, the first message generated in the O-DU application may be coordinated with the second message generated in the O-DU accelerator in terms of data frame, beam index, or time and frequency mapping to spatial streams, and similarly, the third message interpreted in the O-DU application may be coordinated with the fourth message interpreted in the O-DU accelerator.

[0072] In some aspects, to transmit the first message via a pass-through of the O-DU accelerator, the O-DU may embed the payload of the first message at the O-DU accelerator via the transport interface towards the O-RU, where the first message may indicate compression of beam weights, I / Q samples, or other parameters describing the wireless channel associated with the O-DU. In some aspects, to receive the third message via a pass-through of the O-DU accelerator, the O-DU may extract the payload of the third message at the O-DU accelerator, where the third message may indicate decompression of the beam weights, I / Q samples, or other parameters describing the wireless channel associated with the O-DU. In other words, the pass-through may concern only the message payload, and the O-DU accelerator may still be involved in minimal processing, for example, to transpose the message payload to the transport layer or compress / decompress the beamforming weights. Other parameters describing the wireless channel may relate to information summarizing or describing the wireless channel (Uu) or samples on the wireless channel (eg, channel modeling or estimation parameters).

[0073] In some aspects, the first message may be associated with a beam weight that the O-RU can implicitly know, indicating that the first message is to pass through the O-DU accelerator, and the beam weight may be implicitly known to the O-RU based at least in part on a semi-static configuration, a dynamic configuration, or a dynamic implicit generation at the O-RU from a precoder indication from the O-DU. The beam weight may be implicitly known to the O-RU based at least in part on a previous semi-static configuration, a previous (dynamic explicit) signaling, or a dynamic implicit generation at the O-RU from a precoder indication (e.g., layer indexing) by the O-DU. The second message may be associated with information generated by the O-DU accelerator, including dynamically generated information for use in a message from the O-DU to the O-RU, at least one I / Q sample for use in a message from the O-DU to the O-RU, or at least one parameter signaling a result of accelerator-based decoding when the I / Q sample is received from the O-RU. The accelerator generated information may include at least one dynamically generated information for use in a fronthaul message from the O-DU to the O-RU (e.g., via the control plane), at least one I / Q sample for use in a fronthaul message from the O-DU to the O-RU (e.g., via the user plane), or at least one parameter signaling a result of accelerator-based decoding if an I / Q sample is received from the fronthaul.

[0074] In some aspects, the O-DU may initiate signaling between the O-DU application and the O-DU accelerator to negotiate the type of messages passing through the O-DU accelerator and the type of messages to be hardware accelerated at the O-DU accelerator. In some aspects, the O-DU may initiate signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with fragmentation or reassembly to be performed by the O-DU application or the O-DU accelerator. In some aspects, the O-DU may initiate signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with compression or decompression to be performed by the O-DU application or the O-DU accelerator.

[0075] In some aspects, the O-DU may generate (or interpret) section or header information in the O-DU application for a second message that passes through the O-DU accelerator without being subject to hardware acceleration. In some aspects, the O-DU may generate or interpret section or header information for the second message in the O-DU accelerator based at least in part on input received from the O-DU application.

[0076] In some aspects, the O-DU may generate a second message in the O-DU application. The O-DU may transmit the second message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator based at least in part on the O-DU accelerator not supporting a channel associated with the second message. In some aspects, the O-DU may receive a third message from the O-RU in the O-DU application via a pass-through of the O-DU accelerator based at least in part on the O-DU accelerator not supporting a channel associated with the third message. The O-DU may interpret the third message in the O-DU application that does not utilize the O-DU accelerator.

[0077] In some aspects, the O-DU may initiate management plane signaling in a management plane entity associated with the O-DU application with a management plane entity associated with the O-RU, and the management plane signaling may be associated with O-RU initialization, O-RU discovery, or O-RU orchestration.

[0078] In some aspects, the O-DU may transmit the first message through a pass-through of the O-DU accelerator based at least in part on signaling by the O-DU application of a location where the O-DU accelerator generates or expects I / Q samples, beam weights, beam index, channel estimates, or decoded data, and the location may be associated with the first message or memory location generated by the application. In other words, the O-DU accelerator may generate I / Q / beam / channel estimate samples in a memory location without needing to know how the O-DU application packages the location with other message fields. In some aspects, the O-DU may transmit the first message through a pass-through of the O-DU accelerator based at least in part on signaling by the O-DU application of I / Q samples, beam weights, beam index, channel estimates, decoded data, and other information associated with the message header and parameters to be generated or interpreted by the O-DU accelerator. In other words, the O-DU accelerator may generate both I / Q / beam / CE samples and message headers / parameters based at least in part on the FAPI abstraction. In some aspects, the O-DU may transmit a first message through a pass-through of the O-DU accelerator based at least in part on signaling by the O-DU application of a second type message to be used by the O-DU accelerator for generating or interpreting the first type message, the second type message may be associated with a control plane message, and the first type message may be associated with a control plane message and a user plane message.

[0079] As noted above, Figure 5 is provided as an example. Other examples may differ from that described with respect to Figure 5.

[0080] FIG. 6 is a diagram illustrating an embodiment 600 associated with accelerator pass-through for control plane messages in an O-DU in accordance with the present disclosure.

[0081] In some aspects, similar to FIG. 5, messages are shown from O-DU to O-RU, but messages terminated at the O-DU may also be subject to accelerator pass-through or accelerator processing.

[0082] In some aspects, the O-DU may execute an O-DU application that may be associated with a MAC layer. At the O-DU, the MAC implementation may include some OFH control plane functions. The O-DU application may communicate with an accelerator at the O-DU via the FAPI. The accelerator may include a hardware accelerator. The application may utilize associated libraries / drivers to communicate with the accelerator. The accelerator may be a high PHY layer inline accelerator. The O-DU may communicate with an O-RU that may be associated with a low PHY layer. The accelerator may be inline, since it may be between the O-DU application and the O-RU. In some aspects, the accelerator may generate or expect control plane and user plane messages based at least in part on the FAPI between the accelerator and the O-DU application, and the control plane and user plane messages may be sent to or received from the O-RU. In other words, the control plane and user plane messages generated or expected at the accelerator may be subject to hardware acceleration at the accelerator. The control plane messages may be OFH control plane messages. In some aspects, some control plane messages may be generated or expected in the O-DU application. These control plane messages may pass through the accelerator and then be sent to or received from the O-RU. In other words, these control plane messages passing through the accelerator may not be subject to hardware acceleration at the accelerator, which may improve the performance of the accelerator since many control plane messages are not well suited for acceleration and unnecessarily consume cycles at the accelerator that could otherwise be used for higher value functions.

[0083] In some aspects, the O-DU application and the accelerator may negotiate which messages have pass-through enabled (e.g., which control plane messages pass through the accelerator and are not subject to hardware acceleration) and which messages do not have pass-through enabled (e.g., which control plane messages are generated at the accelerator and are subject to hardware acceleration). The O-DU application can communicate with the accelerator to negotiate which messages have pass-through enabled.

[0084] In some aspects, the accelerator may provide a transparent path for messages between the O-DU application and the O-RU. The transparent path may enable pass-through of messages through the accelerator. In some aspects, the accelerator does not perform hardware acceleration on the messages, but the accelerator may perform other functions on the messages. For example, the accelerator may be responsible for enhanced common public radio interface (eCPRI) headers for the messages. As another example, the accelerator may be responsible for compression or decompression of sample or weight values ​​in the messages. As another example, the accelerator may be responsible for fragmentation / segmentation / aggregation of messages at the time of transposition with the fronthaul transport.

[0085] In some aspects, messages subject to pass-through may include various section identifiers that indicate corresponding resources, and the section identifiers may be referenced in non-pass-through messages. Section identifier management may involve having consistent section identifiers between control plane messages and user plane messages. The O-DU application may be responsible for section identifier processing for control plane messages that pass through the accelerator. The O-DU application may also be responsible for section identifier processing for control plane and / or user plane messages that do not pass through the accelerator (e.g., non-pass-through messages), such that the O-DU application may provide the accelerator with section identifiers for these non-pass-through messages.

[0086] In some aspects, the accelerator may be applicable to multiple channels and / or signals, including PDSCH, PDSCH DMRS, physical downlink control channel (PDCCH), PDCCH DMRS, physical broadcast channel (PBCH), PSS / SSS PBCH DMRS, channel state information reference signal (CSI-RS), phase tracking reference signal (PT-RS), and / or tracking reference signal (TRS). In some aspects, the accelerator may provide simultaneous support for multiple channels and / or signals, such as PDSCH, PDSCH DMRS, PDCCH, PDCCH DMRS, PBCH, PSS / SSS PBCH DMRS, CSI-RS, PT-RS, and / or TRS. In some examples, the accelerator may support a particular channel and / or signal.

[0087] In some aspects, the pass-through of control plane messages through the accelerator may be beneficial to bypass generation or interpretation of FAPI messages (e.g., FAPI P19) for interfacing between an O-DU application and a front-end unit associated with the accelerator, where the front-end unit functionality may be hosted at least in part by the O-RU. The FAPI P19 interface may be used for analog beamforming. Since the P19 interface does not directly affect the baseband associated with the accelerator, the O-DU application may directly send OFH control plane messages that bypass the baseband associated with the accelerator, thereby bypassing the need to terminate the FAPI P19 at the O-DU accelerator. In some aspects, the pass-through of control plane messages through the accelerator may be beneficial for control plane messages with section type 0, which may signal an empty resource block, where no user plane information is sent and where the accelerator may not add any value. In this case, these control plane messages may benefit from passing through the accelerator. In some cases, the accelerator may be instructed to avoid generating or interpreting samples for empty resource blocks, and in other cases, recipients of OFH messages associated with empty RBs may be instructed or programmed to ignore samples associated with such empty RBs.

[0088] In some aspects, control plane messages generated by the O-DU application may be coordinated or combined with user plane messages generated by the accelerator. Because the control plane messages and user plane messages may be generated by different entities in the pass-through approach (e.g., an accelerator may be used to pass through some control plane messages, while user plane control messages may be generated in the O-DU application), a common understanding of some FH allocation dimensions (or allocation abstractions) may be needed. The FH allocation dimensions may include time and frequency mapping to data frames that may be needed for the O-DU to generate and interpret user plane messages. Furthermore, the FH allocation dimensions may include beam management, which relates to beam management decisions performed in the O-DU application versus the accelerator for control plane messages and user plane messages. Furthermore, the FH allocation dimensions may include spatial beam management, which relates to control plane messages and user plane messages. A common understanding of the FH allocation dimensions may enable the pass-through approach when the control plane messages and user plane messages are generated by different entities.

[0089] In some aspects, the accelerator (e.g., MAC / PHY interface) may support a PHY layer that generates only user plane messages for at least one channel, and the O-DU application (e.g., MAC layer) may generate control plane messages for the channel. In some aspects, the accelerator and the O-DU application may have the capability to negotiate which control plane messages should pass through the accelerator. The O-DU application may generate beam weights (e.g., DU generated beam weights) for different control plane messages, and control plane messages related to implicit beam weights may pass through the accelerator, and control plane messages signaling dynamic weights may not pass through the accelerator. In some aspects, the accelerator and the O-DU application may negotiate the control plane generation per channel (e.g., the channel on which the control plane messages are generated). The accelerator and the O-DU application may negotiate the user plane generation per channel (e.g., the channel on which the user plane messages are generated). In some aspects, the accelerator and the O-DU application may negotiate whether the accelerator or the O-DU application should handle data fragmentation based at least in part on the maximum frame size. In some aspects, the accelerator and the O-DU application may negotiate parameters associated with the compression to be performed at the accelerator or the O-DU application.

[0090] In some aspects, for messages that are not pass-through messages based at least in part on DU-generated beam weights, message section and header generation may be processed by either the O-DU application or the accelerator. The messages may each include section and header information. In some aspects, the O-DU application may generate the message section and header information. Alternatively, the accelerator may generate the message section and header information based at least in part on input received from the O-DU application. In other words, in this case, the O-DU application may provide input to assist the accelerator in generating the section and header information.

[0091] In some aspects, signaling of allocation abstractions (or FH allocation dimensions) may be supported from the O-DU application to the accelerator (or higher PHY layer) for pass-through of control plane messages, and the signaling of the allocation abstractions may be associated with frequency and time mapping, individual management of beam indices (e.g., O-DU application generated or implicit weights, or accelerator generated or dynamic weights), and / or extended antenna carrier (eAxCs) mapping to multiple RU categories. The signaling of the allocation abstractions may enable the accelerator to generate or interpret messages associated with the control plane messages generated by the O-DU application regarding frequency and time mapping, individual management of beam indices, and eAxCss mapping to multiple RU categories. In some aspects, the signaling of the allocation abstractions may enable the generation of FAPI data structures that enable the accelerator to generate / receive user plane I / Q samples and beam weights in a manner as expected by the FH. In some aspects, the signaling of the allocation abstraction may enable the accelerator to pass control plane messages directly through, with optional links between the FAPI channel and the associated control plane sections and couplings. In some aspects, the signaling of the allocation abstraction may enable a shared memory location for the accelerator to write / retrieve I / Q samples, which may be between the O-DU and the O-RU. In a particular example, the shared memory location may be between the O-DU / O-RU FH eCPRI transport and the accelerator module. In some aspects, the signaling of the allocation abstraction may enable concatenation or interpretation of application-generated message headers, header parameters, or application-indicated header parameters with message sections to generate or interpret I / Q samples or weights at the accelerator.

[0092] In some aspects, the allocation abstraction signaling may include rate matching associations, where the MAC layer may identify overlaps between PDSCH allocations and other channels, and may enable generation of section priority information. The allocation abstraction signaling may include beamforming and precoding information, such as information regarding precoders, beams, and / or weights. The allocation abstraction signaling may include eAxCSs mappings, where the MAC layer may identify various spatial streams.

[0093] In some aspects, a set of FAPI hard-coded or explicit capabilities may indicate limitations associated with frequency and time mapping, individual management of beam indices, and eAxCSs mapping for multiple RU categories. For example, such limitations may be associated with the shape of the frequency and time area, the resource element pattern, the type of bonding supported by the O-RAN, the amount of abstraction per channel where a particular abstraction is mapped to physical resource block (PRB) and symbol allocations, and / or the extension types supported.

[0094] In some aspects, for non-pass-through channels, the FAPI may be updated for inputs / outputs other than MAC transport blocks (TBs), such as modulation symbols, codeword or codeblock bits, or modulation symbols. Depending on the input / output, some FAPI parameter values ​​may be "don't care" values.

[0095] As noted above, Figure 6 is provided as an example. Other examples may differ from that described with respect to Figure 6.

[0096] FIG. 7 is a diagram illustrating an embodiment 700 associated with accelerator pass-through for control plane messages and user plane messages in an O-DU in accordance with the present disclosure.

[0097] In some aspects, similar to FIG. 5, messages are shown from O-DU to O-RU, but messages terminated at the O-DU may also be subject to accelerator pass-through or accelerator processing.

[0098] In some aspects, the O-DU may execute an O-DU application, which may be associated with a MAC layer. The O-DU application may communicate with an accelerator in the O-DU via the FAPI. The accelerator may include a hardware accelerator and associated libraries / drivers. The accelerator may be a high PHY layer inline accelerator. The O-DU may communicate with an O-RU, which may be associated with a low PHY layer. The accelerator may be inline, since it may be between the O-DU application and the O-RU. In some aspects, the accelerator may generate control plane messages and user plane messages based at least in part on the FAPI between the accelerator and the O-DU application, and the control plane messages and user plane messages may be transmitted to the O-RU. In other words, the control plane messages and user plane messages generated in the accelerator may be subject to hardware acceleration in the accelerator. The control plane messages may be OFH control plane messages. In some aspects, some control plane messages and some user plane messages may be generated in the O-DU application. These control and user plane messages may pass through the accelerator and then be sent to the O-RU, In other words, these control and user plane messages passing through the accelerator may not be subject to hardware acceleration at the accelerator, which may improve the performance of the accelerator.

[0099] In some aspects, pass-through may be applicable to user plane messages as well as control plane messages for accelerator profiles that do not support some channels. For example, for accelerators that do not support PDCCH or for applications that choose not to utilize hardware acceleration of PDCCH, user plane messages may also pass through the accelerator. In some aspects, FAPI between the O-DU application and accelerator may be used for accelerated functions (as these control and user plane messages are subject to hardware acceleration at the accelerator), and pass-through of user plane and / or control plane messages through the accelerator may be used for other functions. In some other aspects, accelerated functions may be functional blocks that configure a particular channel (e.g., low density parity check (LDPC) coding), except for some functions (e.g., modulation) that are handled by the application layer. In this latter aspect, FAPI functions may be limited to parameters that control those accelerated blocks, as well as extended to define the inputs and outputs of accelerated blocks, especially when the output of one accelerated block is not the input of the immediately following accelerated block or the transposition to / from the OFH transport.

[0100] As noted above, Figure 7 is provided as an example. Other examples may differ from that described with respect to Figure 7.

[0101] FIG. 8 is a diagram illustrating an embodiment 800 associated with a management plane architecture at an O-DU in accordance with the present disclosure.

[0102] In some aspects, the O-DU may execute an O-DU application. The O-DU application may communicate with an accelerator in the O-DU via the FAPI. The accelerator may include a hardware accelerator and associated libraries / drivers. The accelerator may be a high PHY layer inline accelerator. The O-DU may communicate with an O-RU, which may be associated with a low PHY layer. The O-DU application may be associated with a management plane (M-Plane), which may reside in the O-DU application. The management plane may reside in the O-DU application and may be assisted by a management plane helper, which may reside in the accelerator. In other words, the management plane may not terminate in the accelerator, but rather, the accelerator may include a management plane assister to assist the management plane in the O-DU application. In some aspects, the management plane in the O-DU application may communicate with a management plane in the O-RU. The management plane functions may involve O-RU initialization, discovery, and / or orchestration. Additionally, the management plane function may involve pooling of accelerator resources to switch an O-RU from one accelerator to another in some circumstances.

[0103] In some aspects, the assistance may involve at least in part a translation between O-RAN management plane O-DU or O-RU parameters and equivalent FAPI P5 or P19 configuration or capability parameters. The translation may further involve transport of capability and / or configuration parameters between the O-DU and O-RU as required for consistent configuration and capability awareness between application / accelerator interfaces and the O-DU / O-RU interface.

[0104] In some aspects, the management plane may terminate at the O-DU application (or MAC layer) and the relevant parameters may be reflected in the FAPI operation. The relevant parameters may not include the control plane section number. In some aspects, the O-DU application may interpret the management plane instead of interpreting the control plane. Furthermore, the relevant parameters may be associated with a semi-static FAPI configuration that may reflect the management plane configuration channel.

[0105] As noted above, Figure 8 is provided as an example. Other examples may differ from that described with respect to Figure 8.

[0106] In some aspects, control plane messages generated in the O-DU application may be coordinated or combined with user plane messages generated in the accelerator based at least in part on a common understanding of some FH allocation dimensions. The user plane may be associated with frequency domain I / Q samples and data at the resource block and symbol level. The control plane may be associated with data related control (e.g., scheduling and beamforming). One or more control plane section type sections may be required to interpret / control I / Q samples within a single user plane message for a given eAxC.

[0107] In some aspects, for the FAPI, a channel protocol data unit (PDU) may be associated with a time and frequency mapping per slot and a set of spatial streams. For a set of I / Q samples, the control plane may define a symbol mapping of RBs or resource elements (REs) and I / Q samples in a user plane message, and the user plane message may be associated with a spatial stream (e.g., an eAxC identifier).

[0108] In some aspects, with regard to separating control plane and user plane messages, the accelerator (or PHY layer) may generate I / Q samples expected by the O-RU. The accelerator may skip blank PRBs and / or assign I / Q samples to the correct data frame identifier, which may ensure correct packaging of the I / Q samples. Assuming separation, a channel PDU may map to a single user plane frame per symbol, and the O-RAN user plane allocation may be rectangular (e.g., time and frequency per slot). In some cases, to support separation, an O-RAN user plane frame may aggregate I / Q samples from multiple channels, and a channel may be divided into multiple O-RAN user plane frames.

[0109] In some aspects, the I / Q data frame allocation within a slot may be represented as a rectangular resource allocation template having a PRB and symbol resolution, a bitmap of excluded PRBs and symbols, deterministic rules for generating I / Q samples, rules for zero-filling I / Q samples that are not explicitly excluded, and / or an I / Q sample compression scheme where the data frame may be irregularly shaped.

[0110] In some aspects, analog and digital beam management may be separated, digital beams may be associated with channel PDUs, and analog beams may be associated with symbols (or slots) and subbands. Beam management may involve correctly filling the beam index and weights in the appropriate control plane section. The precoder / beam index and / or precoder weights may be controlled by the MAC layer. Dynamic precoder weights may be generated by the accelerator based at least in part on indexing in the MAC layer, which may guide the accelerator to generate a control plane template, and the accelerator may fill the control plane template with the calculated beam weights. The accelerator may also fill the beam index from a reserved range (signaled by the MAC layer). In some aspects, in hybrid beamforming, analog beams may be signaled to the accelerator and may not be transparent, and the FAPI may require on-the-fly updates of analog beamforming entries that may be conveyed to the O-RU via the control plane.

[0111] In some aspects, an I / Q data frame may be associated with an O-RAN beam index, which may correspond to a FAPI precoder index and / or a beam or a combination thereof. An I / Q data frame may be a basic unit for abstracting the allocation dimension, and an I / Q data frame may be associated with a PRB and a rectangular set of symbols, along with a set of RE patterns and eAxC identifiers. Furthermore, each PRB or the entire rectangular set may be associated with a set of beam indices, and each beam may be mapped to an eAxC identifier.

[0112] In some aspects, with regard to section and header management, the O-DU application (or MAC layer) may inform the accelerator (or PHY layer) of the section identifier to be associated with the user plane data frame. The data frame header may be added to the accelerator-generated (or PHY-generated) I / Q samples (or user plane samples), for example in a shared memory or via concatenation.

[0113] In some aspects, the abstraction may involve a shared memory location. The abstraction may correspond to a structure that indicates, for each spatial stream, the symbol identifier, the starting PRB, the total number of PRBs, the compression scheme, and / or the shared memory location. For the downlink, the accelerator may place the I / Q samples in the shared memory location. For the uplink, the accelerator may extract the I / Q samples from the shared memory location. A trigger mechanism (e.g., an event or arrival window) may be required for the uplink to determine when valid I / Q samples are available. In this case, the O-DU application (or MAC layer) may handle the fragmentation and eAxC identifier mapping. However, the shared memory location approach may not be preferable for interfaces that do not share memory.

[0114] In some aspects, the RE mapping abstraction may be sent as a control plane message (or section) that can be interpreted by the accelerator. Each FAPI style allocation may be linked to a control plane section(s) signaling the resulting RE of the allocation, a user plane section for holding the RE, and / or a binding type. The "binding type" may refer to binding by section, binding by frequency and time, or binding by frequency and time with priority. In this case, fewer FAPI updates may be required. However, the accelerator (or O-DU high PHY layer) may need to interpret the control plane structure, which may increase the complexity in the accelerator.

[0115] In some aspects, the coupling of the control plane and the user plane is based at least in part on a section identifier and may be by frequency and time, and therefore coordination between the control plane and the user plane may be envisaged. Separation may be required to allow for control plane pass-through. Separation may be achieved via user plane templates and / or capability adjustments. The user plane templates may be user plane section placeholders. The O-DU application may be responsible for generating the user plane templates based at least in part on the multiplexing of channels into the user plane templates.

[0116] In some aspects, with regard to FAPI capabilities, the O-DU may signal an indication indicating the O-DU's ability to support pass-through operation. The O-DU may indicate whether the O-DU supports DU-generated beam weights, as well as any limitations on applicable compression techniques and resolution (e.g., per section or PRB). The O-DU may indicate any limitations on channels on which control plane pass-through is supported. The O-DU may indicate any limitations on channels on which user plane pass-through is supported (e.g., for hardware accelerated compression, etc.). The O-DU may indicate any limitations on support for various FH section extension types (e.g., when the abstraction is signaled in FH format).

[0117] 9 illustrates an example process 900 implemented, for example, by an O-DU, in accordance with the present disclosure. The example process 900 is an example of an O-DU (e.g., base station 110) performing operations associated with passing through a message in an accelerator of a distributed unit.

[0118] 9, in some aspects, the process 900 may include generating, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of the O-DU that is inline with the O-DU application (block 910). For example, as described above, the O-DU may generate (e.g., using the communications manager 150 and / or the generating component 1008 shown in FIG. 10) a first message in an O-DU application running on the O-DU that does not utilize an O-DU accelerator of the O-DU that is inline with the O-DU application.

[0119] 9, in some aspects, the process 900 may include transmitting a first message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator, where the first message does not utilize the O-DU accelerator (block 920) based at least in part on the payload of the first message being forwarded to the O-RU without modification by the O-DU accelerator. For example, as described above, the O-DU (e.g., using the communication manager 150 and / or the transmitting component 1004 shown in FIG. 10) may transmit a first message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator, where the first message does not utilize the O-DU accelerator based at least in part on the payload of the first message being forwarded to the O-RU without modification by the O-DU accelerator.

[0120] Process 900 may include additional aspects, such as any single aspect or any combination of aspects described below and / or with respect to one or more other processes described elsewhere herein.

[0121] In a first aspect, the process 900 includes embedding, at an O-DU accelerator, a payload of a first message over a transport interface toward an O-RU, the first message indicating compression of beam weights, I / Q samples, or other parameters describing a wireless channel associated with the O-DU.

[0122] In a second aspect, alone or in combination with the first aspect, the process 900 includes generating, at the O-DU accelerator, a second message based at least in part on a functional application platform interface between the O-DU accelerator and the O-DU application, where the second message is generated through hardware acceleration in the O-DU accelerator, and sending the second message from the O-DU accelerator to the O-RU.

[0123] In a third aspect, alone or in combination with one or more of the first and second aspects, the first message is a control plane message and the second message is a control plane message or a user plane message.

[0124] In a fourth aspect, alone or in combination with one or more of the first to third aspects, the first message is associated with a beam weight that the O-RU can implicitly know, indicating that the first message is to pass through the O-DU accelerator, the beam weight being implicitly known to the O-RU based at least in part on a semi-static configuration, a dynamic configuration, or a dynamic implicit generation at the O-RU from a precoder instruction from the O-DU, and the second message is associated with information generated by the O-DU accelerator, including dynamically generated information for use in a message from the O-DU to the O-RU, at least one I / Q sample for use in a message from the O-DU to the O-RU, or at least one parameter signaling a result of accelerator-based decoding when the I / Q sample is received from the O-RU.

[0125] In a fifth aspect, alone or in combination with one or more of the first to fourth aspects, the process 900 includes initiating signaling between the O-DU application and the O-DU accelerator to negotiate a type of message passing through the O-DU accelerator and a type of message to be subject to hardware acceleration at the O-DU accelerator.

[0126] In a sixth aspect, alone or in combination with one or more of the first through fifth aspects, the process 900 includes supporting a plurality of channels, and the first message is associated with a channel included in the plurality of channels.

[0127] In a seventh aspect, alone or in combination with one or more of the first to sixth aspects, the process 900 includes initiating signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with fragmentation or reassembly to be performed by the O-DU application or the O-DU accelerator, or initiating signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with compression or decompression to be performed by the O-DU application or the O-DU accelerator.

[0128] In an eighth aspect, alone or in combination with one or more of the first to seventh aspects, the process 900 includes generating or interpreting, at the O-DU application, section or header information for the second message that does not pass through the O-DU accelerator, or generating or interpreting, at the O-DU accelerator, section or header information for the second message based at least in part on input received from the O-DU application.

[0129] In a ninth aspect, alone or in combination with one or more of the first to eighth aspects, the process 900 includes generating, in the O-DU application, a second message; and, based at least in part on the O-DU accelerator not supporting a channel associated with the second message, sending the second message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator.

[0130] In a tenth aspect, alone or in combination with one or more of the first to ninth aspects, the process 900 includes, in a management plane entity associated with an O-DU application, initiating or terminating management plane signaling with a management plane entity associated with the O-RU, the management plane signaling being associated with O-RU initialization, O-RU discovery, or O-RU orchestration, the management plane entity being present in the O-DU application and assisted by a management plane helper being present in the O-DU accelerator.

[0131] In an eleventh aspect, alone or in combination with one or more of the first to tenth aspects, a first message generated in an O-DU application is coordinated with a second message generated in an O-DU accelerator in terms of time and frequency mapping to a data frame, a beam index, or a spatial stream.

[0132] In a twelfth aspect, alone or in combination with one or more of the first to eleventh aspects, transmitting the first message via a pass-through of the O-DU accelerator is based at least in part on one of: signaling by the O-DU application of a location where the O-DU accelerator generates or expects I / Q samples, beam weights, beam indexes, channel estimates, or decoded data, which is associated with the first message or memory location generated by the application; signaling by the O-DU application of I / Q samples, beam weights, beam indexes, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or signaling by the O-DU application of a second type of message associated with a control plane message, which is to be used by the O-DU accelerator for generating or interpreting a first type of message associated with a control plane message and a user plane message.

[0133] In a thirteenth aspect, alone or in combination with one or more of the first to twelfth aspects, the process 900 includes receiving a third message from the O-RU at the O-DU application via a pass-through of the O-DU accelerator, and interpreting, at the O-DU application, the third message without utilizing the O-DU accelerator.

[0134] In a fourteenth aspect, alone or in combination with one or more of the first to thirteenth aspects, the process 900 includes receiving a fourth message from the O-RU at the O-DU accelerator; and interpreting the fourth message at the O-DU accelerator based at least in part on a functional application platform interface between the O-DU accelerator and the O-DU application, where the fourth message is subject to hardware acceleration in the O-DU accelerator.

[0135] In a fifteenth aspect, alone or in combination with one or more of the first to fourteenth aspects, receiving the third message via a pass-through of the O-DU accelerator includes extracting a payload of the third message at the O-DU accelerator, the third message indicating decompression of beam weights, I / Q samples, or other parameters describing a wireless channel associated with the O-DU.

[0136] In a sixteenth aspect, alone or in combination with one or more of the first to fifteenth aspects, the first message and the second message are associated with an O-DU transmit message, and the third message and the fourth message are associated with an O-DU receive message.

[0137] In a seventeenth aspect, alone or in combination with one or more of the first to sixteenth aspects, the process 900 includes receiving, at the O-DU application, a third message from the O-RU via a pass-through of the O-DU accelerator based at least in part on the O-DU accelerator not supporting a channel associated with the third message, and interpreting, at the O-DU application, the third message that does not utilize the O-DU accelerator.

[0138] 9 illustrates example blocks of process 900, in some aspects process 900 may include additional, fewer, different, or differently arranged blocks compared to the blocks illustrated in FIG 9. Additionally or alternatively, two or more of the blocks of process 900 may be performed in parallel.

[0139] FIG. 10 is a diagram of an example apparatus 1000 for wireless communication. The apparatus 1000 may be an O-DU, or the O-DU may include the apparatus 1000. In some aspects, the apparatus 1000 includes a receiving component 1002 and a transmitting component 1004, which may be in communication with each other (e.g., via one or more buses and / or one or more other components). As shown, the apparatus 1000 may communicate with another apparatus 1006 (such as a UE, a base station, or another wireless communication device) using the receiving component 1002 and the transmitting component 1004. As further shown, the apparatus 1000 may include a communications manager 150. The communications manager 150 may include one or more of a generating component 1008 or an initiating component 1010, among other examples.

[0140] In some aspects, the apparatus 1000 may be configured to perform one or more operations described herein with respect to FIGS. 5-8. Additionally or alternatively, the apparatus 1000 may be configured to perform one or more processes described herein, such as the process 900 of FIG. 9. In some aspects, the apparatus 1000 and / or one or more components illustrated in FIG. 10 may include one or more components of the O-DU described with respect to FIG. 2. Additionally or alternatively, one or more components illustrated in FIG. 10 may be implemented within one or more components described with respect to FIG. 2. Additionally or alternatively, one or more components of the set of components may be implemented at least in part as software stored in a memory. For example, a component (or a portion of a component) may be implemented as instructions or code stored in a non-transitory computer-readable medium and executable by a controller or processor to perform the function or operation of the component.

[0141] The receiving component 1002 may receive communications, such as reference signals, control information, data communications, or combinations thereof, from the device 1006. The receiving component 1002 may provide the received communications to one or more other components of the device 1000. In some aspects, the receiving component 1002 may perform signal processing (such as filtering, amplification, demodulation, analog-to-digital conversion, demultiplexing, deinterleaving, demapping, equalization, interference cancellation, or decoding, among other examples) on the received communications and may provide the processed signals to one or more other components of the device 1000. In some aspects, the receiving component 1002 may include one or more antennas, a modem, a demodulator, a MIMO detector, a receive processor, a controller / processor, a memory, or a combination thereof of an O-DU as described with respect to FIG.

[0142] The transmitting component 1004 may transmit a communication, such as a reference signal, control information, a data communication, or a combination thereof, to the device 1006. In some aspects, one or more other components of the device 1000 may generate a communication and provide the generated communication to the transmitting component 1004 for transmission to the device 1006. In some aspects, the transmitting component 1004 may perform signal processing (such as filtering, amplifying, modulating, digital-to-analog conversion, multiplexing, interleaving, mapping, or encoding, among other examples) on the generated communication and may transmit the processed signal to the device 1006. In some aspects, the transmitting component 1004 may include one or more antennas, a modem, a modulator, a transmit MIMO processor, a transmit processor, a controller / processor, a memory, or a combination thereof, of an O-DU as described with respect to FIG. 2. In some aspects, the transmitting component 1004 may be collocated with the receiving component 1002 in a transceiver.

[0143] The generating component 1008 may generate, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of an O-DU that is inline with the O-DU application. The transmitting component 1004 may transmit the first message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator, the first message not utilizing the O-DU accelerator based at least in part on the payload of the first message being forwarded to the O-RU unaltered by the O-DU accelerator.

[0144] The transmitting component 1004 may embed a payload of a first message over the transport interface toward the O-RU at the O-DU accelerator, the first message indicating compression of beam weights, I / Q samples, or other parameters describing a wireless channel associated with the O-DU.

[0145] The generating component 1008 may generate a second message in the O-DU accelerator based at least in part on a functional application platform interface between the O-DU accelerator and the O-DU application, where the second message is subject to hardware acceleration in the O-DU accelerator. The transmitting component 1004 may transmit the second message from the O-DU accelerator to the O-RU.

[0146] The initiation component 1010 may signal between the O-DU application and the O-DU accelerator to negotiate the type of messages passing through the O-DU accelerator and the type of messages to be subject to hardware acceleration at the O-DU accelerator. The initiation component 1010 may initiate signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with fragmentation or reassembly to be performed by the O-DU application or the O-DU accelerator, or may initiate signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with compression or decompression to be performed by the O-DU application or the O-DU accelerator.

[0147] The generating component 1008 may generate or interpret section or header information for a second message in an O-DU application that does not pass through the O-DU accelerator. The generating component 1008 may generate or interpret section or header information for a second message in an O-DU application that does not pass through the O-DU accelerator.

[0148] The generating component 1008 may generate a second message in the O-DU application. The transmitting component 1004 may transmit the second message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator based at least in part on the O-DU accelerator not supporting a channel associated with the second message.

[0149] The initiation component 1010 can initiate management plane signaling in a management plane entity associated with the O-DU application with a management plane entity associated with the O-RU, where the management plane signaling is associated with O-RU initialization, O-RU discovery, or O-RU orchestration, where the management plane entity resides in the O-DU application and is assisted by a management plane helper resides in the O-DU accelerator.

[0150] The transmitting component 1004 may transmit the first message through a pass-through of the O-DU accelerator based at least in part on one of: signaling by the O-DU application of a location where the O-DU accelerator generates or expects in-phase and quadrature (I / Q) samples, beam weights, beam indexes, channel estimates, or decoded data associated with the first message or memory location generated by the application; signaling by the O-DU application of I / Q samples, beam weights, beam indexes, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or signaling by the O-DU application of a second type of message associated with a control plane message to be used by the O-DU accelerator for generating or interpreting a first type of message associated with a control plane message and a user plane message.

[0151] The receiving component 1002 may receive a third message from the O-RU in the O-DU application via a pass-through of the O-DU accelerator, and interpret the third message in the O-DU application without utilizing the O-DU accelerator.

[0152] The receiving component 1002 can receive a fourth message from the O-RU at the O-DU accelerator, and interpret the fourth message at the O-DU accelerator based at least in part on a functional application platform interface between the O-DU accelerator and the O-DU application, where the fourth message is subject to hardware acceleration in the O-DU accelerator.

[0153] The receiving component 1002 may extract the payload of the third message at the O-DU accelerator, where the third message indicates decompression of beam weights, in-phase and quadrature (I / Q) samples, or other parameters describing a wireless channel associated with the O-DU.

[0154] The receiving component 1002 may receive the third message from the O-RU in the O-DU application via a pass-through of the O-DU accelerator based at least in part on the O-DU accelerator not supporting a channel associated with the third message, and may interpret the third message in the O-DU application without utilizing the O-DU accelerator.

[0155] The number and arrangement of components shown in Figure 10 is provided as one example. In practice, there may be additional, fewer, different, or differently arranged components compared to those shown in Figure 10. Furthermore, two or more of the components shown in Figure 10 may be implemented within a single component, or a single component shown in Figure 10 may be implemented as multiple distributed components. Additionally or alternatively, a set of components (or components) shown in Figure 10 may perform one or more functions that are described as being performed by another set of components shown in Figure 10.

[0156] FIG. 11 is a diagram illustrating an example disaggregated base station architecture 1100 in accordance with the present disclosure.

[0157] The deployment of a communication system such as a 5G NR system may be configured in multiple ways with various components or parts. In a 5G NR system or network, a network node, a network entity, a mobility element of the network, a RAN node, a core network node, a network element, or a network equipment such as a base station (BS, e.g., base station 110), or one or more units (or one or more components) performing a base station function may be implemented in an aggregated or non-aggregated architecture. For example, a BS (such as a Node B (NB), eNB, NR BS, 5G NB, Access Point (AP), TRP, or cell) may be implemented as an aggregated base station (also known as a standalone BS or monolithic BS) or a non-aggregated base station.

[0158] An aggregated base station may be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node. A non-aggregated base station may be configured to utilize a protocol stack that is physically or logically distributed between two or more units (e.g., one or more CUs, one or more DUs, or one or more RUs). In some aspects, a CU may be implemented within a RAN node, and one or more DUs may be co-located with the CU or alternatively geographically or virtually distributed across one or more other RAN nodes. A DU may be implemented to communicate with one or more RUs. Each of the CU, DU, and RU may be implemented as a virtual unit (e.g., a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU)).

[0159] The operation of a base station type or network design may take into account the aggregation characteristics of the base station functions. For example, a non-aggregated base station may be utilized in an IAB network, an O-RAN (such as a network configuration sponsored by the O-RAN Alliance), or a virtualized radio access network (vRAN, also known as a Cloud Radio Access Network (C-RAN)). Non-aggregation may include distributing functions across two or more units in various physical locations, as well as distributing functions virtually for at least one unit, which may allow flexibility in network design. Various units of a non-aggregated base station, or a non-aggregated RAN architecture, may be configured for wired or wireless communication with at least one other unit.

[0160] The unaggregated base station architecture shown in FIG. 11 may include one or more CUs 1110 that may communicate directly with the core network 1120 via a backhaul link or indirectly with the core network 1120 through one or more unaggregated base station units (such as a near-RT RIC 1125 via an E2 link, or a non-RT RIC 1115 associated with a service management and orchestration (SMO) framework 1105, or both). The CUs 1110 may communicate with one or more DUs 1130 via respective midhaul links, such as an F1 interface. The DUs 1130 may communicate with one or more RUs 1140 via respective fronthaul links. The RUs 1140 may communicate with respective UEs 120 via one or more radio frequency (RF) access links. In some implementations, a UE 120 may be served by multiple RUs 1140 simultaneously.

[0161] Each of the units (e.g., CU 1110, DU 1130, RU 1140), as well as the near-RT RIC 1125, the non-RT RIC 1115, and the SMO framework 1105, may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) over a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the unit's communication interface, may be configured to communicate with one or more of the other units over a transmission medium. For example, a unit may include a wired interface configured to receive or transmit signals to one or more of the other units over a wired transmission medium. In addition, a unit may include a wireless interface, which may include a receiver, transmitter, or transceiver (such as an RF transceiver), configured to receive and / or transmit signals to one or more of the other units over a wireless transmission medium.

[0162] In some aspects, the CU 1110 may host one or more upper layer control functions. Such control functions may include RRC, PDCP, SDAP, etc. Each control function may be implemented with an interface configured to communicate signals with other control functions hosted by the CU 1110. The CU 1110 may be configured to handle user plane functions (e.g., Central Unit-User Plane (CU-UP)), control plane functions (e.g., Central Unit-Control Plane (CU-CP)), or a combination thereof. In some implementations, the CU 1110 may be logically divided into one or more CU-UP units and one or more CU-CP units. The CU-UP units, when implemented in an O-RAN configuration, may communicate bidirectionally with the CU-CP units via an interface, such as an E1 interface. The CU 1110 may be implemented to communicate with the DU 1130, as needed, for network control and signaling.

[0163] The DU 1130 may correspond to a logical unit including one or more base station functions for controlling the operation of one or more RUs 1140. In some aspects, the DU 1130 may host one or more of an RLC layer, a MAC layer, and one or more higher PHY layers (such as modules for FEC encoding and decoding, scrambling, modulation, and demodulation, etc.), at least in part according to a functional division such as that defined by 3GPP. In some aspects, the DU 1130 may further host one or more lower PHY layers. Each layer (or module) may be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DU 1130 or with a control function hosted by the CU 1110.

[0164] The lower layer functions may be implemented by one or more RUs 1140. In some deployments, the RUs 1140 controlled by the DU 1130 may correspond to logical nodes hosting RF processing functions, or low PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional division such as a lower layer functional division. In such an architecture, the RU(s) 1140 may be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some implementations, real-time and non-real-time aspects of control and user plane communications with the RU(s) 1140 may be controlled by the corresponding DU 1130. In some scenarios, this configuration may enable the DU(s) 1130 and the CU 1110 to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

[0165] The SMO framework 1105 may be configured to support RAN deployment and provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 1105 may be configured to support deployment of dedicated physical resources for RAN coverage requirements that may be managed via an operation and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO framework 1105 may be configured to interact with a cloud computing platform (such as an open cloud (O-cloud) 1190) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as an O2 interface). Such virtualized network elements may include, but are not limited to, the CU 1110, the DU 1130, the RU 1140, and the near-RT RIC 1125. In some implementations, the SMO framework 1105 may communicate with hardware aspects of a 4G RAN, such as an open eNB (O-eNB) 1111, via an O1 interface. Additionally, in some implementations, the SMO framework 1105 can communicate directly with one or more RUs 1140 via an O1 interface. The SMO framework 1105 may also include a non-RT RIC 1115 configured to support the functionality of the SMO framework 1105.

[0166] The non-RT RIC 1115 may be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updates, or policy-based guidance of applications / features in the near-RT RIC 1125. The non-RT RIC 1115 may be coupled to or in communication with the near-RT RIC 1125 (e.g., via an A1 interface). The near-RT RIC 1125 may be configured to include logic functions that enable near real-time control and optimization of RAN elements and resources via one or more CUs 1110, one or more DUs 1130, or both, and data collection and action via an interface connecting the O-eNB to the near-RT RIC 1125 (e.g., via an E2 interface).

[0167] In some implementations, the non-RT RIC 1115 may receive parameters or external enrichment information from an external server to generate the AI / ML models deployed to the near-RT RIC 1125. Such information may be utilized by the near-RT RIC 1125 or may be received at the SMO framework 1105 or the non-RT RIC 1115 from non-network data sources or from network functions. In some examples, the non-RT RIC 1115 or the near-RT RIC 1125 may be configured to adjust RAN behavior or performance. For example, the non-RT RIC 1115 may employ the AI / ML models to monitor long-term trends and patterns regarding performance and take corrective action through the SMO framework 1105 (e.g., reconfiguration via O1) or through the creation of RAN management policies (e.g., A1 policies).

[0168] As noted above, Figure 11 is provided as an example. Other examples may differ from that described with respect to Figure 11.

[0169] The following provides a summary of several aspects of the disclosure. Aspect 1: A method of wireless communication performed by an open radio access network (O-RAN) distributed unit (O-DU), the method including: generating, in an O-DU application executing on the O-DU, a first message that does not utilize an O-DU accelerator of the O-DU that is inline with the O-DU application; and transmitting the first message from the O-DU application to an O-RAN radio unit (O-RU) via a pass-through of the O-DU accelerator, wherein the first message does not utilize the O-DU accelerator based at least in part on a payload of the first message being forwarded to the O-RU without modification by the O-DU accelerator.

[0170] Aspect 2: The method of aspect 1, wherein transmitting a first message via a pass-through of the O-DU accelerator further includes embedding a payload of the first message at the O-DU accelerator via a transport interface toward the O-RU, wherein the first message indicates compression of beam weights, in-phase and quadrature (I / Q) samples, or other parameters describing a wireless channel associated with the O-DU.

[0171] Aspect 3: The method of any of Aspects 1 to 2, further including: generating, in the O-DU accelerator, a second message based at least in part on a functional application platform interface between the O-DU accelerator and the O-DU application, the second message being generated through hardware acceleration in the O-DU accelerator; and sending the second message from the O-DU accelerator to the O-RU.

[0172] Aspect 4: The method of aspect 3, wherein the first message is a control plane message and the second message is a control plane message or a user plane message.

[0173] Aspect 5: The method of aspect 3, wherein the first message is associated with a beam weight that the O-RU can implicitly know, indicating that the first message is to pass through the O-DU accelerator, the beam weight being implicitly known to the O-RU based at least in part on a semi-static configuration, a dynamic configuration, or a dynamic implicit generation at the O-RU from a precoder instruction from the O-DU, and the second message is associated with information generated by the O-DU accelerator, the information including dynamically generated information for use in a message from the O-DU to the O-RU, at least one in-phase and quadrature (I / Q) sample for use in a message from the O-DU to the O-RU, or at least one parameter signaling a result of accelerator-based decoding when the I / Q sample is received from the O-RU.

[0174] Aspect 6: The method of any one of aspects 1 to 5, further including initiating signaling between the O-DU application and the O-DU accelerator to negotiate a type of message passing through the O-DU accelerator and a type of message to be subject to hardware acceleration in the O-DU accelerator.

[0175] Aspect 7: The method of any one of aspects 1 to 6, further comprising supporting a plurality of channels, the first message being associated with a channel included in the plurality of channels.

[0176] Aspect 8: The method according to any one of aspects 1 to 7, further comprising: initiating signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with fragmentation or reassembly to be performed by the O-DU application or the O-DU accelerator; or initiating signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with compression or decompression to be performed by the O-DU application or the O-DU accelerator.

[0177] Aspect 9: The method of any one of aspects 1 to 8, further comprising: at the O-DU application, generating or interpreting section or header information for a second message that does not pass through the O-DU accelerator; or at the O-DU accelerator, generating or interpreting section or header information for the second message based at least in part on an input received from the O-DU application.

[0178] Aspect 10: The method of any one of aspects 1 to 9, further including: generating, in an O-DU application, a second message; and, based at least in part on the O-DU accelerator not supporting a channel associated with the second message, sending the second message from the O-DU application to the O-RU through a pass-through of the O-DU accelerator.

[0179] Aspect 11: The method of any one of aspects 1 to 10, further comprising, in a management plane entity associated with an O-DU application, initiating or terminating management plane signaling with a management plane entity associated with an O-RU, the management plane signaling being associated with O-RU initialization, O-RU discovery, or O-RU orchestration, the management plane entity being present in the O-DU application and assisted by a management plane helper being present in the O-DU accelerator.

[0180] Aspect 12: The method of any one of aspects 1 to 11, wherein a first message generated in an O-DU application is coordinated with a second message generated in an O-DU accelerator in terms of a data frame, a beam index, or a time and frequency mapping to a spatial stream.

[0181] Aspect 13: The method of any one of aspects 1 to 12, wherein transmitting the first message via a pass-through of the O-DU accelerator is based at least in part on one of: signaling by the O-DU application of a location where the O-DU accelerator generates or expects in-phase and quadrature (I / Q) samples, beam weights, beam indexes, channel estimates, or decoded data, which is associated with the first message or memory location generated by the application; signaling by the O-DU application of I / Q samples, beam weights, beam indexes, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or signaling by the O-DU application of a second type of message associated with a control plane message to be used by the O-DU accelerator for generating or interpreting a first type of message associated with a control plane message and a user plane message.

[0182] Aspect 14: The method of any one of aspects 1 to 13, further including: receiving a third message from the O-RU in the O-DU application via a pass-through of the O-DU accelerator; and interpreting the third message in the O-DU application without utilizing the O-DU accelerator.

[0183] Aspect 15: A method as described in aspect 14, comprising receiving a fourth message from an O-RU at an O-DU accelerator, and interpreting the fourth message at the O-DU accelerator based at least in part on a functional application platform interface between the O-DU accelerator and an O-DU application, wherein the fourth message is subject to hardware acceleration in the O-DU accelerator.

[0184] Aspect 16: The method of aspect 14, wherein receiving a third message via a pass-through of an O-DU accelerator includes extracting a payload of the third message at the O-DU accelerator, the third message indicating decompression of beam weights, in-phase and quadrature (I / Q) samples, or other parameters describing a wireless channel associated with the O-DU.

[0185] Aspect 17: The method of aspect 16, wherein the first message and the second message are associated with an O-DU transmission message, and the third message and the fourth message are associated with an O-DU reception message.

[0186] Aspect 18: The method of any one of aspects 1 to 17, further including: receiving a third message from the O-RU at the O-DU application via a pass-through of the O-DU accelerator based at least in part on the O-DU accelerator not supporting a channel associated with the third message; and interpreting, at the O-DU application, the third message that does not utilize the O-DU accelerator.

[0187] Aspect 19: An apparatus for wireless communication in a device, comprising: a processor; a memory coupled to the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to perform a method according to one or more of aspects 1 to 18.

[0188] Aspect 20: A device for wireless communication, comprising: a memory; and one or more processors coupled to the memory, wherein the one or more processors are configured to perform a method as recited in one or more of aspects 1 to 18.

[0189] Aspect 21: An apparatus for wireless communication, comprising at least one means for performing the method recited in one or more of aspects 1 to 18.

[0190] Aspect 22: A non-transitory computer-readable medium storing code for wireless communication, the code comprising instructions executable by a processor to perform a method as recited in one or more of aspects 1 to 18.

[0191] Aspect 23: A non-transitory computer-readable medium storing a set of instructions for wireless communication, the set of instructions including one or more instructions that, when executed by one or more processors of a device, cause the device to perform a method described in one or more of aspects 1 to 18.

[0192] The above disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the embodiments.

[0193] As used herein, the term "component" shall be broadly construed as hardware and / or a combination of hardware and software. "Software" shall be broadly construed to mean, among other examples, instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, and / or functions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. As used herein, a "processor" is implemented in hardware and / or a combination of hardware and software. It will be apparent that the systems and / or methods described herein can be implemented in different forms of hardware and / or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not a limiting aspect. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, as those skilled in the art will understand that software and hardware can be designed to implement the systems and / or methods based at least in part on the description herein.

[0194] As used herein, "meeting a threshold" can refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, etc., depending on the context.

[0195] Although particular combinations of features are recited in the claims and / or disclosed herein, those combinations do not limit the disclosure of the various aspects. Many of these features may be combined in ways not specifically recited in the claims and / or disclosed herein. The disclosure of the various aspects includes each dependent claim in combination with any other claim in the claim set. As used herein, a phrase referring to "at least one of" a list of items refers to any combination of those items, including single members. As an example, "at least one of a, b, or c" is intended to include a, b, c, a+b, a+c, b+c, and a+b+c, as well as any combination having multiple identical elements (e.g., a+a, a+a+a, a+a+b, a+a+c, a+b+b, a+c+c, b+b, b+b+b, b+b+c, c+c, and c+c+c, or any other order of a, b, and c).

[0196] No element, act, or instruction used herein should be construed as critical or essential unless expressly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Additionally, as used herein, the article "the" is intended to include one or more items referred to in relation to the article "the" and may be used interchangeably with "one or more." Additionally, as used herein, the terms "set" and "group" are intended to include one or more items and may be used interchangeably with "one or more." When only one item is intended, the phrase "only one" or similar language is used. Also, as used herein, terms such as "has," "have," and "having" are intended to be open-ended terms that do not limit the elements they modify (e.g., an element that "has" A can also have B). Additionally, the phrase "based on" is intended to mean "based at least in part on," unless otherwise specified. Also, as used in this specification, the term "or" is intended to be inclusive when used in a consecutive manner, and may be used interchangeably with "and / or" unless otherwise stated (e.g., when used in combination with "either" or "only one of").

Claims

1. 1. An apparatus for wireless communication in an Open Radio Access Network (O-RAN) Distributed Unit (O-DU), comprising: Memory and one or more processors coupled to the memory; wherein the one or more processors: generating, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of the O-DU that is inline with the O-DU application; sending the first message from the O-DU application to an O-RAN radio unit (O-RU) via a pass-through of the O-DU accelerator, wherein the first message does not utilize the O-DU accelerator based at least in part on a payload of the first message being forwarded to the O-RU without modification by the O-DU accelerator; The apparatus is configured to:

2. To transmit the first message through the pass-through of the O-DU accelerator, the one or more processors:

2. The apparatus of claim 1, configured in the O-DU accelerator to embed the payload of the first message over a transport interface toward the O-RU, the first message indicating compression of beam weights, in-phase and quadrature (I / Q) samples, or other parameters describing a wireless channel associated with the O-DU.

3. the one or more processors: generating, at the O-DU accelerator, a second message based at least in part on a functional application platform interface between the O-DU accelerator and the O-DU application, wherein the second message is generated via hardware acceleration at the O-DU accelerator; and transmitting the second message from the O-DU accelerator to the O-RU, preferably the first message is a control plane message and the second message is a control plane message or a user plane message; or The first message is associated with a beam weight that is implicitly known to the O-RU, indicating that the first message is to pass through the O-DU accelerator, the beam weight being implicitly known to the O-RU based at least in part on semi-static configuration, dynamic configuration, or dynamic implicit generation at the O-RU from a precoder instruction from the O-DU; and the second message is associated with information generated by the O-DU accelerator, including dynamically generated information for use in a message from the O-DU to the O-RU, at least one in-phase and quadrature (I / Q) sample for use in the message from the O-DU to the O-RU, or at least one parameter signaling the result of accelerator-based decoding when an I / Q sample is received from the O-RU.

10. The apparatus of claim 1.

4. the one or more processors: Initiating signaling between the O-DU application and the O-DU accelerator to negotiate the types of messages that will pass through the O-DU accelerator and the types of messages that will be hardware accelerated at the O-DU accelerator; or supporting a plurality of channels, wherein the first message is associated with a channel included in the plurality of channels; The apparatus of claim 1 , further configured to:

5. the one or more processors: Initiating signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with the fragmentation or reassembly to be performed by the O-DU application or the O-DU accelerator; or 2. The apparatus of claim 1, further configured to initiate signaling between the O-DU application and the O-DU accelerator to negotiate parameters associated with compression or decompression to be performed by the O-DU application or the O-DU accelerator.

6. the one or more processors: In the O-DU application, generating or interpreting section or header information for a second message that does not pass through the O-DU accelerator; or 2. The apparatus of claim 1, further configured to, at the O-DU accelerator, generate or interpret the section or header information for the second message based at least in part on input received from the O-DU application.

7. the one or more processors: generating a second message in the O-DU application; 2. The apparatus of claim 1, further configured to: transmit the second message from the O-DU application to the O-RU via the pass-through of the O-DU accelerator based at least in part on the O-DU accelerator not supporting a channel associated with the second message.

8. the one or more processors:

2. The device of claim 1, further configured to initiate or terminate management plane signaling with a management plane entity associated with the O-RU, in a management plane entity associated with the O-DU application, the management plane signaling being associated with O-RU initialization, O-RU discovery, or O-RU orchestration, the management plane entity being present in the O-DU application and assisted by a management plane helper present in the O-DU accelerator.

9. 2. The apparatus of claim 1, wherein a first message generated in the O-DU application is coordinated with a second message generated in the O-DU accelerator in terms of time and frequency mapping to data frames, beam indexes, or spatial streams.

10. the one or more processors: signaling by the O-DU application of a location where the O-DU accelerator generates or expects in-phase and quadrature (I / Q) samples, beam weights, beam indices, channel estimates, or decoded data, the location being associated with a first message or memory location generated by the application; signaling by the O-DU application of the I / Q samples, the beam weights, the beam index, the channel estimates, the decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or signaling by the O-DU application of a second type of message associated with a control plane message to be used by the O-DU accelerator for generating or interpreting a first type of message associated with a control plane message and a user plane message; 10. The apparatus of claim 1, configured to transmit the first message through the pass-through of the O-DU accelerator based at least in part on one of:

11. the one or more processors: receiving a third message from the O-RU at the O-DU application via the pass-through of the O-DU accelerator; The apparatus of claim 1 , configured to interpret the third message in the O-DU application without utilizing the O-DU accelerator.

12. the one or more processors: receiving a fourth message from the O-RU at the O-DU accelerator; The O-DU accelerator is further configured to interpret the fourth message based at least in part on a functional application platform interface between the O-DU accelerator and the O-DU application, and the fourth message is subject to hardware acceleration in the O-DU accelerator, preferably: the one or more processors are configured to extract a payload of the third message at the O-DU accelerator to receive the third message via the pass-through of the O-DU accelerator, where the third message indicates decompression of beam weights, in-phase and quadrature (I / Q) samples, or other parameters describing a wireless channel associated with the O-DU; or The apparatus of claim 11 , wherein the first message and the second message are associated with an O-DU transmission message, and the third message and the fourth message are associated with an O-DU reception message.

13. the one or more processors: receiving the third message from the O-RU at the O-DU application via the pass-through of the O-DU accelerator based at least in part on the O-DU accelerator not supporting a channel associated with the third message; The apparatus of claim 1 , further configured to, in the O-DU application, interpret the third message that does not utilize the O-DU accelerator.

14. 1. A method of wireless communication performed by an Open Radio Access Network (O-RAN) Distributed Unit (O-DU), comprising: generating, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of the O-DU that is inline with the O-DU application; and transmitting the first message from the O-DU application to an O-RAN radio unit (O-RU) via a pass-through of the O-DU accelerator, wherein the first message does not utilize the O-DU accelerator based at least in part on the payload of the first message being forwarded to the O-RU without modification by the O-DU accelerator.

15. 1. A non-transitory computer-readable storage medium storing a set of instructions for wireless communication, the set of instructions including one or more instructions: The one or more instructions, when executed by one or more processors of an Open Radio Access Network (O-RAN) Distributed Unit (O-DU), cause the O-DU to: generating, in an O-DU application running on the O-DU, a first message that does not utilize an O-DU accelerator of the O-DU that is inline with the O-DU application; and transmitting the first message from the O-DU application to an O-RAN radio unit (O-RU) via a pass-through of the O-DU accelerator, the first message not utilizing the O-DU accelerator, based at least in part on a payload of the first message being forwarded to the O-RU without modification by the O-DU accelerator.

Images