Passthrough of messages in an accelerator of a distributed unit

Abstract

In summary, the various embodiments of this application relate to wireless communication. In some embodiments, an Open Radio Access Network (O-RAN) Distributed Unit (O-DU) can generate a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent with the O-DU application. The O-DU can 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, wherein the first message is transmitted to the O-RU at least in part based on its payload without being altered by the O-DU accelerator. Numerous other embodiments are provided.

Description

[Technical Field]

[0001] In general, the contents of this case relate to wireless communication, and specifically to the technology and apparatus for passthrough of messages in accelerators for distributed units. [Previous Technology]

[0002] Wireless communication systems are widely deployed to provide various telecommunications services such as telephone, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiplexing access technologies that support communication with multiple users by sharing available system resources (e.g., bandwidth, transmission power). Examples of such multiplexing access technologies include Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), and Long Term Evolution (LTE). LTE / LTE-Enhanced is an enhancement set of the Universal Mobile Telecommunications System (UMTS) mobile service standard released by the 3rd Generation Partnership Project (3GPP).

[0003] The wireless network may include one or more base stations supporting communications for one or more user equipment (UE). The UE may communicate with the base station via downlink communications and uplink communications. "Downlink" (or "DL") refers to the communication link from the base station to the UE, and "uplink" (or "UL") refers to the communication link from the UE to the base station.

[0004] The above multiplexing access technologies have been adopted in various telecommunications standards to provide a common protocol that enables different UEs to communicate at the city, country, region, and / or global levels. New Radio (NR) (which may be referred to as 5G) is an enhancement set of the LTE mobile service standard released by 3GPP. NR is designed to better integrate with other open standards by improving spectrum efficiency, reducing costs, improving service, utilizing new spectrum, and using Orthogonal Frequency Division Multiplexing (OFDM) with Cyclic Prefix (CP) on the downlink and CP-OFDM and / or Single Carrier Frequency Division Multiplexing (SC-FDM) (also known as Discrete Fourier Transform Extended OFDM (DFT-s-OFDM)) on the uplink, as well as supporting beamforming, multiple-input multiple-output (MIMO) antenna technology, and carrier aggregation, thereby better supporting mobile broadband internet access. As the demand for mobile broadband access continues to grow, further improvements to LTE, NR, and other radio access technologies remain useful. [Summary of the Invention]

[0005] In some implementations, an apparatus for wireless communication at an Open Radio Access Network (O-RAN) distributed unit (O-DU) includes a memory and one or more processors coupled to the memory, the one or more processors being configured to: generate a first message at an O-DU application executing on the O-DU, the first message not utilizing an O-DU accelerator consistent 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 passthrough of the O-DU accelerator, wherein the first message is transmitted to the O-RU at least in part based on the payload of the first message without being altered by the O-DU accelerator and without utilizing the O-DU accelerator.

[0006] In some implementations, a method of wireless communication performed by an O-DU includes the following steps: generating a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent with the O-DU application; and transmitting the first message from the O-DU application to an O-RU via a passthrough of the O-DU accelerator, wherein the first message is transmitted to the O-RU at least in part based on the payload of the first message without being altered by the O-DU accelerator and without utilizing the O-DU accelerator.

[0007] In some implementations, a non-transitory computer-readable medium storing an instruction set for wireless communication includes one or more instructions that, when executed by one or more processors of the O-DU, cause the O-DU to: generate a first message at an O-DU application executing on the O-DU, the first message not utilizing an O-DU accelerator consistent with the O-DU application; and transmit the first message from the O-DU application to the O-RU via a passthrough of the O-DU accelerator, wherein the first message is transmitted to the O-RU at least in part based on the payload of the first message without being altered by the O-DU accelerator and without utilizing the O-DU accelerator.

[0008] In some implementations, an apparatus for wireless communication includes: means for generating a first message at an application running on the apparatus, the first message not utilizing an accelerator of the apparatus consistent with the application; and means for transmitting the first message from the application to an O-RU via a pass-through of the accelerator, wherein the first message is transmitted to the O-RU at least in part based on the payload of the first message without being altered by the accelerator and without utilizing the accelerator.

[0009] Generally speaking, the various types include methods, apparatuses, 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 the accompanying drawings and description.

[0010] The foregoing has provided a fairly broad overview of the features and technical advantages of examples based on the content of this application, in order to better understand the following detailed description. Additional features and advantages will be described below. The disclosed concepts and specific examples can be readily used as the basis for modifying or designing other structures for achieving the same purpose as the content of this application. Such equivalent constructions do not depart from the scope of the appended claims. The characteristics of the concepts disclosed herein (both their organization and operation) and the associated advantages will be better understood when considered in conjunction with the accompanying drawings, based on the following description. Each of the accompanying drawings is provided for illustrative and descriptive purposes and is not intended to define or limit the claims.

[0011] Although various forms have been described in this document by way of examples, those skilled in the art will understand that such forms can be implemented in many different arrangements and scenarios. The techniques described herein can be implemented using different platform types, devices, systems, shapes, sizes, and / or package arrangements. For example, some forms can be implemented via integrated chip embodiments or other devices based on non-modular components (e.g., end-user devices, vehicles, communication devices, computing devices, industrial devices, retail / purchasing devices, medical devices, and / or artificial intelligence devices). Forms 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 forms and features may include additional elements and features for the implementation and enforcement of the claimed and described forms. For example, the transmission and reception of wireless signals may include one or more elements (e.g., hardware elements including antennas, radio frequency (RF) chains, power amplifiers, modulators, buffers, processors, interleavers, adders, and / or summers) for analog and digital purposes. It is intended that the various embodiments described herein can be implemented in a variety of devices, elements, systems, distributed arrangements, and / or end-user equipment with different sizes, shapes, and constructions.

Implementation Method

[0022] The various forms of the present invention are described more fully below with reference to the accompanying drawings. However, the present invention can be embodied in many different forms and should not be construed as limited to any particular structure or function presented throughout the present invention. Rather, these forms are provided so that the present invention will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art. Those skilled in the art should understand that the scope of the present invention is intended to cover any form of the present invention disclosed herein, whether that form is implemented independently of any other form of the present invention or in combination with any other form. For example, an apparatus or a method can be implemented using any number of forms set forth herein. Furthermore, the scope of the present invention is intended to cover such an apparatus or method implemented using structures, functions, or structures and functions other than or different from the various forms of the present invention set forth herein. It should be understood that any form of the present invention disclosed herein can be embodied by one or more elements of the claim.

[0023] Various devices and techniques will now be used to provide several embodiments of a telecommunications system. These devices and techniques will be described in detail below and illustrated in the accompanying drawings, in the form of various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as "elements"). These elements can be implemented using hardware, software, or a combination thereof. Whether such an element is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0024] Although this document may use terms commonly associated with 5G or New Radio (NR) Radio Access Technology (RAT) to describe the various forms, the various forms of the content herein may be applied to other RATs, such as 3G RAT, 4G RAT and / or RATs after 5G (e.g., 6G).

[0025] Figure 1 is a schematic diagram illustrating an example of a wireless network 100 according to the present invention. The wireless network 100 may be or may include elements of a 5G (e.g., NR) network and / or a 4G (e.g., Long Term Evolution (LTE)) network, as well as other examples. The wireless network 100 may include one or more base stations 110 (shown as BS 110a, BS 110b, BS 110c, and BS 110d), one 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. The base station 110 is the entity that communicates with the UE 120. Base station 110 (sometimes referred to as BS) 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 transport receiving points (TRPs). Each base station 110 can provide communication coverage for a specific geographic area. In the 3GPP, the term "cell" may represent the coverage area of ​​base station 110 and / or the base station subsystem serving that coverage area, depending on the context in which the term is used.

[0026] Base station 110 can provide communication coverage for macrocells, picocells, femtocells, and / or another type of cell. Macrocells can cover a relatively large geographic area (e.g., a radius of several kilometers) and can allow unrestricted access by UE 120 with a service subscription. Picocells can cover a relatively small geographic area and can allow unrestricted access by UE 120 with a service subscription. Femtocells can cover a relatively small geographic area (e.g., a residential area) and can allow restricted access by UE 120 associated with that femtocell (e.g., UE 120 in a Closed Subscriber Group (CSG)). Base station 110 for macrocells can be referred to as a macro base station. Base station 110 for picocells can be referred to as a pico base station. Base station 110 for femtocells can be referred to as a femto base station or a home base station. In the example illustrated in Figure 1, BS 110a can be a macro base station for macro cells 102a, BS 110b can be a pico base station for pico cells 102b, and BS 110c can be a femto base station for femto cells 102c. The base station can support one or more (e.g., three) cells.

[0027] In some embodiments, the term "base station" (e.g., base station 110) or "network entity" may refer to a converged base station, a decentralized base station, an integrated access and backhaul (IAB) node, a relay node, and / or one or more of its components. For example, in some embodiments, "base station" or "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 embodiments, the term "base station" or "network entity" may refer to a device configured to perform one or more functions (such as those described herein in conjunction with base station 110). In some embodiments, the term "base station" or "network entity" may refer to a plurality of devices configured to perform one or more functions. For example, in some distributed systems, each of multiple different devices (which may be located in the same geographical location or different geographical locations) can be configured to perform at least a portion of the functionality or replicate at least a portion of the functionality, and the terms "base station" or "network entity" can refer to any one or more of these different devices. In some configurations, the terms "base station" or "network entity" can refer to one or more virtual base stations and / or one or more virtual base station functions. For example, in some configurations, two or more base station functions can be created on a single device. In some configurations, the terms "base station" or "network entity" can refer to one base station function rather than another. In this way, a single device can include more than one base station.

[0028] In some instances, the cell may not be stationary, and the geographical area of ​​the cell may be movable depending on the location of the mobile base station 110 (e.g., the mobile base station). In some instances, base stations 110 may be interconnected with each other and / or with one or more other base stations 110 or network nodes (not shown) in the wireless network 100 via various types of backhaul interfaces (such as direct physical connections or virtual networks) using any suitable transport network.

[0029] Wireless network 100 may include one or more relay stations. A relay station is an entity that can receive data transmissions from an upstream station (e.g., base station 110 or UE 120) and send data transmissions to a downstream station (e.g., UE 120 or base station 110). A relay station may be a UE 120 capable of relaying transmissions for other UE 120s. In the example illustrated in Figure 1, BS 110d (e.g., a relay base station) can communicate with BS 110a (e.g., a macro base station) and UE 120d to facilitate communication between BS 110a and UE 120d. The base station 110 relaying the communication may be referred to as a relay station, relay base station, relay, etc.

[0030] The wireless network 100 may be a heterogeneous network comprising different types of base stations 110 (such as macro base stations, pico base stations, femto base stations, repeater base stations, etc.). These different types of base stations 110 may have different transmission power levels, different coverage areas, and / or different effects on interference in the wireless network 100. For example, macro base stations may have high transmission power levels (e.g., 5 to 40 watts), while pico base stations, femto base stations, and repeater base stations may have lower transmission power levels (e.g., 0.1 to 2 watts).

[0031] The network controller 130 can be coupled to or communicate with a group of base stations 110, and can provide coordination and control for such base stations 110. The network controller 130 can communicate with the base stations 110 via a backhaul communication link. The base stations 110 can communicate with each other directly or indirectly via wireless or wired backhaul communication links.

[0032] UE 120 may be distributed throughout the wireless network 100, and each UE 120 may be stationary or mobile. UE 120 may include, for example, access terminals, terminals, mobile stations, and / or user units. UE 120 may be a cellular phone (e.g., a smartphone), a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a wireless phone, a wireless loop (WLL) station, a tablet device, a camera, a gaming device, a laptop, a smart computer, an ultrabook, a medical device, a biometric device, a wearable device (e.g., a smartwatch, smart clothing, smart glasses, a smart wristband, smart jewelry (e.g., a smart ring or smart bracelet)), an entertainment device (e.g., a music device, a video device, and / or a satellite radio unit), a vehicle component or sensor, a smart instrument / sensor, industrial manufacturing equipment, a global positioning system device, and / or any other suitable device configured to communicate via wireless media.

