Patent Application
20240196445
The present disclosure relates to a Radio Access Network (RAN) design for 4G and 5G based mobile networks, and more particularly, to a system and methods for enabling physical random-access channel (PRACH) repetition combining at an open radio unit (O-RU) at both the time-domain and the frequency-domain in an Open RAN (O-RAN) based RAN.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Traditionally, RANs were built as an integrated unit where the entire RAN was processed. The RAN traditionally uses application specific hardware for processing, making it difficult to upgrade and evolve. As future networks evolve to have massive densification of networks to support increased capacity requirements, there is a growing need to reduce the CAPEX/OPEX costs of RAN deployment and make the solution scalable and easy to upgrade.
In a cloud-based RAN, a significant portion of the RAN layer processing is performed at a central unit (CU) and a distributed unit (DU). Both CUs and DUs are also known as the baseband units (BBUs). CUs are usually located in the cloud on commercial off the shelf servers, while DUs can be distributed. Radio frequency (RF) and real-time critical functions can be processed in the remote radio unit (RU).
3GPP has defined multiple PRACH formats with different lengths. Long formats include formats 0, 1, 2, and 3, with 1, 2, 4, and 4 repetitions, respectively. Short formats include (a) formats A1, A2, and A3, with 2, 4, and 6 repetitions, respectively, (b) formats B1, B2, B3, and B4 with 2, 4, 6, and 12 repetitions, respectively, and (c) formats C0 and C2, with 1 and 4 repetitions, respectively.
The O-RAN specifications provide a way for the O-DU or a service management and orchestration (SMO) unit to configure the O-RU to send the PRACH repetitions to the O-DU. However, the specifications do not provide a way to instruct the O-RU to combine the PRACH repetitions locally in the O-RU and send the combined signal to the O-DU.
The prior art has at least two problems. First, it may add overhead to the fronthaul interface since the O-RU needs to send each and every repetition to the O-DU. Specifically, in case of a lower layer fronthaul based on split option 7-2x, the frequency domain RACH samples data rate on fronthaul can be high, especially for massive MIMO application. With a high-density RACH configuration, it can occupy more than 1 Gbps bandwidth for the fronthaul interface. Second, in some cases, not performing the combining at the O-RU may increase the complexity at the O-RU by executing several FFTs.
In the prior art, there is no solution to achieve coherent combining at the O-RU for an O-RAN based network.
For background, below, we describe two prior art methods of configuring the O-RU to send the PRACH signals, i.e., all PRACH repetitions, to the O-DU.
The first prior art method is static PRACH configuration—M-plane. Since PRACH is periodic, its location in time and frequency resources is constant for all periods. It is therefore possible to configure PRACH via M-plane. To do that, an SMO/O-RU controller needs to configure the following aspects:
Static configurations shall be provided to the O-RU as part of carrier configuration before the configured carrier is activated.
The O-RU exposes its ability to support static PRACH configuration by support of the feature PRACH-STATIC-CONFIGURATION-SUPPORTED in o-ran-module-cap.yang module. The presence of this feature means, that at least one of static-low-level-rx-endpoints offered by the O-RU supports static configuration for PRACH.
The static PRACH configuration includes:
The second prior art method is real-time PRACH configuration—C-plane, which configures the O-RU in real-time with the control parameters needed to process and send the PRACH signal to the O-DU. This is achieved by sending section type 3 with the following parameters:
The O-RU uses these parameters to receive and process the PRACH signal and send it to the O-DU.
The present disclosure provides a system and methods for enabling PRACH repetition combining at the O-RU at both time-domain and frequency-domain. The system and methods reduce the fronthaul data rate and latency related to the RACH samples from O-RU to O-DU and can possibly bring cycle-saving benefits for the O-RU, and improve performance of RACH detection significantly. The present disclosure focuses on PRACH formats with at least 2 PRACH repetitions. The combining benefits will be mainly related to the short PRACH formats.
The method includes (a) communicating from an O-RAN radio unit (O-RU) to an O-RU controller, data informing that the O-RU supports physical random-access channel (PRACH) combining, (b) communicating from the O-RU controller to the O-RU, a parameter to facilitate the PRACH combining, and (c) configuring the O-RU in accordance with the parameter.
A component or a feature that is common to more than one drawing is indicated with the same reference number in each of the drawings.
According to the NR 3GPP specification, a maximum of 12 repetition can be configured for RACH short preamble, which implies, in non-high-speed scenario for RACH IQ samples, a coherent combining between repetitions can be performed in the O-RU. The combining should be linear accumulation between repetitions, with scaling to maintain the thermal noise as power invariant, and it can be performed in either time domain before FFT or frequency domain after FFT, before sending to O-DU.
The present disclosure provides a system and methods for enabling PRACH repetition combining at the O-RU at both time-domain and frequency-domain. The methods can be summarized as follows:
O-RU 105 represents mainly an O-RAN-compliant O-RU that executes the lower physical layer blocks such as FFT/IFFT, CP removal/addition, beamforming, analog to digital converter, digital to analog convertor, and RF functions.
O-RU 105 includes electronic circuitry, namely circuitry 106, that performs operations on behalf of O-RU 105 to execute methods described herein. Circuitry 106 may be implemented with any or all of (a) discrete electronic components, (b) firmware, and (c) a programmable circuit 106A.
Programmable circuit 106A, which is an optional implementation of circuitry 106, includes a processor 107 and a memory 108. Processor 107 is an electronic device configured of logic circuitry that responds to and executes instructions. Memory 108 is a tangible, non-transitory, computer-readable storage device encoded with a computer program. In this regard, memory 108 stores data and instructions, i.e., program code, that are readable and executable by processor 107 for controlling operations of processor 107. Memory 108 may be implemented in a random-access memory (RAM), a hard drive, a read only memory (ROM), or a combination thereof. One of the components of memory 108 is a program module, namely module 109. Module 109 contains instructions for controlling processor 107 to execute operations described herein on behalf of O-RU 105.
O-DU 115 represents an O-RAN compliant O-DU that executes functions such as higher physical layer (based on O-RAN split or similar lower layer splits), MAC, scheduler, and RLC. O-DU 115 can be implemented on proprietary hardware or COTS (commercial over the shelf servers), and it can be on the cloud.
O-DU 115 includes electronic circuitry, namely circuitry 116, that performs operations on behalf of O-DU 115 to execute methods described herein. Circuitry 116 may be implemented with any or all of (a) discrete electronic components, (b) firmware, and (c) a programmable circuit 116A.
Programmable circuit 116A, which is an optional implementation of circuitry 116, includes a processor 117 and a memory 118. Processor 117 is an electronic device configured of logic circuitry that responds to and executes instructions. Memory 118 is a tangible, non-transitory, computer-readable storage device encoded with a computer program. In this regard, memory 118 stores data and instructions, i.e., program code, that are readable and executable by processor 117 for controlling operations of processor 117. Memory 118 may be implemented in a random-access memory (RAM), a hard drive, a read only memory (ROM), or a combination thereof. One of the components of memory 118 is a program module, namely module 119. Module 119 contains instructions for controlling processor 117 to execute operations described herein on behalf of O-DU 115.
The term “module” is used herein to denote a functional operation that may be embodied either as a stand-alone component or as an integrated configuration of a plurality of subordinate components. Thus, each of module 109 and module 119 may be implemented as a single module or as a plurality of modules that cooperate with one another.
While modules 109 and 119 are indicated as being already loaded into memories 108 and 118, respectively, either or both of modules 109 and 119 may be configured on a storage device 130 for subsequent loading into their respective memories 108 and 118. Storage device 130 is a tangible, non-transitory, computer-readable storage device that stores either or both of modules 109 and 119 thereon. Examples of storage device 130 include (a) a compact disk, (b) a magnetic tape, (c) a read only memory, (d) an optical storage medium, (e) a hard drive, (f) a memory unit consisting of multiple parallel hard drives, (g) a universal serial bus (USB) flash drive, (h) a random-access memory, and (i) an electronic storage device coupled to O-RU 105 and/or O-DU 115 via a data communications network.
FH 110 is a connection link between O-DU 115 and O-RU 105 that carries control user synchronization (CUS)-plane packets as well as M-plane packets.
System 100 also includes an O-RU controller 125, an M-plane interface 126, and an O1 interface 129. M-plane interface 126 is a communicative link between O-RU controller 125 and O-RU 105. O1 interface 129 is a communicative link between O-RU controller 125 and O-DU 115.
O-RU controller 125 is a controller that controls operations of O-RU 105 by exchanging M-plane messages with O-RU 105. O-RU 105 reports its capabilities to O-RU controller 125. Subsequently, O-RU controller 125 configures O-RU 105 to operate via M-plane. The exchange of M-plane messages between O-RU controller 125 and O-RU 105 can be accomplished by way of two possible paths, namely (1) via M-plane interface 126, or (2) via O1 interface 129, O-DU 115, and FH 110. Thus, O-RU 105 can report its capabilities to O-RU controller 125, and O-RU controller 125 can send management configuration data to O-RU 105, either (a) directly, via M-plane interface 126, in a hybrid M-plane architecture, or (b) indirectly, via O1 interface 129, O-DU 115 and FH 110, in a hierarchical architecture or hybrid architecture. Communicating means transferring data from a sender to a receiver, e.g., from O-RU 105 to O-RU controller 125, or vice versa. The communicating may be directly from the sender to the receiver, e.g., from O-RU controller 125 to O-RU 105 via M-plane interface 126, or via an intermediary device, e.g., from O-RU controller 125 to O-RU 105 via O-DU 115.
O-RU controller 125 includes electronic circuitry, namely circuitry 124, that performs operations on behalf of O-RU controller 125 to execute methods described herein. Circuitry 124 may be implemented with any or all of (a) discrete electronic components, (b) firmware, and (c) a programmable circuit. Circuitry 124 may be implemented similarly to programmable circuit 116A, i.e., with a processor and a memory that contains instructions that are readable by the processor to control the processor to execute operations on behalf of O-RU controller 125, and the instructions may be stored on storage device 130.
Although O-RU controller 125 is shown as being a stand-alone device, as an alternative to being a stand-alone device, O-RU controller 125 can reside in any of O-DU 115, a service management and orchestration system (SMO) (not shown), or a network management system (NMS) (not shown).
The SMO is responsible for RAN domain management. The key capabilities of the SMO are:
The SMO performs these services through four key interfaces to the O-RAN elements:
The NMS performs FCAP functions and interface for managing network elements.
O-RU 105 can report as part of its capabilities if it supports:
One or more of the above parameters can be included in the capability YANG module, where O-RU 105 includes its supported features and capabilities.
The o-ran-module-cap.yang module (i.e., capability YANG module) is a data model that includes the capabilities of the O-RU.
To make coherent combining in O-RU 105 possible, O-DU 115 sends extra control information to inform O-RU 105 how the combining is to be performed in addition to the fields of section type 3, such as startSymbolId and numSymbol. For each sectionId connected data and control message, a section extension type 21 can be included.
The extension type number 21 is provided just as an example. In practice, the number can be any positive integer from 21 to 127, inclusive.
O-DU 115 can include one or more of the following parameters in the section extension 21 that is sent to O-RU 105 to instruct it to perform PRACH repetition combining:
To maintain the thermal noise as power invariant after combination, the implicit power scaling factor 1/√{square root over (numCombSize)} should be applied, which can make O-DU RACH subsequent processing not affected especially for preamble detection false alarm and miss detection parameters design. So, the coherent combining should be performed as:
where,
In an alternative embodiment, the powerScaler value is designed and selected solely by the vendor of O-DU 115.
In an alternative embodiment, O-DU 115 can use the numCombSize or numCombGroup to convey the number of repetitions to be combined together.
numCombSize: This parameter informs the combining granularity for RACH repetition, here numCombSize should not be bigger than numSymbol in the same control message.
numCombGroup: This parameter informs the combining granularity for RACH repetition. Here, current RACH configuration's repetition number divided by numCombGroup should not be greater than numSymbol in the same control message.
In an alternative embodiment, O-DU 115 can instruct O-RU 105 to combine any number of PRACH repetitions, while other repetitions can be reported individually by O-RU 105 to O-DU 115.
In an example, O-RU controller 125 can configure O-RU 105 with the PRACH repetition combining parameters statically via M-plane interface 126. In this embodiment, O-RU controller 125 includes one or more of the above configurations such as TD/FD, combMask, powerScaler, numCombSize, numCombGroup as static configuration in the YANG module to O-RU 105.
Static configurations can be provided to O-RU 105 as part of carrier configuration, i.e., before the configured carrier is activated or updated by O-RU controller 125, if needed.
O-RU 105 exposes its ability to support static PRACH configuration by support of the feature PRACH-STATIC-CONFIGURATION-SUPPORTED in the o-ran-module-cap.yang module. The presence of this feature means, that at least one of static-low-level-rx-endpoints offered by O-RU 105 supports static configuration for PRACH.
O-RU controller 125 can include the required parameters for static PRACH combining at O-RU 105 in the u-plane conf YANG module. The static PRACH configuration parameters include:
O-RU 105 may use the parameters of the first PRACH repetition, e.g., symbolId, to fill the header and U-plane packet carrying the combined signal of the PRACH repetitions.
Any of the PRACH repetitions parameters, e.g., symbolId, can be used to fill the header and U-plane packet carrying the combined PRACH signal.
O-RU controller 125 may configure O-RU 105 to use the parameters of a specific repetition (first, second, etc.) to send the combined signal back O-DU 115.
Thus, the present document discloses a method of operating an Open Radio Access Network (O-RAN) fronthaul interface between O-RU 105 and O-RU controller 125 for controlling O-RU 105, where the method includes:
O-RU controller 125 may be implemented in an SMO unit, O-DU 115, an NMS, or as a separate entity.
The present document also discloses a method of operating an Open Radio Access Network (O-RAN) fronthaul interface between O-RU 105 and O-RU controller 125 for controlling O-RU 105, where the method includes: configuring, by O-RU controller 125 or via the O-DU 115, PRACH combining configurations to O-RU 105 requesting O-RU 105 to perform PRACH combining based on at least one configuration parameter included in the combining configuration; and sending, by O-RU 105, one or more U-plane messages to O-DU 115 including the combined PRACH repetitions.
The combining configurations may be sent from O-RU controller 125 to O-RU 105 either (a) via M-plane interface 126, or (b) in a section extension appended to a C-plane message sent by O-DU 115 via fronthaul interface 110, and specifically the control plane (C-plane).
The combining configuration message via C-plane or static configurations includes at least one of:
The embodiments described herein show some exemplary parameter sets. The parameter set can be different as long as it can enable coherent combining on the O-RU side (for example, numCombSize can be replaced by numCombNumber equivalently which is the number of coherent combining).
This application is a continuation of International (PCT) Application PCT/CN2021/116141, filed Sep. 2, 2021 and published as WO 2023/028935 A1, the entire contents of all of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2021/116141 | Sep 2021 | WO |
| Child | 18585750 | US |