[0033] Some UEs 120 may be considered Machine Type Communication (MTC) or Evolved or Enhanced Machine Type Communication (eMTC) UEs. MTC UEs and / or eMTC UEs may include, for example, robots, drones, remote devices, sensors, meters, monitors, and / or location tags, which can communicate with a base station, another device (e.g., a remote device), or some other entity. Some UEs 120 may be considered Internet of Things (IoT) devices and / or may be implemented as NB-IoT (Narrowband IoT) devices. Some UEs 120 may be considered customer premises equipment. UE 120 may be included within a housing that houses the components of UE 120, such as processor components and / or memory components. In some instances, processor components and memory components may be coupled together. For example, processor components (e.g., one or more processors) and memory components (e.g., memory) may be operatively coupled, communicatively coupled, electronically coupled, and / or electrically coupled.

[0034] Typically, any number of wireless networks 100 can be deployed in a given geographical area. Each wireless network 100 can support a specific RAT and can operate on one or more frequencies. A RAT can be referred to as a radio technology, air interface, etc. A frequency can be referred to as a carrier, channel, etc. Each frequency can support a single RAT in a given geographical area to avoid interference between wireless networks using different RATs. In some cases, NR or 5G RAT networks can be deployed.

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

[0036] Devices of the wireless network 100 can communicate using the electromagnetic spectrum, which can be subdivided into various categories, bands, channels, etc., according to frequency or wavelength. For example, devices of the wireless network 100 can communicate using one or more operating frequency bands. In 5G NR, two initial operating frequency bands have been identified as frequency range names FR1 (410 MHz–7.125 GHz) and FR2 (24.25 GHz–52.6 GHz). It should be understood that although a portion of FR1 is greater than 6 GHz, FR1 is often (interchangeably) referred to as the "below 6 GHz" band in various documents and articles. Similar naming issues sometimes arise regarding FR2; although FR2 is different from the extremely high frequency (EHF) band (30 GHz–300 GHz), it is often (interchangeably) referred to as the "millimeter wave" band in documents and articles, while the EHF band is identified as the "millimeter wave" band by the International Telecommunication Union (ITU).

[0037] The frequencies between FR1 and FR2 are often referred to as intermediate frequency (IF) frequencies. Recent 5G NR studies have identified the operating bands used for these IF frequencies as the frequency range name FR3 (7.125 GHz – 24.25 GHz). Bands falling within FR3 can inherit FR1 and / or FR2 characteristics, and thus can effectively extend the features of FR1 and / or FR2 to IF frequencies. Furthermore, higher frequency bands are currently being explored to extend 5G NR operation beyond 52.6 GHz. For example, three higher operating frequency bands have been identified as the frequency range names FR4-a or FR4-1 (52.6 GHz – 71 GHz), FR4 (52.6 GHz – 114.25 GHz), and FR5 (114.25 GHz – 300 GHz). Each of these higher frequency bands falls within the EHF band.

[0038] Considering the above examples, unless otherwise specifically stated, it should be understood that, as used herein, the term "below 6 GHz" can broadly refer to frequencies that are less than 6 GHz, within FR1, or may include intermediate frequency bands. Furthermore, unless otherwise specifically stated, it should be understood that, as used herein, the term "millimeter wave" can broadly refer to frequencies that may include intermediate frequency bands, within FR2, FR4, FR4-a, or FR4-1 and / or FR5, or within the EHF band. It is contemplated that the frequencies included in these operating frequency bands (e.g., FR1, FR2, FR3, FR4, FR4-a, FR4-1, and / or FR5) can be modified, and the techniques described herein are applicable to such modified frequency ranges.

[0039] In some embodiments, 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 may generate a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent 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 passthrough of the O-DU accelerator, wherein the first message is transmitted to the O-RU at least in part based on the payload of the first message without being altered by the O-DU accelerator and without utilizing the O-DU accelerator. Additionally or alternatively, the communications manager 150 may perform one or more other operations described herein.

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

[0041] Figure 2 is a schematic diagram illustrating an example 200 of communication between a base station 110 and a UE 120 in a wireless network 100 according to the present invention. The base station 110 may be equipped with a set of antennas 234a to 234t, such as T antennas (T≧1). The UE 120 may be equipped with a set of antennas 252a to 252r, such as R antennas (R≧1).

[0042] At base station 110, transmission processor 220 can receive data intended for UE 120 (or a set of UE 120) from data source 212. Transmission processor 220 can select one or more modulation and decoding schemes (MCS) for UE 120 based at least in part on one or more Channel Quality Indicators (CQIs) received from UE 120. Base station 110 can process (e.g., encode and modulate) the data for UE 120 and provide data symbols for UE 120 based at least in part on the MCS selected for UE 120. Transmission processor 220 can process system information (e.g., semi-static resource partitioning information (SRPI)) and control information (e.g., CQI requests, permission and / or upper-layer signaling), and provide management burden symbols and control symbols. The transmission processor 220 can generate reference symbols for reference signals (e.g., cell-specific reference signals (CRS) or demodulated reference signals (DMRS)) and synchronization signals (e.g., primary synchronization signal (PSS) or secondary synchronization signal (SSS)). The transmission (TX) multiple-input multiple-output (MIMO) processor 230 can perform spatial processing (e.g., precoding, if applicable) on data symbols, control symbols, administrative burden symbols, and / or reference symbols, and can provide a set of output symbol streams (e.g., T output symbol streams) to a set of corresponding data machines 232 (e.g., T data machines), shown as data machines 232a to 232t. For example, each output symbol stream can be provided to a modulator element (shown as MOD) of the data machine 232. Each data machine 232 can use a corresponding modulator element to process the corresponding output symbol stream (e.g., for OFDM) to obtain an output sample stream. Each modem 232 may also use a corresponding modulator element to process (e.g., convert to analog, amplify, filter, and / or upconvert) the output sampled stream to obtain a downlink signal. Modems 232a to 232t may transmit a set of downlink signals (e.g., T downlink signals) via a set of corresponding antennas 234 (e.g., T antennas) (shown as antennas 234a to 234t).

[0043] At UE 120, an array of antennas 252 (shown as antennas 252a to 252r) can receive downlink signals from base station 110 and / or other base stations 110, and can provide a set of received signals (e.g., R received signals) to an array of data terminals 254 (e.g., R data terminals) (shown as data terminals 254a to 254r). For example, each received signal can be provided to a demodulator element (shown as DEMOD) of data terminal 254. Each data terminal 254 can use a corresponding demodulator element to modulate (e.g., filter, amplify, downconvert, and / or digitize) the received signal to obtain an input sample. Each data terminal 254 can use a demodulator element to further process the input sample (e.g., for OFDM) to obtain a received symbol. MIMO detector 256 can obtain the received symbols from data terminal 254, can perform MIMO detection on the received symbols (if applicable), and can provide the detected symbols. The receiver processor 258 can process (e.g., demodulate and decode) the detected symbols, provide decoded data for the UE 120 to the data slot 260, and provide decoded control information and system information to the controller / processor 280. The term "controller / processor" can refer to one or more controllers, one or more processors, or a combination thereof. The channel processor can determine Reference Signal Received Power (RSRP) parameters, Received Signal Strength Indicator (RSSI) parameters, Reference Signal Received Quality (RSRQ) parameters, and / or CQI parameters, among others. In some instances, one or more components of the UE 120 may be included in the housing 284.

[0044] The network controller 130 may include a communication unit 294, a controller / processor 290, and a memory 292. The network controller 130 may include one or more devices, such as those in a core network. The network controller 130 may communicate with the base station 110 via the communication unit 294.

[0045] One or more antennas (e.g., antennas 234a to 234t and / or antennas 252a to 252r) may include or may be included in the following: one or more antenna panels, one or more antenna groups, one or more antenna element sets, and / or one or more antenna arrays, and other examples. Antenna panels, antenna groups, antenna element sets, and / or antenna arrays may include one or more antenna elements (within a single housing or multiple housings), coplanar antenna element sets, non-coplanar antenna element sets, and / or one or more antenna elements coupled to one or more transmitting and / or receiving elements (such as one or more elements of FIG. 2).

[0046] On the uplink, at UE 120, transmission processor 264 can receive and process data from data source 262 and control information from controller / processor 280 (e.g., for reporting RSRP, RSSI, RSRQ, and / or CQI). Transmission processor 264 can generate reference symbols for one or more reference signals. Symbols from transmission processor 264 can be pre-coded (if applicable) by TX MIMO processor 266, further processed by data unit 254 (e.g., for DFT-s-OFDM or CP-OFDM), and transmitted to base station 110. In some instances, data unit 254 of UE 120 may include modulators and demodulators. In some instances, UE 120 includes a transceiver. The transceiver may include any combination of antenna 252, data unit 254, MIMO detector 256, receiver processor 258, transmission processor 264, and / or TX MIMO processor 266. The transceiver may be used by a processor (e.g., controller / processor 280) and memory 282 to execute any of the methods described herein (e.g., see Figures 5-10).

[0047] At base station 110, uplink signals from UE 120 and / or other UEs can be received by antenna 234, processed by modem 232 (e.g., demodulator elements of modem 232, shown as DEMOD), detected by MIMO detector 236 (if applicable), and further processed by receiver processor 238 to obtain decoded data and control information transmitted by UE 120. Receiver processor 238 can provide decoded data to data slot 239 and decoded control information to controller / processor 240. Base station 110 may include communication unit 244 and can communicate with network controller 130 via communication unit 244. Base station 110 may include scheduler 246 to schedule one or more UEs 120 for downlink and / or uplink communication. In some instances, modem 232 of base station 110 may include modulator and demodulator. In some instances, base station 110 includes transceiver. The transceiver may include any combination of antenna 234, modem 232, MIMO detector 236, receiver processor 238, transmitter processor 220, and / or TX MIMO processor 230. The transceiver may be configured by a processor (e.g., controller / processor 240) and memory 242 to perform various methods of the methods described herein (e.g., see Figures 5-10).

[0048] The controller / processor 240 of base station 110, the controller / processor 280 of UE 120, and / or any other element in FIG. 2 may perform one or more techniques associated with the pass-through of messages in the accelerator of the distributed unit, as described in more detail elsewhere herein. In some cases, the O-DU described herein is base station 110, is included in base station 110, or includes one or more elements of base station 110 illustrated in FIG. 2. For example, the controller / processor 240 of base station 110, the controller / processor 280 of UE 120, and / or any other element in FIG. 2 may perform or direct the operation of, for example, process 900 of FIG. 9 and / or other processes as described herein. Memory 242 and memory 282 may store data and code for base station 110 and UE 120, respectively. In some instances, memory 242 and / or memory 282 may include non-transitory computer-readable media storing one or more instructions (e.g., code and / or program code) for wireless communication. For example, when executed by one or more processors of base station 110 and / or UE 120 (e.g., directly, or after compilation, translation, and / or interpretation), one or more instructions may cause one or more processors, UE 120, and / or base station 110 to perform or direct the operation of, for example, process 900 of FIG. 9 and / or other processes as described herein. In some instances, the execution instructions may include execution instructions, translation instructions, compilation instructions, and / or interpretation instructions, among others.

[0049] In some embodiments, the O-DU (e.g., base station 110) includes: means for generating a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent with the O-DU application; and / or means for transmitting the first message from the O-DU application to the O-RU via a passthrough of the O-DU accelerator, wherein the first message is transmitted to the O-RU at least in part based on the payload of the first message without being altered by the O-DU accelerator. In some embodiments, the means for the O-DU to perform the operations described herein may include, for example, one or more of a communication manager 150, a transmission processor 220, a TX MIMO processor 230, a modem 232, an antenna 234, a MIMO detector 236, a receiver processor 238, a controller / processor 240, a memory 242, or a scheduler 246.

[0050] Although the blocks in Figure 2 are shown as different elements, the functions described above with respect to these blocks can be implemented in a single hardware, software, or combined element, or in various combinations of elements. For example, the functions described with respect to the transmission processor 264, the reception processor 258, and / or the TX MIMO processor 266 can be executed by or under the control of the controller / processor 280.

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

[0052] Figure 3 is a schematic diagram of an example 300 of the O-RAN architecture according to the content of this case.

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

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

[0055] Therefore, DU 330 may correspond to a logic unit that includes one or more base station functions to control the operation of one or more RU 340s. For example, in some configurations, at least in part based on lower-layer function separation, DU 330 may host the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, and one or more high-level physical (PHY) layers (e.g., forward error correction (FEC) encoding and decoding, scrambling, and / or modulation and demodulation). Higher-level control functions (such as Packet Data Convergence Protocol (PDCP), Radio Resource Control (RRC), and / or Service Data Adaptation Protocol (SDAP)) may be hosted by CU 310. At least in part based on lower-layer function separation, RU 340 controlled by DU 330 may correspond to a logic node hosting RF processing functions and low-level PHY layer functions (e.g., Fast Fourier Transform (FFT), Inverse FFT (iFFT), Digital Beamforming, and / or Physical Random Access Channel (PRACH) extraction and filtering). Therefore, in the O-RAN architecture, RU 340 handles all over-the-air (OTA) communications with UE 120, and the real-time and non-real-time modes of control and user plane communications with RU 340 are controlled by the corresponding DU 330. This enables DU 330 and CU 310 to be implemented in a cloud-based RAN architecture.

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

[0057] Figure 4 is a schematic diagram illustrating an example 400 of the O-RAN architecture according to the content of this case.

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

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

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

[0061] The O-RAN fronthaul (FH) (OFH) can 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 can be associated with the control plane (C plane). The control plane can provide scheduling and beamforming commands, multiple numerical schemes, channel estimation to the O-RU, unauthorized access support, segment extension for updating beam weights, and / or discontinuous resource block patterns. The O-RAN FH can be associated with the user plane (U plane). The user plane can provide transmissions 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 can be associated with the synchronization plane, which can provide an overview of the protocols and mechanisms used to ensure timely delivery between the control plane and the user plane.

[0062] FAPI can be the interface between L2 / 3 and L1 in O-DU, while O-RAN FH can provide the connection between O-DU and O-RU. FAPI can be independent of O-RAN FH.

[0063] The O-DU can employ accelerators (e.g., hardware accelerators and associated libraries / drivers) to improve its performance. Accelerators can be implemented using FAPI to support interaction at the O-DU. Due to FAPI's limited understanding of the O-RAN FH (which can provide connectivity between the O-DU and O-RU), the accelerator may need to generate O-RAN FH messages for both the control plane and the user plane. However, the accelerator may be primarily valuable for user plane generation and decoding of in-phase and quadrature (I / Q) signals, or for beamforming weight generation in the control plane, and a particular O-DU implementation may not require accelerator assistance to generate other control plane messages or fields. Accelerators can use high-performance hardware that is less suited to complex data structures but may be well-suited for handling FH user plane messages (e.g., I / Q samples to and from the O-RU) or beamforming weights (e.g., complex-valued samples to and from the O-RU). Therefore, generating or receiving O-RAN FH messages for all control plane and user plane messages may not be as valuable as generating or receiving hardware-intensive messages that concentrate accelerators in the O-DU.

[0064] In various embodiments of the technologies and apparatus described herein, the O-DU can generate (or receive) control plane messages on an O-DU application running on the O-DU. The O-DU can transmit control plane messages between the O-DU application and the O-RU via a passthrough of an accelerator consistent with the O-DU application. The O-DU accelerator of the O-DU can be consistent between the O-DU application and the O-RU. Control plane messages can be transmitted via the O-DU's accelerator and may not be subject to hardware acceleration at the accelerator, except for possible transformations between the application message payload and the transmission medium. Such transformations may involve I / Q sampling, or beamforming weight compression or decompression, or the addition or removal of transmission adaptations. In other words, for a passthrough, the message payload can be fully generated or interpreted at the O-DU application, and the accelerator can at most participate in compression / decompression transformations.

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

[0066] In some configurations, certain control plane messages may not terminate at the O-DU accelerator, potentially increasing control plane transparency for the accelerator. Some control plane messages may be generated or received in the O-DU application, and these messages may be passed through the accelerator and exchanged with the O-RU. Passing through certain control plane messages can minimize bookkeeping at the accelerator and the number of transformations without any added value at the accelerator, thereby improving accelerator performance. Passing through certain control plane messages at the accelerator may result in additional cycles available at the accelerator for more high-value functions. Furthermore, the management plane may terminate primarily in the O-DU application, rather than at the accelerator. Therefore, FAPI exchange can be used in a manner that precisely extracts as many values ​​from the accelerator as are required by the O-DU application.

[0067] Figure 5 is a schematic diagram illustrating an example 500 of an accelerator pass-through associated with at least some control plane messages in the O-DU according to the contents of this case.

[0068] In some configurations, the O-DU can generate (or anticipate) control plane messages at an O-DU application running on the O-DU. The O-DU can transmit (or receive) control plane messages between the O-DU application and the O-RU via a passthrough of an accelerator (or O-DU accelerator) consistent with the O-DU application running on the O-DU. The O-DU accelerator of the O-DU can be consistent between the O-DU application and the O-RU. Control plane messages can be transmitted via the O-DU accelerator and may not be subject to hardware acceleration at the O-DU accelerator. In some configurations, the accelerator can support multiple channels, and control plane messages can be associated with channels included in the multiple channels.

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

[0070] In some configurations, control plane messages generated, partially or entirely, at the O-DU application executing on the O-DU may be associated (or coordinated) with at least one message payload generated at the O-DU's accelerator regarding time and frequency mapping to data frames, beam indexing and weighting (e.g., implicit or dynamic weighting), and / or spatial streaming. Implicit weighting refers to weights that can be calculated or known at the O-RU (e.g., due to prior semi-static configuration or dynamic signaling, or a shared understanding of channel and precoder selection between the O-DU and O-RU), without explicit signaling in the message payload under consideration itself.

[0071] In some configurations, the first control plane message may be associated with implicit beamweights, which may indicate that the first control plane message will be transmitted via the O-DU's accelerator. The implicit beamweights may be known or assumed at the O-DU application running on the O-DU. The second message (control plane or user plane message) may be associated with dynamic beamweights, which may indicate that the second message is not transparently transmitted via the O-DU's accelerator, wherein the dynamic beamweights may be generated at the O-DU's accelerator.

[0072] In some cases, the O-DU can initiate signal transmission between the O-DU application running on the O-DU and the O-DU accelerator to negotiate the types of messages to be transmitted via the O-DU accelerator and the types of messages not transmitted via the O-DU accelerator; in some cases, the type of message can be indicated by scope (e.g., user plane, control plane, or dynamic beamforming), controlled Uu direction (e.g., uplink or downlink), forward direction (e.g., upstream or downstream), channelization (e.g., physical downlink shared channel (PDSCH) or physical uplink shared channel (PUSCH)) or individual message identification (e.g., via segment, time slot, symbol, resource block (RB) or time, or other message identification or coupling methods). In some configurations, the O-DU can initiate signaling between the O-DU application running on the O-DU and the O-DU's accelerator to negotiate parameters associated with segmentation and compression to be performed by either the O-DU application or the O-DU's accelerator. In some configurations, the O-DU can initiate management plane signaling at a management plane entity associated with the O-RU at a management plane entity associated with the O-DU application running on the O-DU, where management plane signaling can be associated with O-RU initialization, exploration, or orchestration. In other configurations, the management plane entity can be associated with O-DU initialization, exploration, or orchestration.

[0073] In some forms, the O-DU may generate (or receive expected) segment and header information for a message to be transmitted via the O-DU's accelerator without hardware acceleration at an O-DU application running on the O-DU. Alternatively, the O-DU may generate segment and header information for a message at the O-DU's accelerator, at least in part, based on input received from the O-DU application running on the O-DU.

[0074] In some configurations, the O-DU may generate or anticipate user or control plane messages at the O-DU application running on the O-DU. The O-DU may transmit user plane messages from the O-DU application to the O-RU via pass-through of the O-DU accelerator, at least in part, based on the fact that the O-DU accelerator does not support channels associated with user plane messages.

[0075] In some embodiments, the O-DU may generate a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent with the O-DU application. The O-DU 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 may be transmitted to the O-RU without utilizing the O-DU accelerator, at least in part, based on the payload of the first message without being altered by the O-DU accelerator. The O-DU may generate a second message via hardware acceleration of the O-DU accelerator, at least in part, based on the FAPI between the O-DU accelerator and the O-DU application. The O-DU may transmit the second message from the O-DU accelerator to the O-RU. In some embodiments, the first message may be a control plane message, and the second message may be a control plane message or a user plane message.

[0076] In some embodiments, the O-DU can receive a third message from the O-RU via a direct pass-through of the O-DU accelerator at the O-DU application. The O-DU can interpret the third message without utilizing the O-DU accelerator at the O-DU application. The O-DU can receive a fourth message from the O-RU at the O-DU accelerator. The O-DU can interpret the fourth message at the O-DU accelerator at least in part based on the functional application platform interface between the O-DU accelerator and the O-DU application, wherein the fourth message may be subject to hardware acceleration at the O-DU accelerator. In some embodiments, the first and second messages can be associated with messages transmitted by the O-DU, and the third and fourth messages can be associated with messages received by the O-DU.

[0077] In some cases, the first and third messages may be accelerator-independent messages, which may be generated or interpreted at the O-DU application and can be transparently transmitted via the O-DU accelerator. The second and fourth messages may be accelerator-related messages or accelerator-aware messages, which may require at least one parameter (e.g., beam weight or I / Q sampling or decoded sampling) to be generated or interpreted by the O-DU accelerator.

[0078] In some configurations, the O-DU can support a plurality of channels, and the first, second, third, and fourth messages can be associated with one or more of the channels included in the plurality of channels. In some configurations, the first message generated at the O-DU application can be coordinated with the second message generated at the O-DU accelerator regarding the time and frequency mapping, beam indexing, or spatial streaming to the data frame, and similarly, the third message interpreted at the O-DU application can be coordinated with the fourth message interpreted at the O-DU accelerator.

[0079] In some embodiments, for pass-through transmission of a first message via an O-DU accelerator, the O-DU may embed the payload of the first message at the O-DU accelerator via a transmission interface toward the O-RU, wherein the first message may indicate beamweight compression, I / Q sampling, or other parameters describing the radio channel associated with the O-DU. In some embodiments, for pass-through reception of a third message via an O-DU accelerator, the O-DU may extract the payload of the third message at the O-DU accelerator, wherein the third message may indicate beamweight decompression, I / Q sampling, or other parameters describing the radio channel associated with the O-DU. In other words, pass-through may only relate to the message payload, and the O-DU accelerator may still be involved in minimal processing, such as transferring the message payload to the transport layer or compressing / decompressing the beamforming weights. Other parameters describing the radio channel may relate to information summarizing or describing the radio channel (Uu) or sampling on the radio channel (e.g., channel modeling or estimation parameters).

[0080] In some configurations, the first message may be associated with beam weights implicitly known to the O-RU, which indicate that the first message will be transmitted via the O-DU accelerator. The O-RU may implicitly know the beam weights at the O-RU based at least in part on a semi-static configuration, a dynamic configuration, or based on dynamic implicit generation at the O-RU according to precoder instructions from the O-DU. The O-RU may implicitly know the beam weights at the O-RU based at least in part on a previous semi-static configuration, a previous (dynamic explicit) signal transmission, or based on dynamic implicit generation at the O-RU according to precoder instructions (e.g., layer indexes) from the O-DU. The second message may be associated with information generated by the O-DU accelerator, including: dynamically generated information to be used in the O-DU to O-RU message, at least one I / Q sample to be used in the O-DU to O-RU message, or at least one parameter signaled as a result of accelerator-based decoding when I / Q samples are received from the O-RU. The information generated by the accelerator may include: at least one dynamically generated information to be used in O-DU to O-RU fronthaul messages (e.g., via the control plane), at least one I / O sample to be used in O-DU to O-RU fronthaul messages (e.g., via the user plane), or at least one parameter signaling the result of accelerator-based decoding in the case of receiving I / Q samples from the fronthaul.

[0081] In some embodiments, the O-DU can initiate signal transmission between the O-DU application and the O-DU accelerator to negotiate the type of message to be transmitted via the O-DU accelerator and the type of message to be hardware-accelerated at the O-DU accelerator. In some embodiments, the O-DU can initiate signal transmission between the O-DU application and the O-DU accelerator to negotiate parameters associated with segmentation or assembly to be performed by the O-DU application or the O-DU accelerator. In some embodiments, the O-DU can initiate signal transmission 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.

[0082] In some embodiments, the O-DU may generate (or interpret) segment or header information for a second message transmitted via the O-DU accelerator without hardware acceleration at the O-DU application. In some embodiments, the O-DU may generate or interpret segment or header information for the second message at the O-DU accelerator based at least in part on input received from the O-DU application.

[0083] In some configurations, the O-DU can generate a second message at the O-DU application. The O-DU can transmit the second message from the O-DU application to the O-RU via a passthrough of the O-DU accelerator, at least in part, based on the fact that the O-DU accelerator does not support the channel associated with the second message. In some configurations, the O-DU can receive a third message at the O-DU application via a passthrough of the O-DU accelerator, at least in part, based on the fact that the O-DU accelerator does not support the channel associated with the third message. The O-DU can interpret the third message that does not utilize the O-DU accelerator at the O-DU application.

[0084] In some configurations, the O-DU can initiate management plane signaling of the management plane entity associated with the O-RU at the management plane entity associated with the O-DU application, wherein the management plane signaling can be associated with O-RU initialization, O-RU exploration or O-RU orchestration.

[0085] In some configurations, the O-DU can at least partially transmit a first message via the O-DU accelerator based on a location signaled by the O-DU application, at which the O-DU accelerator generates or anticipates I / Q sampling, beam weights, beam indices, channel estimates, or decoded data, wherein the location may be associated with a first message generated by the application or a memory location. In other words, the O-DU accelerator can generate I / Q / beam / channel estimate samples at a memory location without knowing how the O-DU application encapsulates that location with other message fields. In some configurations, the O-DU can at least partially transmit a first message via the O-DU accelerator based on I / Q sampling, beam weights, beam indices, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator, signaled by the O-DU application. In other words, an O-DU accelerator can generate both I / Q / beam / CE sampling and message header / parameters, at least in part, based on the FAPI abstraction. In some cases, the O-DU can be at least in part based on a second type of message, signaled by the O-DU application to the O-DU accelerator for generating or interpreting a first type of message, transmitted via a pass-through of the O-DU accelerator. The second type of message can be associated with control plane messages, and the first type of message can be associated with both control plane messages and user plane messages.

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

[0087] Figure 6 is a schematic diagram illustrating an example 600 of an accelerator pass-through associated with control plane information in the O-DU according to the contents of this case.

[0088] In some cases, similar to Figure 5, the message from O-DU to O-RU is illustrated, but the message terminated at O-DU may also be passed through the accelerator or processed by the accelerator.

[0089] In some configurations, the O-DU can execute an O-DU application that can be associated with the MAC layer. At the O-DU, the MAC implementation may include some OFH control plane functions. The O-DU application can communicate with the O-DU's accelerator via FAPI. The accelerator may include a hardware accelerator. The application can utilize associated libraries / drivers to communicate with the accelerator. The accelerator may be a high-PHY layer inline accelerator. The O-DU can communicate with the O-RU, which may be associated with a low-PHY layer. Since the accelerator may be located between the O-DU application and the O-RU, the accelerator may be inline. In some configurations, the accelerator may generate or anticipate control plane messages and user plane messages at least partially based on the FAPI between the accelerator and the O-DU application, and the control plane messages and user plane messages may be transmitted to or received from the O-RU. In other words, the control plane messages and user plane messages generated or anticipated at the accelerator may be subject to hardware acceleration at the accelerator. Control plane messages can be OFH control plane messages. In some cases, certain control plane messages may be generated or anticipated at the O-DU application. These control plane messages may be transmitted via an accelerator and subsequently transmitted to or received from an O-RU. In other words, these control plane messages transmitted via an accelerator may not be subject to hardware acceleration at the accelerator. This can improve accelerator performance because many control plane messages are not well-suited for acceleration and unnecessarily consume cycles at the accelerator, which could be used for other high-value functions.

[0090] In some configurations, the O-DU application and the accelerator can negotiate which messages are enabled for pass-through (e.g., which control plane messages are transmitted via the accelerator and are not hardware-accelerated) and which messages are not enabled for pass-through (e.g., which control plane messages are generated at the accelerator and are hardware-accelerated). The O-DU application can communicate with the accelerator to negotiate which messages have pass-through enabled.

[0091] In some configurations, the accelerator can provide a pass-through path for messages between the O-DU application and the O-RU. This pass-through path allows messages to pass directly through the accelerator. In some configurations, although the accelerator does not perform hardware acceleration on the messages, it may perform other functions for the messages. For example, the accelerator may be responsible for the Enhanced Common Public Radio Interface (eCPRI) header of the messages. As another example, the accelerator may be responsible for compressing or decompressing sampled or weighted values ​​in the messages. As yet another example, the accelerator may be responsible for segmenting / splitting / aggregating the messages at the transition point with the fronthaul transmission.

[0092] In some configurations, the passed-through message may include various segment identifiers indicating corresponding resources, and the segment identifiers may be referenced in non-direct communication messages. Segment identifier management may involve having consistent segment identifiers between control plane messages and user plane messages. The O-DU application may be responsible for segment identifier processing for control plane messages transmitted via the accelerator. The O-DU application may also be responsible for segment identifier processing for control plane and / or user plane messages not transmitted via the accelerator (e.g., non-direct communication messages), enabling the O-DU application to provide the accelerator with segment identifiers for such non-direct communication messages.

[0093] In some configurations, the accelerator can be applied to multiple channels and / or signal transmissions, including PDSCH, PDSCH DMRS, Physical Downlink Control Channel (PDCCH), PDCCH DMRS, Physical Broadcast Channel (PBCH), PSS / SSS PBCH DMRS, Channel Status Information Reference Signal (CSI-RS), Phase Tracking Reference Signal (PT-RS), and / or Tracking Reference Signal (TRS). In some configurations, the accelerator can 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 instances, the accelerator can support specific channels and / or signals.

[0094] In some configurations, pass-through of control plane messages via the accelerator can be advantageous in bypassing the generation or interpretation of FAPI messages (e.g., FAPI P19) used for interfacing between the O-DU application and the front-end unit associated with the accelerator, where the front-end unit functionality can be at least partially managed by the O-RU. The FAPI P19 interface can be used for analog beamforming. Since the P19 interface does not directly affect the baseband associated with the accelerator, the O-DU application can directly send OFH control plane messages that bypass the baseband associated with the accelerator, and thus bypass the need to terminate FAPI P19 at the O-DU accelerator. In some configurations, pass-through of control plane messages via the accelerator may be advantageous for control plane messages with segment type 0, which can signal empty resource blocks. For empty resource blocks, user plane messages may not be sent, and the accelerator may not add any values. In this case, such control plane messages may benefit from being transmitted via the accelerator. In one scenario, the accelerator can be instructed to avoid generating or interpreting samples for empty resource blocks. In another scenario, the recipient of an OFH message associated with an empty resource block can be instructed or programmed to ignore samples associated with such an empty resource block.

[0095] In some configurations, control plane messages generated by the O-DU application can be coordinated or coupled with user plane messages generated by the accelerator. Since in a pass-through approach, control plane messages and user plane messages may be generated by different entities (e.g., the accelerator may be used to transmit some control plane messages, while user plane control messages may be generated at the O-DU application), a common understanding of certain FH allocation dimensions (or allocation abstractions) may be required. FH allocation dimensions may include time and frequency mappings to data frames, which may be necessary for the O-DU to generate and interpret user plane messages. Furthermore, FH allocation dimensions may include beam management decisions performed at the O-DU application and beam management of the accelerator regarding control plane messages and user plane messages. Additionally, FH allocation dimensions may include spatial beam management related to control plane messages and user plane messages. A common understanding of FH allocation dimensions may enable the pass-through approach when control plane messages and user plane messages are generated by different entities.

[0096] In some embodiments, the accelerator (e.g., MAC / PHY interface) may support a PHY layer that generates user plane messages for only at least one channel, while an O-DU application (e.g., MAC layer) may generate control plane messages for that channel. In some embodiments, the accelerator and O-DU application may have the ability to negotiate which control plane messages will be transmitted via the accelerator. The O-DU application may generate beam weights (e.g., beam weights generated by the DU) for different control plane messages, wherein control plane messages associated with implicit beam weights may be transmitted via the accelerator, and control plane messages for dynamic weights may be signaled not to be transmitted via the accelerator. In some embodiments, the accelerator and O-DU application may negotiate per-channel control plane generation (e.g., the channel for which control plane messages are generated). The accelerator and O-DU application may negotiate per-channel user plane generation (e.g., the channel for which user plane messages are generated). In some configurations, the accelerator and O-DU application can negotiate, at least in part, whether the accelerator or the O-DU application will process the data segments based on the maximum frame size. In other configurations, the accelerator and O-DU application can negotiate parameters associated with the compression to be performed at the accelerator or the O-DU application.

[0097] In some configurations, for messages that are not direct communication messages and whose beam weights are at least partially based on the DU-generated beam weights, the generation of segments and headers for the message can be handled by the O-DU application or the accelerator. Each message may include segment and header information. In some configurations, the O-DU application can generate the segment and header information for the message. Alternatively, the accelerator can generate the segment and header information for the message based at least partially on input received from the O-DU application. In other words, in this case, the O-DU application can provide input to assist the accelerator in generating the segment and header information.

[0098] In some embodiments, for the pass-through of control plane messages, signaling of the allocation abstraction (or FH allocation dimension) from the O-DU application to the accelerator (or higher PHY layer) can be supported. This allocation abstraction signaling can be associated with the separate management of frequency and time mappings, beam indices (e.g., implicit weights generated by the O-DU application or dynamic weights generated by the accelerator), and / or extended antenna carrier (eAxC) mappings for multiple RU categories. The allocation abstraction signaling enables the accelerator to generate or interpret messages associated with control plane messages generated by the O-DU application regarding the separate management of frequency and time mappings, beam indices, and eAxC mappings for multiple RU categories. In some embodiments, the allocation abstraction signaling can enable the generation of FAPI data structures, which allow the accelerator to generate / receive user plane I / Q samples and beam weights in a manner desired by the FH. In some configurations, the allocation of abstract signaling allows the accelerator to have optional connections between the FAPI channel and the associated control plane components and couplings, directly via control plane messages. In some configurations, the allocation of abstract signaling enables the accelerator to write / get I / Q samples to a shared memory location, which can be located between the O-DU and O-RU. In specific instances, the shared memory location can be located between the O-DU / O-RU FH eCPRI transport and the accelerator module. In some configurations, the allocation of abstract signaling enables the concatenation or interpretation of application-generated message headers, header parameters, or application-indicated header parameters with message segments used to generate or interpret I / Q samples or weights at the accelerator.

[0099] In some configurations, the signal delivery of the allocation abstraction may include rate matching association, where the MAC layer can identify overlaps between PDSCH allocations and other channels, thereby enabling the generation of segment priority information. The signal delivery of the allocation abstraction may include beamforming and precoding information, such as information about the precoder, beam, and / or weights. The signal delivery of the allocation abstraction may include eAxCS mapping, where the MAC layer can identify various spatial streams.

[0100] In some cases, the set of FAPI hard-coded or explicit capabilities can indicate limitations associated with frequency and time mappings, separate management of beam indices, and eAxCS mappings for multiple RU categories. For example, such limitations can be associated with the shape of frequency and time regions, resource element patterns, the type of coupling supported by O-RAN, the number of abstractions per channel, where specific abstractions are mapped to entity resource blocks (PRBs) and symbol allocation and / or supported extension types.

[0101] In some configurations, for non-direct communication channels, FAPI can update inputs / outputs other than the MAC transport block (TB), such as modulated symbols, coded character bits, or code block bits or modulation symbols. Depending on the inputs / outputs, some FAPI parameter values ​​may become "irrelevant" values.

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

[0103] Figure 7 is a schematic diagram illustrating an example 700 of an accelerator pass-through associated with control plane information and user plane information in an O-DU according to the contents of this case.

[0104] In some cases, similar to Figure 5, the message from O-DU to O-RU is illustrated, but the message terminated at O-DU may also be passed through the accelerator or processed by the accelerator.

[0105] In some configurations, the O-DU can execute an O-DU application that can be associated with the MAC layer. The O-DU application can communicate with the O-DU's accelerator via 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 can communicate with the O-RU, which may be associated with a low-PHY layer. Since the accelerator may be located between the O-DU application and the O-RU, the accelerator may be inline. In some configurations, the accelerator may generate control plane messages and user plane messages at least in part based 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 at the accelerator may be subject to hardware acceleration at the accelerator. The control plane messages may be OFH control plane messages. In some configurations, some control plane messages and some user plane messages may be generated at the O-DU application. These control plane and user plane messages can be transmitted via the accelerator and subsequently transferred to the O-RU. In other words, these control plane and user plane messages transmitted via the accelerator may not be subject to hardware acceleration at the accelerator, which can improve the accelerator's performance.

[0106] In some embodiments, for accelerators that do not support certain channels, passthrough may apply to both user plane messages and control plane messages. For example, for accelerators that do not support PDCCH, or for applications that choose not to utilize hardware acceleration via PDCCH, user plane messages may also be passed through the accelerator. In some embodiments, the FAPI between the O-DU application and the accelerator can be used for the accelerated function (because such control plane messages and user plane messages are hardware accelerated at the accelerator), while user plane messages and / or control plane messages can be used for other functions via passthrough through the accelerator. In some other embodiments, the accelerated function may be a functional block that makes up a specific channel (e.g., low-density isotope check (LDPC) coding), but does not include some functions processed by the application layer (e.g., modulation). In this latter case, FAPI functionality may be limited to controlling parameters of the accelerated blocks, and may be enhanced to define the inputs and outputs of the accelerated blocks, particularly when the output of an accelerated block is not the input of a subsequent accelerated block or a transition to / from an OFH transfer.

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

[0108] Figure 8 is a schematic diagram illustrating an example 800 associated with the management plane architecture in O-DU according to the content of this case.

[0109] In some configurations, the O-DU can execute an O-DU application. The O-DU application can communicate with the O-DU's accelerator via 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 can communicate with the 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 within the O-DU application. The management plane may reside within the O-DU application and may be assisted by a management plane assistant that may reside within the accelerator. In other words, the management plane may not terminate within the accelerator, but the accelerator may include a management plane assistant to assist the management plane within the O-DU application. In some configurations, the management plane within the O-DU application can communicate with the management plane within the O-RU. Management plane functionality may involve O-RU initialization, exploration, and / or orchestration. In addition, management plane functions can involve pooling accelerator resources so that O-RUs can be switched from one accelerator to another under certain circumstances.

[0110] In some cases, assistance may involve at least part of the conversion between O-RAN management plane O-DU or O-RU parameters and equivalent FAPI P5 or P19 configuration or capability parameters. The conversion may also involve the transfer of capability and / or configuration parameters between O-DUs and O-RUs, such as those required for consistent configuration and capability awareness between application / accelerator interfaces and O-DU / O-RU interfaces.

[0111] In some configurations, the management plane can be terminated in the O-DU application (or MAC layer), where relevant parameters can be reflected in the FAPI operation. These parameters may not include the control plane segment number. In some configurations, the O-DU application can interpret the management plane but not the control plane. Furthermore, the relevant parameters can be associated with a semi-static FAPI configuration that reflects the channels configured for the management plane.

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

[0113] In some cases, control plane messages generated at the O-DU application and user plane messages generated at the accelerator can be coordinated or coupled, at least in part, based on a shared understanding of certain FH allocation dimensions. The user plane can be associated with frequency domain I / Q sampling and data at the resource block and symbol levels. The control plane can be associated with data-related controls (e.g., scheduling and beamforming). One or more control plane segment types may be required to interpret / control the I / Q sampling within a single user plane message for a given eAxC.

[0114] In some configurations, for FAPI, the Channel Protocol Data Unit (PDU) can be associated with a time and frequency mapping per time slot and a set of spatial streams. For the I / Q sample set, the control plane can define the RB or resource element (RE) and symbol mapping of the I / Q samples in the user plane message, where the user plane message can be associated with a spatial stream (e.g., an eAxC identifier).

[0115] In some configurations, regarding the decoupling of control plane messages and user plane messages, the accelerator (or PHY layer) can generate I / Q samples as expected by the O-RU. The accelerator can skip blank PRBs and / or assign I / Q samples to the correct data frame identifiers, ensuring proper encapsulation of the I / Q samples. As a decoupling assumption, channel PDUs can be mapped to a single user plane frame per symbol, where the O-RAN user plane allocation can be rectangular (e.g., time and frequency per time slot). In some cases, to support decoupling, O-RAN user plane frames can aggregate I / Q samples from multiple channels, where channels may be split into multiple O-RAN user plane frames.

[0116] In some forms, the allocation of I / Q data frames in a time slot can be represented as a rectangular resource allocation pattern with PRB and symbol resolution, a bit map of excluded PRB and symbols, a deterministic rule for generating I / Q samples, a rule for zero-filled I / Q samples that are not explicitly excluded, and / or an I / Q sampling compression scheme, wherein the data frames may be irregular in shape.

[0117] In some configurations, analog and digital beam management can be separate, where digital beams can be associated with channel PDUs and analog beams can be associated with symbols (or time slots) and subbands. Beam management can involve correctly filling beam indices and weights in appropriate control plane segments. Precoder / beam indices and / or precoder weights can be controlled by the MAC layer. The accelerator can generate dynamic precoder weights based at least in part on indexing in the MAC layer, where the MAC layer causes the accelerator to generate a control plane template, and the accelerator can fill the calculated beam weights in the control plane template. The accelerator can also fill beam indices from reserved ranges (signaled by the MAC layer). In some configurations, in hybrid beamforming, analog beams can be signaled to the accelerator, and analog beams may not be transparent, and FAPI may need to update analog beamforming entries that can be transmitted to the O-RU via the control plane in real time.

[0118] In some configurations, I / Q data frames can be associated with O-RAN beam indices, which can correspond to FAPI precoder indices and / or beams or combinations. I / Q data frames can be the basic units used for abstracting allocation dimensions, and can be associated with rectangular PRBs and symbol sets, as well as RE modes and eAxC identifier sets. Furthermore, each PRB or the entire rectangular set can be associated with a beam index set, where each beam maps to an eAxC identifier.

[0119] In some configurations, regarding segment and header management, the O-DU application (or MAC layer) can notify the accelerator (or PHY layer) of the segment identifier to be associated with the user plane data frame. The data frame header can be added to the I / Q samples (or user plane samples) generated by the accelerator (or PHY), for example, in shared memory or via serialization.

[0120] In some cases, abstraction can involve shared memory locations. The abstraction can correspond to a structure for each spatial stream indicator symbol identifier, starting PRB, total number of PRBs, compression scheme, and / or shared memory location. For downlink, the accelerator can place I / Q samples in the shared memory location. For uplink, the accelerator can extract I / Q samples from the shared memory location. For uplink, a triggering mechanism (e.g., events or arrival windows) may be needed to determine when valid I / Q samples are available. In this case, the O-DU application (or MAC layer) can handle segmentation and eAxC identifier mapping. However, the shared memory location approach may not be advantageous for interfaces that do not share memory.

[0121] In some configurations, the RE mapping abstraction can be transmitted as a control plane message (or segment), which can be interpreted by the accelerator. Each FAPI type allocation can be linked to a control plane segment signaling the RE resulting from the allocation, a user plane segment for storing the RE, and / or a coupling type. "Coupled type" can refer to coupling via segment, coupling via frequency and time, or coupling via frequency and time with priority. In this case, fewer FAPI updates may be required. However, the accelerator (or the O-DU high-PHY layer) may need to interpret the control plane structure, which could increase complexity at the accelerator.

[0122] In some configurations, the coupling between the control plane and the user plane can be at least partially based on segment identifiers and via frequency and time, allowing for the assumption of coordination between the control plane and the user plane. Decoupling may be required to allow control plane pass-through. Decoupling can be achieved via user plane templates and / or capability coordination. The user plane template can be a reserved location for user plane segments. The O-DU application can be responsible for generating the user plane template at least partially based on channel-to-user plane template multiplexing.

[0123] In some configurations, regarding FAPI capabilities, the O-DU may indicate, via signal notification, the O-DU's ability to support pass-through operation. The O-DU may indicate any limitations regarding whether it supports beam weights generated by the DU, and applicable compression techniques and resolutions (e.g., segment or per PRB). The O-DU may indicate any limitations regarding the channels it supports for control plane pass-through. The O-DU may indicate any limitations regarding the channels it supports for user plane pass-through (e.g., compression for hardware acceleration). The O-DU may indicate any limitations regarding support for various FH segment extension types (such as when the abstraction is signaled in FH format).

[0124] Figure 9 is a schematic diagram illustrating an exemplary process 900 performed, for example, by an O-DU according to the content of this case. The exemplary process 900 is an example in which an O-DU (e.g., base station 110) performs an operation associated with the pass-through of messages in the accelerator of a distributed unit.

[0125] As shown in FIG9, in some versions, process 900 may include: generating a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent with the O-DU application (block 910). For example, the O-DU (e.g., using the communication manager 150 and / or generating element 1008 illustrated in FIG10) may generate the first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent with the O-DU application, as described above.

[0126] As further shown in FIG9, in some embodiments, process 900 may include: transmitting a first message from an O-DU application to an O-RU via a passthrough of the O-DU accelerator, wherein the first message is transmitted to the O-RU based at least in part on the payload of the first message without being altered by the O-DU accelerator (block 920). For example, an O-DU (e.g., using the communication manager 150 and / or transmission element 1004 illustrated in FIG10) may transmit a first message from an O-DU application to an O-RU via a passthrough of the O-DU accelerator, wherein the first message is transmitted to the O-RU based at least in part on the payload of the first message without being altered by the O-DU accelerator, as described above.

[0127] Process 900 may include additional patterns, such as any single pattern or any combination of patterns described below and / or in conjunction with one or more other processes described elsewhere herein.

[0128] In the first state, process 900 includes: embedding a payload of a first message at the O-DU accelerator via a transmission interface toward the O-RU, wherein the first message indicates beam weight compression, I / Q sampling, or other parameters describing the radio channel associated with the O-DU.

[0129] In the second state, either alone or in combination with the first state, process 900 includes: generating a second 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, 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.

[0130] In the third state, either alone or in combination with one or more states of the first and second states, the first message is a control plane message, and the second message is a control plane message or a user plane message.

[0131] In the fourth state sample, either alone or in combination with one or more of the first to third state samples, the first message is associated with beam weights implicitly known to the O-RU, which indicate that the first message will be transmitted via the O-DU accelerator, wherein the O-RU knows the beam weights at least in part based on a semi-static configuration, a dynamic configuration, or based on dynamic implicit generation at the O-RU according to a precoder instruction from the O-DU, and the second message is associated with information generated by the O-DU accelerator, which includes: dynamically generated information to be used in the O-DU to O-RU message, at least one I / Q sample to be used in the O-DU to O-RU message, or at least one parameter signaled as a result of accelerator-based decoding when an I / Q sample is received from the O-RU.

[0132] In the fifth state sample, either alone or in combination with one or more states from the first to the fourth state samples, process 900 includes: initiating a signal transmission between the O-DU application and the O-DU accelerator to negotiate the type of message to be transmitted via the O-DU accelerator and the type of message to be hardware accelerated at the O-DU accelerator.

[0133] In the sixth state sample, either alone or in combination with one or more states from the first to the fifth state samples, process 900 includes: supporting a plurality of channels, and the first message being associated with a channel included in the plurality of channels.

[0134] In the seventh state sample, either alone or in combination with one or more of the first to sixth state samples, process 900 includes: initiating a signal transmission between the O-DU application and the O-DU accelerator to negotiate parameters associated with segmentation or assembly to be performed by the O-DU application or the O-DU accelerator; or initiating a signal transmission 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.

[0135] In the eighth state sample, either alone or in combination with one or more of the first to seventh state samples, process 900 includes: generating or interpreting segment or header information for a second message not transmitted via the O-DU accelerator at the O-DU application; or generating or interpreting segment or header information for the second message at the O-DU accelerator based at least in part on input received from the O-DU application.

[0136] In the ninth state, either alone or in combination with one or more states from the first to the eighth state, process 900 includes: generating a second message at the O-DU application; and transmitting the second message from the O-DU application to the O-RU via passthrough of the O-DU accelerator, at least in part, based on the fact that the O-DU accelerator does not support the channel associated with the second message.

[0137] In the tenth state sample, either alone or in combination with one or more states from the first to the ninth state samples, process 900 includes: initiating or terminating management plane signaling of the management plane entity associated with the O-DU application and the management plane entity associated with the O-RU, wherein the management plane signaling is associated with O-RU initialization, O-RU exploration or O-RU orchestration, and wherein the management plane entity is located in the O-DU application and is assisted by a management plane assistant located in the O-DU accelerator.

[0138] In the eleventh state, the first message generated at the O-DU application, either alone or in combination with one or more of the first to tenth state samples, is coordinated with the second message generated at the O-DU accelerator regarding the time and frequency mapping, beam indexing, or spatial streaming to the data frame.

[0139] In the twelfth state, the direct transmission of the first message via the O-DU accelerator, either alone or in combination with one or more of the first to eleventh states, is based at least in part on one of the following: the O-DU application signals locations at which the O-DU accelerator generates or anticipates I / Q sampling, beam weights, beam indices, channel estimates, or decoded data, wherein these locations are associated with the first message or memory locations generated by the application; the O-DU application signals I / Q sampling, beam weights, beam indices, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or the O-DU application signals a second type of message to be used by the O-DU accelerator to generate or interpret the first type of message, wherein the second type of message is associated with control plane messages, and the first type of message is associated with control plane messages and user plane messages.

[0140] In the thirteenth state sample, either alone or in combination with one or more states from the first to the twelfth state samples, process 900 includes: receiving a third message from the O-RU via a pass-through of the O-DU accelerator at the O-DU application; and interpreting the third message that does not utilize the O-DU accelerator at the O-DU application.

[0141] In the fourteenth state, either alone or in combination with one or more states from the first to the thirteenth states, 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 at least in part based on the functional application platform interface between the O-DU accelerator and the O-DU application, wherein the fourth message is subject to hardware acceleration at the O-DU accelerator.

[0142] In the fifteenth state sample, receiving the third message directly via the O-DU accelerator, either alone or in combination with one or more of the first to fourteenth state samples, includes: extracting the payload of the third message at the O-DU accelerator, wherein the third message indicates the decompression of beam weights, I / Q sampling, or other parameters describing the radio channel associated with the O-DU.

[0143] In the sixteenth state, either alone or in combination with one or more states from the first to the fifteenth state, the first message and the second message are associated with messages transmitted by the O-DU, and the third message and the fourth message are associated with messages received by the O-DU.

[0144] In the seventeenth state, either alone or in combination with one or more states from the first to the sixteenth states, process 900 includes: receiving a third message from the O-RU via a passthrough of the O-DU accelerator at the O-DU application, at least in part, based on the fact that the O-DU accelerator does not support a channel associated with the third message; and interpreting the third message that does not utilize the O-DU accelerator at the O-DU application.

[0145] Although FIG9 illustrates exemplary blocks of process 900, in some versions, process 900 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently compared to those illustrated in FIG9. Alternatively, two or more blocks of process 900 may be executed in parallel.

[0146] FIG10 is a schematic diagram of an exemplary device 1000 for wireless communication. Device 1000 may be an O-DU, or an O-DU may include device 1000. In some embodiments, device 1000 includes a receiving element 1002 and a transmitting element 1004, which may communicate with each other (e.g., via one or more buses and / or one or more other elements). As shown, device 1000 may use the receiving element 1002 and the transmitting element 1004 to communicate with another device 1006 (such as a UE, a base station, or another wireless communication device). As further illustrated, device 1000 may include a communication manager 150. Communication manager 150 may include one or more of a generating element 1008 or an initiating element 1010, and other instances thereof.

[0147] In some embodiments, device 1000 may be configured to perform one or more operations described herein in conjunction with Figures 5-8. Alternatively, device 1000 may be configured to perform one or more processes described herein, such as process 900 of Figure 9. In some embodiments, device 1000 and / or one or more elements shown in Figure 10 may include one or more elements of the O-DU described in conjunction with Figure 2. Alternatively, one or more elements shown in Figure 10 may be implemented within one or more elements described in conjunction with Figure 2. Alternatively, one or more elements in the set of elements may be implemented at least partially as software stored in memory. For example, an element (or a portion of an element) 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 element.

[0148] Receiver 1002 may receive communications from device 1006, such as reference signals, control information, data communications, or combinations thereof. Receiver 1002 may provide the received communications to one or more other elements of device 1000. In some embodiments, receiver 1002 may perform signal processing on the received communications (such as filtering, amplification, demodulation, analog-to-digital conversion, demultiplexing, deinterleaving, demapping, equalization, interference cancellation, or decoding, and other instances), and may provide the processed signal to one or more other elements of device 1000. In some embodiments, receiver 1002 may include one or more antennas, modems, demodulators, MIMO detectors, receiver processors, controllers / processors, memory, or combinations thereof, as described in conjunction with FIG2 for the O-DU.

[0149] Transmission element 1004 can transmit communications, such as reference signals, control information, data communications, or combinations thereof, to device 1006. In some embodiments, one or more other elements of device 1000 can generate communications and provide the generated communications to transmission element 1004 for transmission to device 1006. In some embodiments, transmission element 1004 can perform signal processing (such as filtering, amplification, modulation, digital-to-analog conversion, multiplexing, interleaving, mapping, or encoding, and other instances) on the generated communications and can transmit the processed signals to device 1006. In some embodiments, transmission element 1004 may include one or more antennas, modems, modulators, transmission MIMO processors, transmission processors, controllers / processors, memory, or combinations thereof, as described in conjunction with FIG. 2 for the O-DU. In some embodiments, transmission element 1004 may be co-located with receiving element 1002 in a transceiver.

[0150] Generating element 1008 can generate a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent with the O-DU application. Transmission element 1004 can transmit the first message from the O-DU application to the O-RU via a pass-through of the O-DU accelerator, wherein the first message is transmitted to the O-RU at least in part based on the payload of the first message without being altered by the O-DU accelerator and without utilizing the O-DU accelerator.

[0151] The transmission element 1004 can embed the payload of a first message at the O-DU accelerator via a transmission interface toward the O-RU, wherein the first message indicates beam weight compression, I / Q sampling, or other parameters describing the radio channel associated with the O-DU.

[0152] The generating element 1008 can generate a second message at the O-DU accelerator at least in part based on the functional application platform interface between the O-DU accelerator and the O-DU application, wherein the second message is hardware-accelerated at the O-DU accelerator. The transmitting element 1004 can transmit the second message from the O-DU accelerator to the O-RU.

[0153] The initiation element 1010 can initiate signal transmission between the O-DU application and the O-DU accelerator to negotiate the type of message to be transmitted via the O-DU accelerator and the type of message to be hardware-accelerated at the O-DU accelerator. The initiation element 1010 can initiate signal transmission between the O-DU application and the O-DU accelerator to negotiate parameters associated with segmentation or assembly to be performed by the O-DU application or the O-DU accelerator; or initiate signal transmission 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.

[0154] Generating element 1008 can generate or interpret segment or header information for second messages not transmitted via the O-DU accelerator at the O-DU application. Generating element 1008 can generate or interpret segment or header information for second messages not transmitted via the O-DU accelerator at the O-DU application.

[0155] Generating element 1008 can generate a second message at the O-DU application. Transmission element 1004 can transmit the second message from the O-DU application to the O-RU via a passthrough of the O-DU accelerator, at least in part, based on the fact that the O-DU accelerator does not support the channel associated with the second message.

[0156] The initiation element 1010 can initiate management plane signal transmission at the management plane entity associated with the O-DU application and the management plane entity associated with the O-RU, wherein the management plane signal transmission is associated with O-RU initialization, O-RU exploration or O-RU orchestration, and wherein the management plane entity is located in the O-DU application and is assisted by a management plane assistant located in the O-DU accelerator.

[0157] The transmission element 1004 may transmit the first message via the O-DU accelerator at least in part based on one of the following: the O-DU application signals locations at which the O-DU accelerator generates or anticipates in-phase and quadrature (I / Q) sampling, beam weights, beam indices, channel estimates, or decoded data, wherein such locations are associated with the first message or memory locations generated by the application; the O-DU application signals I / Q sampling, beam weights, beam indices, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or the O-DU application signals a second type of message to be used by the O-DU accelerator to generate or interpret the first type of message, wherein the second type of message is associated with control plane messages, and wherein the first type of message is associated with both control plane messages and user plane messages.

[0158] The receiving element 1002 can receive third messages from the O-RU via the O-DU accelerator through the O-DU application; and interpret third messages that do not utilize the O-DU accelerator in the O-DU application.

[0159] The receiving element 1002 can receive the fourth message from the O-RU at the O-DU accelerator; and interpret the fourth message at the O-DU accelerator at least in part based on the functional application platform interface between the O-DU accelerator and the O-DU application, wherein the fourth message is hardware accelerated at the O-DU accelerator.

[0160] The receiving element 1002 can extract the payload of a third message at the O-DU accelerator, wherein the third message indicates the decompression of beam weights, in-phase and quadrature (I / Q) sampling, or describes other parameters of the radio channel associated with the O-DU.

[0161] The receiving element 1002 can receive the third message from the O-RU via the O-DU accelerator passthrough at least in part at the O-DU application based on the fact that the O-DU accelerator does not support the channel associated with the third message; and interpret the third message that does not utilize the O-DU accelerator at the O-DU application.

[0162] The number and arrangement of elements shown in FIG10 are provided as examples. In practice, there may be additional elements, fewer elements, different elements, or elements arranged differently compared to those shown in FIG10. Furthermore, two or more elements shown in FIG10 may be implemented within a single element, or a single element shown in FIG10 may be implemented as multiple distributed elements. Alternatively or additionally, a group (one or more) of elements shown in FIG10 may perform one or more functions described as being performed by another group of elements shown in FIG10.

[0163] Figure 11 is a schematic diagram illustrating an example 1100 of a decomposed base station architecture according to the content of this case.

[0164] The deployment of communication systems (such as 5G NR systems) can be arranged in a variety of ways using various components or parts. In a 5G NR system or network, network nodes, network entities, network mobility elements, RAN nodes, core network nodes, network elements, or network equipment (such as base stations (BS, e.g., base station 110) or one or more units (or one or more elements) performing base station functions) can be implemented in aggregated or decomposed architectures. For example, BSs (such as node B (NB), eNB, NR BS, 5G NB, access point (AP), TRP, cell, etc.) can be implemented as aggregated base stations (also known as standalone BS or monolithic BS) or decomposed base stations.

[0165] Aggregated base stations can be configured to utilize radio protocol stacks that are physically or logically integrated within a single RAN node. Decomposed base stations can be configured to utilize protocol stacks that are physically or logically distributed among two or more units (such as one or more CUs, one or more DUs, or one or more RUs). In some configurations, the CU can be implemented within a RAN node, and one or more DUs can be co-located with the CU, or alternatively, they can be geographically or virtually distributed across one or more other RAN nodes. The DU can be implemented to communicate with one or more RUs. Each of the CU, DU, and RU can also be implemented as a virtual unit (e.g., a Virtual Centralized Unit (VCU), a Virtual Distributed Unit (VDU), or a Virtual Radio Unit (VRU)).

[0166] Base station type operation or network design can consider the aggregation characteristics of base station functions. For example, decomposed base stations can be utilized in IAB networks, O-RAN (such as network configurations sponsored by the O-RAN Consortium), or virtualized radio access networks (vRAN, also known as cloud radio access networks (C-RAN)). Decomposition can include allocating functions across two or more units at various physical locations, as well as virtually allocating functions to at least one unit, which allows for flexibility in network design. The individual units of a decomposed base station or the decomposed RAN architecture can be configured for wired or wireless communication with at least one other unit.

[0167] The decomposed base station architecture illustrated in Figure 11 may include one or more CUs 1110, which may communicate directly with the core network 1120 via a backhaul link, or indirectly with the core network 1120 via one or more decomposed base station units (such as near-RT RICs 1125 via E2 links, or non-RT RICs 1115 associated with the Service Management and Orchestration (SMO) framework 1105, or both). CUs 1110 may communicate with one or more DUs 1130 via appropriate midrange links such as F1 interfaces. DUs 1130 may communicate with one or more RUs 1140 via appropriate fronthaul links. RUs 1140 may communicate with corresponding 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.

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

[0169] In some configurations, CU 1110 may host one or more higher-level control functions. Such control functions may include RRC, PDCP, SDAP, etc. Each control function may be implemented using an interface configured to transmit signals with other control functions hosted by CU 1110. 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 combinations thereof. In some implementations, CU 1110 may be logically separated into one or more CU-UP units and one or more CU-CP units. CU-UP units may communicate bidirectionally with CU-CP units via an interface (such as an E1 interface when implemented in an O-RAN configuration). Where necessary, CU 1110 may be implemented to communicate with DU 1130 for network control and signaling.

[0170] DU 1130 may correspond to a logic unit that includes one or more base station functions to control the operation of one or more RU 1140s. In some configurations, DU 1130 may, at least in part, host one or more of the RLC layer, MAC layer, and one or more high PHY layers (such as modules for FEC encoding and decoding, scrambling, modulation and demodulation, etc.) depending on functional separation (such as the separation of other functions as defined by 3GPP). In some configurations, DU 1130 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to transmit signals with other layers (and modules) hosted by DU 1130 or control functions hosted by CU 1110.

[0171] Lower-layer functions can be implemented by one or more RU 1140s. In some deployments, based at least in part on functional separation (such as lower-layer function separation), the RU 1140 controlled by the DU 1130 can correspond to a logical node for managed 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. In this architecture, the RU 1140 can be implemented to handle over-the-air (OTA) communications with one or more UE 120s. In some implementations, the real-time and non-real-time modes of control and user plane communications with the RU 1140 can be controlled by the corresponding DU 1130. In some scenarios, this configuration allows the DU 1130 and CU 1110 to be implemented in a cloud-based RAN architecture (such as a vRAN architecture).

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

[0173] The non-RT RIC 1115 can be configured to include logical 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 can be coupled to or communicate with the near-RT RIC 1125 (e.g., via an A1 interface). The near-RT RIC 1125 can be configured to include logical functions that enable near-real-time control and optimization of RAN elements and resources via data collection and actions through an interface (e.g., via an E2 interface) connecting one or more CU 1110s, one or more DU 1130s, or both, and O-eNBs to the near-RT RIC 1125.

[0174] In some implementations, in order to generate AI / ML models to be deployed in the near-RT RIC 1125, the non-RT RIC 1115 can receive parameters or external rich information from an external server. This information can be utilized by the near-RT RIC 1125 and can be received from non-network data sources or from network functions at the SMO framework 1105 or the non-RT RIC 1115. In some instances, the non-RT RIC 1115 or the near-RT RIC 1125 can be configured to tune RAN behavior or performance. For example, the non-RT RIC 1115 can monitor long-term trends and patterns of performance and, via the SMO framework 1105 (such as via O1 reconfiguration) or by establishing RAN management policies (such as A1 policies), employ AI / ML models to perform corrective actions.

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

[0176] The following provides a summary of some aspects of the case:

[0177] Form 1: A method of wireless communication performed by an Open Radio Access Network (O-RAN) Distributed Unit (O-DU), comprising the steps of: generating a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator consistent 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 passthrough of the O-DU accelerator, wherein the first message is transmitted to the O-RU at least in part based on the payload of the first message without being altered by the O-DU accelerator and without utilizing the O-DU accelerator.

[0178] State 2: According to the method of State 1, the direct transmission of the first message via the O-DU accelerator also includes: embedding the payload of the first message at the O-DU accelerator via a transmission interface toward the O-RU, wherein the first message indicates beam weight compression, in-phase and quadrature (I / Q) sampling or describes other parameters of the radio channel associated with the O-DU.

[0179] State 3: The method according to any one of States 1 to 2 also includes the following steps: generating a second message at the O-DU accelerator based at least in part on the 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.

[0180] State 4: According to the method of State 3, wherein the first message is a control plane message, and wherein the second message is a control plane message or a user plane message.

[0181] State 5: According to the method of State 3, wherein the first message is associated with beam weights implicitly known to the O-RU, the beam weights indicating that the first message will be transmitted via the O-DU accelerator, wherein the O-RU knows the beam weights implicitly at the O-RU based at least in part on a semi-static configuration, a dynamic configuration, or based on a precoder instruction from the O-DU indicating dynamic implicit generation at the O-RU; and the second message is associated with information generated by the O-DU accelerator, the information generated by the O-DU accelerator including: dynamically generated information to be used in the O-DU to O-RU message, at least one in-phase and quadrature (I / Q) sampling to be used in the O-DU to O-RU message, or signaling at least one parameter of the result of accelerator-based decoding when receiving I / Q sampling from the O-RU.

[0182] State 6: The method according to any one of States 1 to 5 also includes the following steps: initiating signal transmission between the O-DU application and the O-DU accelerator to negotiate the type of message to be transmitted via the O-DU accelerator and the type of message to be hardware accelerated at the O-DU accelerator.

[0183] State 7: The method according to any one of states 1 to 6 also includes the following steps: supporting a plurality of channels, and the first message being associated with a channel included in the plurality of channels.

[0184] State 8: The method according to any one of states 1 to 7 also includes the following steps: initiating a signal transmission between the O-DU application and the O-DU accelerator to negotiate parameters associated with segmentation or assembly to be performed by the O-DU application or the O-DU accelerator; or initiating a signal transmission 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.

[0185] State 9: The method according to any one of states 1 to 8 also includes the following steps: generating or interpreting segment or header information for a second message not transmitted via the O-DU accelerator at the O-DU application; or generating or interpreting the segment or header information for the second message at the O-DU accelerator based at least in part on input received from the O-DU application.

[0186] State 10: The method according to any one of States 1 to 9 also includes the steps of: generating a second message at the O-DU application; and transmitting the second message from the O-DU application to the O-RU via the passthrough of the O-DU accelerator, at least in part, based on the fact that the O-DU accelerator does not support the channel associated with the second message.

[0187] State 11: The method according to any one of States 1 to 10 also includes the following steps: initiating or terminating management plane signal transmission of the management plane entity associated with the O-DU application and the management plane entity associated with the O-RU, wherein the management plane signal transmission is associated with O-RU initialization, O-RU exploration or O-RU orchestration, and wherein the management plane entity is located in the O-DU application and is assisted by a management plane assistant located in the O-DU accelerator.

[0188] State 12: According to the method of any one of states 1 to 11, wherein the first message generated at the O-DU application is coordinated with the second message generated at the O-DU accelerator regarding the time and frequency mapping, beam indexing or spatial streaming to the data frame.

[0189] State 13: According to any one of States 1 to 12, the direct transmission of the first message via the O-DU accelerator is based at least in part on one of the following: the O-DU application signals locations at which the O-DU accelerator generates or anticipates in-phase and quadrature (I / Q) sampling, beam weights, beam indices, channel estimates, or decoded data, wherein these locations are associated with the first message or memory locations generated by the application; the O-DU application signals the I / Q sampling, beam weights, beam indices, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or the O-DU application signals a second type of message to be used by the O-DU accelerator to generate or interpret a first type of message, wherein the second type of message is associated with control plane messages, and wherein the first type of message is associated with control plane messages and user plane messages.

[0190] State 14: The method according to any one of States 1 to 13 also includes the following steps: receiving a third message from the O-RU via the passthrough of the O-DU accelerator at the O-DU application; and interpreting the third message that does not utilize the O-DU accelerator at the O-DU application.

[0191] State 15: The method according to State 14 also includes the following steps: receiving a fourth message from the O-RU at the O-DU accelerator; and interpreting the fourth message at the O-DU accelerator at least in part based on the functional application platform interface between the O-DU accelerator and the O-DU application, wherein the fourth message is subject to hardware acceleration at the O-DU accelerator.

[0192] State 16: According to the method of State 14, the direct reception of the third message via the O-DU accelerator includes: extracting the payload of the third message at the O-DU accelerator, wherein the third message indicates decompression of beam weights, in-phase and quadrature (I / Q) sampling or describes other parameters of the radio channel associated with the O-DU.

[0193] State 17: According to the method of State 16, wherein: the first message and the second message are associated with messages transmitted by the O-DU; and the third message and the fourth message are associated with messages received by the O-DU.

[0194] State 18: The method according to any one of states 1 to 17 also includes the following steps: receiving the third message from the O-RU via the O-DU accelerator at least in part at the O-DU application based on the fact that the O-DU accelerator does not support the channel associated with the third message; and interpreting the third message that does not utilize the O-DU accelerator at the O-DU application.

[0195] State 19: An apparatus for wireless communication at 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 device to perform a method according to one or more states 1-18.

[0196] State 20: A device for wireless communication, including a memory and one or more processors coupled to the memory, the one or more processors being configured to perform a method according to one or more states 1-18.

[0197] Format 21: An apparatus for wireless communication, comprising at least one component for performing a method according to one or more formats 1-18.

[0198] Format 22: A non-transitory computer-readable medium storing code for wireless communication, the code including instructions executable by a processor to perform a method according to one or more formats 1-18.

[0199] Style 23: A non-transitory computer-readable medium storing an instruction set for wireless communication, the instruction set including one or more instructions which, when executed by one or more processors of a device, cause the device to perform a method according to one or more of the styles 1-18.

[0200] The foregoing disclosure provides explanation and description, but is not intended to be exhaustive or to limit the various forms to the precise forms disclosed. Modifications and variations may be made in accordance with the foregoing disclosure, or modifications and variations may be derived from the implementation of the various forms.

[0201] As used herein, the term "component" is intended to be interpreted broadly as hardware and / or a combination of hardware and software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or other names, "software" should be interpreted broadly as instructions, instruction sets, code, code fragments, code, programs, subprograms, software modules, applications, software applications, software packages, norms, sub-norms, objects, executable files, threads of execution, programs and / or functions, and other instances thereof. As used herein, a "processor" is implemented using hardware and / or a combination of hardware and software. It will be apparent that the systems and / or methods described herein can be implemented using various forms of hardware and / or combinations of hardware and software. The actual specialized control hardware or software code used to implement such systems and / or methods is not a limitation on the variety. Therefore, this paper describes the operation and behavior of the system and / or method without referencing any specific software code, because those skilled in the art will understand that software and hardware can be designed to implement the system and / or method at least in part based on the description herein.

[0202] As used herein, depending on the context, "meets the threshold" can mean a value 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.

[0203] Even if a specific combination of features is described in the claims and / or disclosed in the specification, such combination is not intended to limit the disclosure of each variant. Many features among such features may be combined in a manner not specifically described in the claims and / or disclosed in the specification. The disclosure of each variant includes combinations of each dependent claim with other claims in each of the claim sets. As used herein, the phrase “at least one of” in the list of items means any combination of those items, including a single member. For example, “at least one of a, b, or c” is intended to cover a, b, c, a+b, a+c, b+c, and a+b+c, as well as any combination with multiples of the same element (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 ordering of a, b, and c).

[0204] No element, action, or instruction used herein should be construed as critical or necessary unless explicitly stated otherwise. Furthermore, 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.” Furthermore, as used herein, the article “the” is intended to include one or more items referenced by the article “the” and may be used interchangeably with “one or more.” Furthermore, 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.” Where only one item is anticipated, the phrase “only one” or similar language is used. Furthermore, as used herein, the terms “has,” “have,” “having,” etc., are intended to be open-ended terms that do not limit the elements to which they are modified (e.g., an element “having” A may also have B). Furthermore, unless otherwise expressly stated, the phrase “based on” is intended to mean “at least partially based on.” Furthermore, as used herein, the term "or" is intended to be inclusive when used in a series, and may be used interchangeably with "and / or" unless otherwise expressly stated (e.g., when used in conjunction with "any" or "only one of them"). [Simplified Explanation of the Diagram]

[0012] In order to fully understand the aforementioned features of the present invention, a more specific description of the brief overview above can be obtained by referring to various embodiments (some of which are illustrated in the accompanying drawings). However, it should be noted that the accompanying drawings only illustrate certain typical embodiments of the present invention and are therefore not intended to limit the scope of the present invention, as the description may allow for other equally valid embodiments. Identical element symbols in different drawings can identify the same or similar elements.

[0013] Figure 1 is a schematic diagram illustrating an example of a wireless network according to the contents of this case.

[0014] Figure 2 is a schematic diagram illustrating an example of communication between a base station and a user equipment (UE) in a wireless network according to the contents of this case.

[0015] Figures 3-4 are schematic diagrams illustrating an example of an Open Radio Access Network (O-RAN) architecture according to the content of this case.

[0016] Figures 5-6 are schematic diagrams illustrating an example of an accelerator pass-through associated with control plane information in an O-RAN distributed unit (DU) (O-DU) according to the contents of this case.

[0017] Figure 7 is a schematic diagram illustrating an example of accelerator pass-through associated with control plane information and user plane information in O-DU according to the contents of this case.

[0018] Figure 8 is a schematic diagram illustrating an example of the management plane architecture associated with the O-DU according to the content of this case.

[0019] Figure 9 is a schematic diagram illustrating an exemplary process associated with the pass-through of messages in the accelerator of the distributed unit according to the content of this case.

[0020] Figure 10 is a schematic diagram of an exemplary device for wireless communication according to the contents of this case.

[0021] Figure 11 is a schematic diagram illustrating an example of a decomposed base station architecture based on the content of this case. [Biomaterial Storage]

[0206] Domestic storage information (please note in order of storage institution, date, and number): None. International storage information (please note in order of storage country, institution, date, and number): None.

Claims

1. An apparatus for wireless communication at an Open Radio Access Network (O-RAN) distributed unit (O-DU), comprising: One or more memory units; and one or more processors coupled to the one or more memory units, the one or more processors being configured to: generate a first message at an O-DU application executing on the O-DU, the first message not utilizing an O-DU accelerator, wherein the O-DU accelerator is in-line between the O-DU application and an O-RAN radio unit (O-RU); and transmit the first message from the O-DU application to the O-RU via a direct connection of the O-DU accelerator, wherein the first message is transmitted to the O-RU via the O-DU accelerator based at least in part on a payload of the first message without being altered by the O-DU accelerator.

2. The apparatus according to claim 1, wherein, in order to transmit the first message via the passthrough of the O-DU accelerator, the one or more processors are configured to: embed the payload of the first message at the O-DU accelerator via a transmission interface toward the O-RU, wherein the first message indicates a compressed, in-phase, and quadrature (I / Q) sample of beam weights or describes other parameters of a wireless channel associated with the O-DU.

3. The apparatus according to claim 1, wherein the one or more processors are also configured to: generate a second message at the O-DU accelerator at least in part based 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 transmit the second message from the O-DU accelerator to the O-RU.

4. The device according to claim 3, wherein the first message is a control plane message, and wherein the second message is a control plane message or a user plane message.

5. The apparatus according to claim 3, wherein: The first message is associated with a beam weight implicitly known to the O-RU, which indicates that the first message will be transmitted via the O-DU accelerator, wherein the O-RU knows the beam weight implicitly based at least in part on a semi-static configuration, a dynamic configuration, or according to a dynamic implicit generation at the O-RU indicated by a precoder from the O-DU; and the second message is associated with information generated by the O-DU accelerator, which includes: dynamically generated information to be used in the O-DU to O-RU message, at least one in-phase and quadrature (I / Q) sample to be used in the O-DU to O-RU message, or at least one parameter signaled as a result of accelerator-based decoding when I / Q samples are received from the O-RU.

6. The apparatus according to claim 1, wherein the one or more processors are also configured to: initiate signal transmission between the O-DU application and the O-DU accelerator to negotiate the type of message to be transmitted via the O-DU accelerator and the type of message to be hardware accelerated at the O-DU accelerator.

7. The apparatus according to claim 1, wherein the one or more processors are also configured to support a plurality of channels, and the first message is associated with one of the plurality of channels.

8. The apparatus according to claim 1, wherein the one or more processors are also configured to: initiate signal transmission between the O-DU application and the O-DU accelerator to negotiate parameters associated with segmentation or assembly to be performed by the O-DU application or the O-DU accelerator; or initiate signal transmission 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.

9. The apparatus according to claim 1, wherein the one or more processors are also configured to: generate or interpret segment or header information for a second message not transmitted via the O-DU accelerator at the O-DU application; or generate or interpret the segment or header information for the second message at the O-DU accelerator based at least in part on input received from the O-DU application.

10. The apparatus according to claim 1, wherein the one or more processors are also configured to: generate a second message at the O-DU application; and transmit the second message from the O-DU application to the O-RU via the passthrough of the O-DU accelerator, at least in part, based on the fact that the O-DU accelerator does not support a channel associated with the second message.

11. The apparatus according to claim 1, wherein the one or more processors are also configured to: initiate or terminate management plane signaling of a management plane entity associated with the O-DU application and a management plane entity associated with the O-RU, wherein the management plane signaling is associated with an O-RU initialization, an O-RU exploration or an O-RU orchestration, and wherein the management plane entity is located in the O-DU application and is assisted by a management plane assistant located in the O-DU accelerator.

12. The apparatus according to claim 1, wherein a first message generated at the O-DU application is coordinated with a second message generated at the O-DU accelerator regarding a time-frequency mapping, beam indexing, or spatial streaming to a data frame.

13. The apparatus of claim 1, wherein the one or more processors are configured to transmit the first message via the passthrough of the O-DU accelerator based at least in part on one of the following: the O-DU application signals locations at which the O-DU accelerator generates or anticipates in-phase and quadrature (I / Q) sampling, beam weights, beam indices, channel estimates, or decoded data, wherein such locations are associated with the location of the first message or memory generated by the application; the O-DU application signals the I / Q sampling, beam weights, beam indices, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or the O-DU application signals a second type of message to be used by the O-DU accelerator to generate or interpret a first type of message, wherein the second type of message is associated with control plane messages, and wherein the first type of message is associated with both control plane messages and user plane messages.

14. The apparatus according to claim 1, wherein the one or more processors are configured to: receive a third message from the O-RU at the O-DU application via the passthrough of the O-DU accelerator; and interpret the third message at the O-DU application that does not utilize the O-DU accelerator.

15. The apparatus according to claim 14, wherein the one or more processors are also configured to: receive a fourth message from the O-RU at the O-DU accelerator; and interpret the fourth message at the O-DU accelerator at least in part based on a functional application platform interface between the O-DU accelerator and the O-DU application, wherein the fourth message is hardware-accelerated at the O-DU accelerator.

16. The apparatus according to claim 15, wherein, in order to receive the third message via the direct pass-through of the O-DU accelerator, the one or more processors are configured to: extract a payload of the third message at the O-DU accelerator, wherein the third message indicates a decompression, in-phase and quadrature (I / Q) sampling of beam weights or describes other parameters of a wireless channel associated with the O-DU.

17. The apparatus according to claim 15, wherein: The first message and the second message are associated with messages transmitted by the O-DU; and the third message and the fourth message are associated with messages received by the O-DU.

18. The apparatus according to claim 1, wherein the one or more processors are also configured to: receive the third message from the O-RU via the passthrough of the O-DU accelerator at least in part at the O-DU application based on the fact that the O-DU accelerator does not support a channel associated with a third message; and interpret the third message that does not utilize the O-DU accelerator at the O-DU application.

19. A method of wireless communication performed by an Open Radio Access Network (O-RAN) Distributed Unit (O-DU), comprising the steps of: generating a first message at an O-DU application running on the O-DU, the first message not utilizing an O-DU accelerator of the O-DU, wherein the O-DU accelerator is consistent between the O-DU application and an O-RAN Radio Unit (O-RU); and transmitting the first message from the O-DU application to the O-RU via a direct connection of the O-DU accelerator, wherein the first message is transmitted to the O-RU via the O-DU accelerator based at least in part on a payload of the first message without being altered by the O-DU accelerator.

20. The method of claim 19, wherein the step of transmitting the first message via the O-DU accelerator also includes the following steps: embedding the payload of the first message at the O-DU accelerator via a transmission interface toward the O-RU, wherein the first message indicates a compressed, in-phase, and quadrature (I / Q) sample of the beam weight or describes other parameters of a radio channel associated with the O-DU.

21. The method according to claim 19 also includes the steps of: generating a second 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, wherein the second message is hardware-accelerated at the O-DU accelerator; and transmitting the second message from the O-DU accelerator to the O-RU, wherein the first message is a control plane message, and wherein the second message is a control plane message or a user plane message, wherein the first message is associated with a beam weight implicitly known to the O-RU, the beam weight indicating that the first message will be transmitted via the O-DU accelerator, wherein the O-RU implicitly knows the beam weight based at least in part on a semi-static configuration, a dynamic configuration, or according to a precoder instruction from the O-DU, and wherein the second message is associated with information generated by the O-DU accelerator, the information generated by the O-DU accelerator including: At least one parameter that is used to dynamically generate information for use in O-DU to O-RU messages, at least one in-phase and quadrature (I / Q) sample to be used in the O-DU to O-RU messages, or to signal a result of accelerator-based decoding when receiving I / Q samples from the O-RU.

22. The method according to claim 19 also includes the following steps: initiating signaling between the O-DU application and the O-DU accelerator to negotiate the type of message to be transmitted via the O-DU accelerator and the type of message to be hardware-accelerated at the O-DU accelerator; supporting a plurality of channels, and the first message being associated with one of the plurality of channels; or initiating or terminating management plane signaling at a management plane entity associated with the O-DU application and a management plane entity associated with the O-RU, wherein the management plane signaling is associated with an O-RU initialization, an O-RU exploration, or an O-RU orchestration, and wherein the management plane entity is located in the O-DU application and is assisted by a management plane assistant located in the O-DU accelerator.

23. The method according to claim 19 also includes the following steps: initiating a signal transmission between the O-DU application and the O-DU accelerator to negotiate parameters associated with segmentation or assembly to be performed by the O-DU application or the O-DU accelerator; or initiating a signal transmission 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.

24. The method according to claim 19 also includes the steps of: generating a second message at the O-DU application; and transmitting the second message from the O-DU application to the O-RU via the passthrough of the O-DU accelerator, at least in part, based on the fact that the O-DU accelerator does not support a channel associated with the second message.

25. The method of claim 19, wherein the direct transmission of the first message via the O-DU accelerator is based at least in part on one of the following: the O-DU application signals locations at which the O-DU accelerator generates or anticipates in-phase and quadrature (I / Q) sampling, beam weights, beam indices, channel estimates, or decoded data, wherein these locations are associated with the location of the first message or memory generated by the application; the O-DU application signals the I / Q sampling, beam weights, beam indices, channel estimates, decoded data, and other information associated with message headers and parameters to be generated or interpreted by the O-DU accelerator; or the O-DU application signals a second type of message to be used by the O-DU accelerator to generate or interpret a first type of message, wherein the second type of message is associated with control plane messages, and wherein the first type of message is associated with control plane messages and user plane messages.

26. The method according to claim 19 also includes the following steps: receiving a third message from the O-RU via the passthrough of the O-DU accelerator in the O-DU application; and interpreting the third message that does not utilize the O-DU accelerator in the O-DU application.

27. The method according to claim 26 also includes the steps of: receiving a fourth message from the O-RU at the O-DU accelerator; and interpreting the fourth message at the O-DU accelerator at least in part based on a functional application platform interface between the O-DU accelerator and the O-DU application, wherein the fourth message is hardware accelerated at the O-DU accelerator.

28. The method of claim 27, wherein the step of receiving the third message via the O-DU accelerator includes the following steps: extracting a payload of the third message at the O-DU accelerator, wherein the third message indicates a decompression, in-phase and quadrature (I / Q) sampling of beam weights or describes other parameters of a radio channel associated with the O-DU, wherein the first message and a second message are associated with messages transmitted by the O-DU, and the third message and the fourth message are associated with messages received by the O-DU.

29. A non-transitory computer-readable medium storing an instruction set for wireless communication, the instruction set comprising: 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: generate a first message at an O-DU application executing on the O-DU, the first message not utilizing an O-DU accelerator of the O-DU, wherein the O-DU accelerator is consistent between the O-DU application and an O-RAN Radio Unit (O-RU); and transmit the first message from the O-DU application to the O-RU via a direct connection of the O-DU accelerator, wherein the first message is transmitted to the O-RU via the O-DU accelerator based at least in part on a payload of the first message without being altered by the O-DU accelerator.

30. An apparatus for wireless communication, comprising: The device includes components for generating a first message at an application running on the device, the first message not utilizing an accelerator of the device, wherein the accelerator is consistent between the application and an O-RAN radio unit (O-RU); and components for transmitting the first message from the application to the O-RU via a continuous connection through the accelerator, wherein the first message is transmitted to the O-RU via the accelerator at least in part based on a payload of the first message transmitted to the O-RU without being altered by the accelerator.

Images