Method and apparatus for prach beamforming

Abstract

Described are systems, apparatuses and for Massive-MIMO radio units that apply the Control Plane Antenna Calibration (AC) Receive (Rx) phase compensation results to a Physical Random Access Channel AC prior to beamforming.

Description

METHOD AND APPARATUS FOR PRACH BEAMFORMING DESCRIPTION OF THE RELATED TECHNOLOGYa. Field of the Disclosure

[0001] The present disclosure relates to systems and methods for radio access networks. The present disclosure is related to the design, operation, administration and management of various network elements of 4G, 5G, and further generations of a radio access network system. In particular, the present disclosure relates to Massive-MIMO radio units that apply the CU-plane Antenna Calibration (AC) Rx phase compensation results to the PRACH AC.b. Description of Related Conventional Technology

[0002] Conventionally, the PRACH signal is received on all Massive-MIMO RU’s 32 antennas. The PRACH RU Baseband receiver has a separate path from the regular CU-plane signals / channels (PUCCH / PUSCH). The separate path between the PRACH and PUSCH / PUCCH is employed since the PRACH can have a different SCS (1.25KHz for long PRACH vs. 30KHz PUSCH). Conventional Massive-MIMO Radio does not take advantage the potential gain of PRACH Beamforming (BF) when all the antennas are aligned (Antenna-Calibrated or AC). FIG. 23 shows an example of conventional PRACH BF antenna mapping for AC in conjunction with BF.Conventional systems employed two options, BF: Enabled and BF: Bypassed.

[0003] BF Enabled: Apply PRACH BFWs to all 32 antennas to reduce to 2 layers (eAxC 32 / 33). BF enabled requires the Antenna Calibration compensation to be applied prior to the BF. Conventionally, the PRACH has a separate route in HW than PUSCH and AC is not applied to PRACH. A 2x16 gain of uncorrelated antennas is still 12 dB lower than 2x16 gain of AC compensated antennas. (######Opt.l: PRACH BF enable ##### devmem 0xa8002030 w 0x0)

[0004] BF Bypassed: Select 2 antennas out of all 32 antennas to directly transferred to 2 layers (eAxC 32 / 33). With BF Bypassed, a 2x1 antennas gain is 24dB lower than 2x16 BF gain. (##### Opt.2: PRACH BF bypass with ANT to Layer mapping######:DFE-A ANT sel range 0x00 to 0x07 (pipe0 to 7)DFE-B ANT sel range 0x08 to 0x0F (pipe0 to 7)DFE-C ANT sel range 0x10 to 0x17 (pipe0 to 7)DFE-D ANT sel range 0x18 to 0x1F (pipe0 to 7))..SUMMARY OF THE DISCLOSURE

[0005] Described are implementations of a computer system, computer system components, computer apparatus, a method, and computer program products configured to execute program instructions for the method for radio access network, and operation, administration and management of various network elements of 4G, 5G, and further generations of the radio access network system. The method is performed by a computer system that comprises one or more processors and a computer-readable storage medium encoded with instructions executable by at least one of the processors and operatively coupled to at least one of the processors.

[0006] The described technology provides methods, systems, and computer program products for antenna calibration and PRACH data processing in a radio access network (RAN). In the method, a Radio Unit (RU) receives a Physical Random-Access Channel (PRACH) control message associated with multiple component carriers (CCs), extracts configuration information for each CC — such as frequency offset and PRACH subcarrier spacing (SCS) — from the message, computes antenna-calibrated (AC) compensation values for each CC (and for a plurality of pipes or antennas), writes these compensation values to compensation memory, and processes PRACH data for each CC using the compensation values. The PRACH control message is typically received from a Distributed Unit (DU) at a field-programmable gate array (FPGA) of the RU. The compensation values can becomputed using specific mathematical equations, such as: Comp(i) = e^(j × (θ(i) + 2π × Δf × n / N)), where Comp(i) is the compensation value for the i-th antenna, 0(i) is a phase offset, Af is a frequency offset, n is a subcarrier index, and N is the total number of subcarriers. Variations of this equation can include additional phase terms, such as a global phase offset <p. Processing the PRACH data includes multiplying the PRACH data for each CC with the corresponding compensation values for each antenna, and can further include performing beamforming. The processed PRACH data can then be sent back to the DU.

[0007] A RAN system is configured with an RU configured to perform the above steps, and can include a DU configured to transmit the PRACH control message. A computer program product can include a non-transitory computer readable medium storing instructions that, when executed, cause the RAN to perform the described method, including the computation of compensation values using the specified equations.

[0008] In an implementation, an apparatus comprises: a method for a RAN comprising: receiving, from a Distributed Unit (DU) at a Radio Unit (RU) field-programmable gate array (FPGA), a Physical Random Access Channel (PRACH) Control Plance (C-plane) message; executing, at the RU-FPGA, program logic(PL) to extract a frequency offset and a PRACH Subcarrier spacing (SCS) for each: component carrier (cc) from the C-plane message and providing it to RU-FPGA software (SW); computing, by the RU-FPGA SW, Antenna-Calibrated (AC) compensation values of 32 pipes for each CC based on the frequency offset and a PRACH format; writing, by the RU SW, the computed 32 pipes AC compensation values to PR AC compensation memory; executing, by the RU-FPGA, program logic to multiply the 32 pipes AC compensation values with 32 pipes PRACH data for each CC, perform beamforming (BF); and sending a PRACH layer packet back to the DU.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 is a block diagram of a system architecture.

[0010] FIG. 2 shows an example of a User Plane Stack.

[0011] FIG. 3 shows an example of a Control Plane Stack.

[0012] FIG.4A shows an example of high-level NG-RAN including a gNB CU and DU.

[0013] FIG.4B shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) in a 5G gNB.

[0014] FIG.4C shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) in a 4G ng-eNB.

[0015] FIG. 5 shows a DL (Downlink) Layer 2 Structure.

[0016] FIG. 6 shows an exemplary logical flow for implementing an RB allocation policy.

[0017] FIG. 7 shows an L2 Data Flow example.

[0018] FIG. 8A shows an example of an 0-RAN architecture.

[0019] FIG. 8B shows an example of an 0-RAN 0AM architecture.

[0020] FIG.9A illustrates a PDU Session architecture comprising of multiple DRBs and multiple QoS Flows.

[0021] FIG.9B illustrates a flow for PDU sessions, DRBs and GTP-U Tunnels across CU and DU.

[0022] FIG.9C illustrates a CU and DU view on PDU session, DRBs and GTP-U tunnels for a 5G network architecture.

[0023] FIG. 10 shows a Resource Allocation MAC Scheduler, DL Data, and Flow Control Feedback for 5G Network.

[0024] FIG. 11A is an EN-DC architecture.

[0025] FIG. 11B is a NG-RAN architecture.

[0026] FIG. 12A illustrates an exemplary flow for AC phase compensation.

[0027] FIG. 12B illustrates another exemplary flow for AC phase compensation

[0028] FIG. 13 illustrates an exemplary architecture and flow for AC phase compensation.

[0029] FIG. 14 shows an implementation of an Antenna Calibration in OFDM System Block Diagram.

[0030] FIG. 15 illustrates an implementation of TDD-based Antenna Calibration.

[0031] FIG. 16 illustrates an AC Compensation Phase Table for SW for AC offset calculations.

[0032] FIG. 17 illustrates an exemplary Register File with address offsets.

[0033] FIG. 18 shows an exemplary Phase Memory.

[0034] FIG. 19A shows a table for AC PRACH Enabled compared to AC PRACH Disabled for 32 antennas.

[0035] FIG. 19B shows a graph for a BJ AC PRACH Performance comparison for AC PRACH Enabled compared to AC PRACH Disabled.

[0036] FIG. 19C shows a graph for a BJ AC PRACH Performance comparison for AC PRACH Enabled.

[0037] FIG. 19D shows a graph for a BJ AC PRACH Performance comparison for AC PRACH Disabled.

[0038] FIG. 20A shows result measurements from AC PRACH per antenna alignment from the field.

[0039] FIG. 20B is a graph showing AC PRACH FO SCS from the result measurements from AC PRACH per antenna alignment from the field.

[0040] FIG. 21A shows the PCAP PRACH level result measurements from AC PRACH per antenna alignment from the field when PRACH AC was enabled.

[0041] FIG. 2 IB shows the PCAP PRACH level result measurements from AC PRACH per antenna alignment from the field when PRACH AC was disabled.

[0042] FIG. 22A shows CB and SSB Beam Sweep results.

[0043] FIG. 22B shows CB and SSB Beam Sweep results.

[0044] FIG. 22C shows CB and SSB Beam Sweep results.

[0045] FIG. 22D shows CB and SSB Beam Sweep results.

[0046] FIG. 23 shows an example of PRACH BF antenna mapping.DETAILED DESCRIPTION OF THE DISCLOSURE

[0047] Reference is made to Third Generation Partnership Project (3GPP) and the Internet Engineering Task Force (IETF) and related standards bodies in accordance with embodiments of the present disclosure. The present disclosure employs abbreviations, terms and technology defined in accord with Third Generation Partnership Project (3GPP) and / or Internet Engineering Task Force (IETF) technology standards and papers, including the following standards and definitions. 3GPP and IETF technical specifications (TS), standards (including proposed standards), technical reports (TR) and other papers are incorporated by reference in their entirety hereby, define the related terms and architecture reference models that follow.

[0048] 0-RAN. WG4. MP.0-R003-vl3.00

[0049] 3GPP TS 23.203 V 17.2.02021-12-23

[0050] 3GPP TS 23.501 V 18.1.02023-04-05

[0051] 3GPP TS 38.300 V 17.4.003-28-2023

[0052] 3GPP TS 36.321 V 17.4.02023-03-29

[0053] 3GPP TS 36.323 V 17.2.02023-01-13

[0054] 3GPP TS 38.321 V 17.4.02023-03-29

[0055] 3GPP TS 38.401 V 17.4.02023-04-03

[0056] 3GPP TS 38.425 17.3.0, 2023-04-03

[0057] Acronyms3GPP: Third generation partnership project 5GC: 5G Core Network5G NR: 5G New Radio5QI: 5G QoS IdentifierACK: AcknowledgementACLR: Gain and Adjacent Channel Leakage Ratio ADC: Analog-to-Digital ConverterAM: Acknowledged ModeAMF: Access Mobility FunctionAMBR: Aggregate Maximum Bit RateAPN: Access Point NameARP: Allocation and Retention PriorityASIC: Application Specific Integrated Circuit AWGN: Additive White Gaussian Noise BF: BeamformingBFW: Beamforming weightBS: Base StationCB: Common BeamCC: Component CarrierCNF: Cloud-Native Network FunctionCP: Control PlaneC-RAN: cloud radio access networkCU: Centralized unitCU-CP: Centralized Unit - Control Plane CU-UP: Centralized Unit - User Plane CQI: Channel Quality IndicatorDAC: Digital-to-Analog ConverterDC: Dual ConnectivityDCI: Downlink Control Information DDDS: DL Data Delivery StatusDFE: Digital Front EndDL: DownlinkDMRS: Demodulation Reference Signal DNN: Data Network NameDRB: Data Radio BearerDU: Distributed uniteNB: evolved Node BeMBB: Enhanced Mobile BroadbandEPC: Evolved Packet CoreEN-DCEP: Endpoint PodE-UTRAN: Evolved Universal Terrestrial Radio Access NetworkE-RAB: E-UTRAN Radio Access BearerIoT: Internet of ThingsIP: Internet ProtocolIWF: Interworking FunctionFGPA: Field-Programmable Gate ArrayGBR: Guaranteed Bit RategNB: gNodeB (5G base station)GTP-U: General Packet Radio Service (GPRS) Tunnelling Protocol - User Plane GW: GatewayHA: High AvailabilityL1: Layer 1L2: Layer 2L3: Layer 3LC: Logical ChannelLTE: Long Term Evolution (4G)MAC: Medium Access ControlMIMO: multiple-in multiple-outMME: Mobility Management EntityMR-DC: Multi-Radio Dual ConnectivityM-plane: Management plane interface between SMO and O-RU NACK: Negative AcknowledgementNAS: Non-Access StratumNB: NarrowbandNear-RT RIC: Near-Real-Time RICng: Next GenerationNMS: Network Management SystemNR: New RadioNR-U: New Radio - User PlaneNSA: Non-Standalone ArchitectureOFDM: orthogonal frequency-division multiplexingO-RAN: Open Radio Access NetworkPA: Power AmplifierPCAP: packet capturePDB: Packet Delay BudgetPDCP: Packet Data Convergence ProtocolPDU: Protocol Data UnitPDCCH: Physical Downlink Control ChannelPDSCH: Physical Downlink Shared ChannelPHY: Physical LayerPRACH: Physical Random-Access ChannelPRG: Physical Resource block GroupPUCCH: Physical Uplink Control ChannelPUSCH: Physical Uplink Shared ChannelQCI: QoS Class IdentifierQFI: QoS Flow IdQFI: QoS Flow IdentifierQoS: Quality of ServiceRAT: Radio Access TechnologyRB: Resource BlockRDI: Reflective QoS Flow to DRB IndicationRIC: RAN Intelligent ControllerRLC: Radio Link ControlRLC-AM: RLC Acknowledged ModeRLC-UM: RLC Unacknowledged ModeRMM: Radio resource managementRQI: Reflective QoS IndicationRRC: Radio Resource ControlRU: Radio UnitSA: Standalone ArchitectureSCTP: Stream Control Transmission ProtocolSCS: Subcarrier SpacingSDAP: Service Data Adaptation ProtocolSDU: Service Data UnitS-GW: Serving GatewaySINR: Signal-to-Interference and Noise Ratio SMO: Service Management and Orchestration systemSN: Secondary NodeSR: Scheduling RequestSSB: Synchronization Signal BlocksSW: SoftwareSRS: Sounding Reference SignalTCP: Transmission Control ProtocolTEID: Tunnel Endpoint IdentifierU-plane: User planeUPF: User Plane FunctionUE: user equipmentUL: uplinkUM: Unacknowledged ModeURLLC: Ultra Reliance Low Latency Communication

[0058] Described are implementations of technology for a cloud-based Radio Access Networks (RAN), where 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. The RF and real-time critical functions can be processed in the remote radio unit (RU).

[0002] RAN Architectures

[0003] FIG. 1 is a block diagram of a system 100 for implementations as described herein. System 100 includes a NR UE 101, a NR gNB 106. The NR UE and NR gNB 106 are communicatively coupled via a Uu interface 120.

[0004] NR UE 101 includes electronic circuitry, namely circuitry 102, that performs operations on behalf of NR UE 101 to execute methods described herein.Circuity 102 can be implemented with any or all of [a] discrete electronic components, (b) firmware, and (c) a programmable circuit 102A.

[0005] NR gNB 106 includes electronic circuitry, namely circuitry 107, that performs operations on behalf of NR gNB 106 to execute methods described herein. Circuity 107 can be implemented with any or all of [a] discrete electronic components, (b) firmware, and (c) a programmable circuit 107A.

[0006] Programmable circuit 107A, which is an implementation of circuitry 107, includes a processor 108 and a memory 109. Processor 108 is an electronic device configured of logic circuitry that responds to and executes instructions. Memory 109 is a tangible, non-transitory, computer-readable storage device encoded with a computer program. In this regard, memory 109 stores data and instructions, i.e., program code, that are readable and executable by processor 108 for controlling operations of processor 108. Memory 109 can be implemented in a random-access memory (RAM), a hard drive, a read only memory (ROM), or a combination thereof. One component of memory 109 is a program module, namely module 110. Module 110 includes instructions for controlling processor 108 to execute operations described herein on behalf of NR gNB 106.

[0007] The term "module" is used herein to denote a functional operation that can be embodied either as a stand-alone component or as an integrated configuration of a plurality of subordinate components. Thus, a module 110 can be implemented as a single module or as a plurality of modules that operate in cooperation with one another.

[0008] While modules 110 are indicated as being already loaded into memories 109, and module 110 can be configured on a storage device 130 for subsequent loading into their memories 109. Storage device 130 is a tangible, non-transitory, computer- readable storage device that stores module 110 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 memoryunit comprising 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 NR gNB 106 via a data communications network.

[0009] Uu Interface (120) is the radio link between the NR UE and NR gNB, which is compliant to the 5G NR specification.

[0010] UEs 101 can be dispersed throughout a wireless communication network, and each UE can be stationary or mobile. A UE includes: an access terminal, a terminal, a mobile station, a subscriber unit, a station, and the like. A UE can also include be a cellular phone (e.g., a smart phone), a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet, a camera, a gaming device, a drone, a robot / robotic device, a netbook, a smartbook, an ultrabook, a medical device, medical equipment, a healthcare device, a biometric sensor / device, a wearable device such as a smartwatch, smart clothing, smart glasses, a smart wristband, and / or smart jewelry (e.g., a smart ring, a smart bracelet, and the like), an entertainment device (e.g., a music device, a video device, a satellite radio, and the like), industrial manufacturing equipment, a global positioning system (GPS) device, or any other suitable device configured to communicate via a wireless or wired medium. UEs can include UEs considered as machine-type communication (MTC) UEs or enhanced / evolved MTC (eMTC) UEs. MTC / eMTC UEs that can be implemented as IoT UEs. IoT UEs include, for example, robots / robotic devices, drones, remote devices, sensors, meters, monitors, cameras, location tags, and the like, which can communicate with a BS, another device (e.g., remote device), or some other entity. A wireless node can provide, for example, connectivity for or to a network (e.g., a wide area network such as Internet or a cellular network) via a wired or wireless communication link.

[0011] One or more UEs 101 in the wireless communication network can be a narrowband bandwidth UE. As used herein, devices with limited communication resources, e.g. smaller bandwidth, are considered as narrowband UEs. Similarly,legacy devices, such as legacy and / or advanced UEs, can be considered as wideband UEs. Wideband UEs are generally understood as devices that use greater amounts of bandwidth than narrowband UEs.

[0012] The UEs 101 are configured to connect, for example, communicatively couple, with a RAN. In embodiments, the RAN can be an NG RAN or a 5G RAN, an E-UTRAN, an MF RAN, or a legacy RAN, such as a UTRAN or GERAN. The term " NG RAN” or the like refers to a RAN 110 that operates in an NR or 5G system, the term " E-UTRAN” or the like refers to a RAN that operates in an LTE or 4G system, and the term " MF RAN" or the like refers to a RAN that operates in an MF system 100. The UEs 101 utilize connections (or channels), respectively, each of which comprises a physical communications interface or layer. The connections and can comprise several different physical DL channels and several different physical UL channels. As examples, the physical DL channels include the PDSCH, PMCH, PDCCH, EPDCCH, MPDCCH, R-PDCCH, SPDCCH, PBCH, PCFICH, PHICH, NPBCH, NPDCCH, NPDSCH, and / or any other physical DL channels mentioned herein. As examples, the physical UL channels include the PRACH, PUSCH, PUCCH, SPUCCH, NPRACH, NPUSCH, and / or any other physical UL channels mentioned herein.

[0013] The RAN can include one or more AN nodes or RAN nodes. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, MF-APs, TRxPs or TRPs, and so forth, and comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The term " NG RAN node” or the like refers to a RAN node that operates in an NR or 5G system (e.g., a gNB), and the term " E-UTRAN node" or the like refers to a RAN node that operates in an LTE or 4G system (e.g., an eNB). According to various embodiments, the RAN nodes can be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0014] In some embodiments, all or parts of the RAN nodes can be implemented as one or more software entities running on server computers as part of a virtual network, which can be referred to as a CRAN and / or a vBBU. In these embodiments, the CRAN or vBBU can implement a RAN function split, such as a PDCP split wherein RRC and PDCP layers are operated by the CRAN / vBBU and other L2 protocol entities are operated by individual RAN nodes; a MAC / PHY split where RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBU and the PHY layer is operated by individual RAN nodes; or a "lower PHY” split where RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer are operated by the CRAN / vBBU and lower portions of the PHY layer are operated by individual RAN nodes. This virtualized framework allows the freed-up processor cores of the RAN nodes to perform other virtualized applications. In some implementations, an individual RAN node can represent individual gNB-DUs that are connected to a gNB-CU 151via individual Fl interfaces. In these implementations, the gNB-DUs can include one or more remote radio heads (RRH), and the gNB-CU 151 can be operated by a server that is located in the RAN or by a server pool in a similar manner as theCRAN / vBBU. One or more of the RAN nodes can be next generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations toward the UEs 101, and are connected to a 5GC via an NG interface. In MF implementations, the MF-APs are entities that provide MultiFire radio services, and can be similar to eNBs in an 3GPP architecture.

[0015] In some implementations, access to a wireless interface can be scheduled, wherein a scheduling entity (e.g.: BS, gNB, and the like) allocates bandwidth resources for devices and equipment in its service area or cell. As scheduling entity can be configured to schedule, assign, reconfigure, and release resources for one or more subordinate entities. In some examples, a UE 101 (or other device) can function as master node scheduling entity, scheduling resources for one or more secondary node subordinate entities (e.g., one or more other UEs 101). Thus, in a wireless communication network with a scheduled access to time — frequency resources and having a cellular configuration, a P2P configuration,and a mesh configuration, a scheduling entity and one or more subordinate entities can communicate utilizing the scheduled resources.

[0016] BS or gNB 106 can be equipped with T antennas and UE 101 can be equipped with R antennas, where in general T>1 and R>1. At BS, a transmit processor is configured to receive data from a data source for one or more UEs 101 and select one or more modulation and coding schemes (MCS) for each UE based on channel quality indicators (CQls) received from the UE 101. The BS is configured to process (e.g., encode and modulate) the data for each UE 101 based on the MCS(s) selected for the UE 101, and provide data symbols for all UEs. A transmit processor is also configured to process system information (e.g., for static resource partitioning information (SRPI), and the like) and control information (e.g., CQI requests, grants, upper layer signaling, and the like) and can provide overhead symbols and control symbols. Processor 108 can also generate reference symbols for reference signals (e.g., the cell-specific reference signal (CRS)) and synchronization signals (e.g., the primary synchronization signal (PSS) and the secondary synchronization signal (SSS)). A transmit (TX) multiple-input multiple-output (MIMO) processor can be configured perform spatial processing (e.g., preceding) on the data symbols, the control symbols, the overhead symbols, and / or the reference symbols, if applicable, and can be configured to provide T output symbol streams to T modulators (MODs). Each modulator can be configured to process a respective output symbol stream (e.g., for OFDM, and the like) to obtain an output sample stream. Each modulator can further be configured to process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. T downlink signals from modulators can be transmitted via T antennas.

[0017] An overview of 5G NR Stacks is as follows. 5G NR (New Radio) user and control plane functions with monolithic gNB 106 are shown in FIG. 1 and FIG. 2. For the user plane, PHY (physical), MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet Data Convergence Protocol) and SDAP (Service DataAdaptation Protocol] sublayers are terminated in the gNB 106 on the network side. For the control plane, RRC (Radio Resource Control), PDCP, RLC, MAC and PHY sublayers are terminated in the gNB 106 on the network side and NAS (Non-Access Stratum) is terminated in the AMF (Access Mobility Function) on the network side. FIG. 2 shows an example of a User Plane Stack as described in 3GPP TS 38.300. FIG.3 shows an example of a Control Plane Stack as described in 3GPP TS 38.300.

[0018] An NG- RAN (NG-Radio Access Network) architecture from 3GPP TS 38.401 is described below. Fl is the interface between gNB-CU 151 (gNB -Centralized Unit) and gNB-DU 152 (gNB - Distributed Unit), NG is the interface between gNB-CU 151 (or gNB) and 5GC (5G Core), El is the interface between CU-CP (CU-Control Plane) and CU-UP (CU-User Plane), and Xn is interface between gNBs.

[0019] A gNB 106 can comprise a gNB-CU-CP, multiple gNB-CU-UPs and multiple gNB-DUs. The gNB-CU-CP is connected to the gNB-DU 152 through the Fl-C interface and to the gNB-CU-UP through the El interface. The gNB-CU-UP is connected to the gNB-DU 152 through the Fl-U interface and to the gNB-CU-CP through the El interface. One gNB-DU 152 is connected to one gNB-CU-CP and one gNB-CU-UP is connected to one gNB-CU-CP. FIG. 4A shows an example of a NG-RAN Architecture as described in 3GPP TS 38.401. FIG. 4B shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) as described in 3GPP TS 38.401.

[0020] A Layer 2 (L2) of 5G NR is split into the following sublayers is described in 3GPP TS 38.300):o Medium Access Control (MAC): The MAC sublayer offers Logical Channels (LCs) to the RLC sublayer. This layer runs a MAC scheduler to schedule radio resources across different LCs (and their associated radio bearers).o Radio Link Control (RLC): The RLC sublayer offers RLC channels to the PDCP sublayer. The RLC sublayer supports three transmission modes: RLC-Transparent Mode (RLC-TM), RLC-Unacknowledged Mode (RLC-UM) and RLC-Acknowledgement Mode (RLC-AM). RLC configuration is per logical channel. It hosts ARQ (Automatic Repeat Request) protocol for RLC-AM mode.o Packet Data Convergence Protocol (PDCP): The PDCP sublayer offers Radio Bearers (RBs) to the SDAP sublayer. There are two types of Radio Bearers: Data Radio Bearers (DRBs) for data and Signaling Radio Bearers (SRBs) for control plane.o Service Data Adaptation Protocol (SDAP): The SDAP offers QoS Flows to the 5GC (5G Core). This sublayer provides mapping between a QoS flow and a DRB. It marks QoS Flow Id in DL (downlink) as well as UL (uplink packets).

[0021] FIG. 4B shows an example of a Separation of 4G CU-CP (CU-Control Plane) and CU-UP (CU-User Plane). The example shown in FIG. 4B shows ng-eNB but legacy eNB also applies same architecture.

[0022] FIG. 5 shows a DL (Downlink) Layer 2 Structure as described in 3GPP TS 38.300. FIG. 6 shows an UL (uplink) Layer 2 Structure in accord with 3GPP TS38.300. FIG. 7 shows a L2 Data Flow example in accord with 3GPP TS 38.300 ([H] denotes headers or subheaders in FIG. 7.)

[0023] O-RAN, which is based on disaggregated components and connected through open and standardized interfaces, is based on 3GPP NG-RAN. An overview of O-RAN with disaggregated RAN (CU, DU, and RU), near-real-time RIC 155 and non-real-time RIC is shown in the figure below. Here, DU (Distributed Unit) and CU (Centralized Unit) are typically implemented using COTS (Commercial off-the-shelf) hardware.

[0024] FIGS. 8A-8B show an example of an 0-RAN architecture. In FIG. 8A, the CU and the DU are connected using the Fl interface (with Fl-C for control plane and Fl-U for user plane traffic] over the midhaul [MH] path. One DU could host multiple cells (for example, one DU could host 24 cells] and each cell can support many users. For example, one cell can support 600 RRC connected users and out of these 600, there can be 200 Active users (i.e., users which have data to send at a given point of time].

[0025] A cell site can comprise multiple sectors and each sector can support multiple cells. For example, one site could comprise three sectors and each sector could support 8 cells (with 8 cells in each sector on different frequency bands]. One CU-CP could support multiple DUs and thus multiple cells. For example, a CU-CP could support 1000 cells and around 100,000 UEs. Each UE could support multiple DRBs and there could be multiple instances of CU-UP to serve these DRBs. For example, each UE could support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UEs] can be served by five CU-UP instances (and one CU-CP instance].

[0026] DU can be located in a private data center, or it could be located at a cell-site too. CU can also be located in a private data center or even hosted on a public cloud system. DU and CU can be tens of kilometers away. CU can communicate with 5G core system which could also be hosted in the same public cloud system (or could be hosted by a different cloud provider]. RU (Radio Unit] is located at cell-site and communicated with DU via a fronthaul (FH] interface.

[0027] The E2 nodes (CU and DU] are connected to the near-real-time RIC 155 using the E2 interface. The E2 interface is used to send data (e.g., user, cell, slice KPMs] from the RAN, and deploy control actions and policies to the RAN at near-real-time RIC 155. The application or service at the near-real-time RIC 155 that deploys the control actions and policies to the RAN are called xApps. The near-real-time RIC 155 is connected to the non-real-time RIC 161 using the Al interface.

[0028] SMO 160 manages multiple regional networks, and O-RAN NFs (O-CUs 151, Near-RT RIC 155, O-DUs 152) can be deployed in a regional data center that is connected to multiple cell sites or in cell site which is close to localized 0-RU 153 according to network requirements. Since SMO 160 Functions and O-RAN NFs are micro services and deployment-independent logical functions, SMO 160 Functions and O-RAN NFs can be composed of multiple deployment instances deployed in the same O-Cloud or in a different O-Cloud in regional data center, or in cell site according to network requirements (ex. capacity, latency, security, and so on) if the secure connection among SM0160 Functions and O-RAN NFs are available.

[0029] As shown in FIG. 8B, an O-RAN compliant SMO 160 defines TE& IV 163, RAN NF 0AM 164, Non-RT RIC 161, and NFO165, FOCOM services 166. SMO 160 interacts with O-RAN NFs with 01 interface. SMO interacts with O-RU 153 with Open FH M-Plane interface and interacts O-Cloud via the 02 interface. O-RAN NF 0AM 164 manages O-RAN NF CM, FM, PM and creates O-RAN NF inventory and topology in TE& IV 163. FOCOM / NFO 166 manages O-Cloud resources and creates O-Cloud resources inventory and topology in TE& IV 163. Analytics / rApp in Non-RT RIC 161 can subscribe O-RAN NFs PM / FM, O-Cloud PM / FM data based on O-RAN NF 0AM and FOCOM 166 / NFO 165. Analytics / rApp in Non-RT RIC 161 can retrieve the O-RAN NF and O-Cloud resource inventory and topology.

[0030] PDU Sessions, DRBs, QoS Flows

[0031] In 5G networks, PDU connectivity service is a service that provides exchange of PDUs between a UE and a data network identified by a Data Network Name (DNN). The PDU Connectivity service is supported via PDU sessions that are established upon request from the UE. This DNN defines the interface to a specific external data network. One or more QoS flows can be supported in a PDU session. All the packets belonging to a specific QoS flow have the same 5QI (5G QoS Identifier). FIG. 9A illustrates a PDU Session architecture comprising of multiple DRBs. Each DRB can include multiple QoS flows (3GPP TS 23.501). FIG. 9B illustrates a flow for PDU sessions, DRBs and GTP-U Tunnels across CU and DU. FIG.9C illustrates a CU and DU view on PDU session, DRBs and GTP-U tunnels for a 5G network architecture.

[0032] As shown in FIGS.9A-9C, a PDU session comprises the following:

[0033] A Data Radio Bearer (DRB) is between UE and CU in RAN and a NG-U GTP tunnel which is between CU and UPF (User Plane Function) in the core network. For the 3GPP’s 5G network architecture, the transport connection between the base station (i.e., CU-UP) and User Plane Function (UPF) uses a single GTP-U tunnel per PDU session. The PDU session is identified using GTP-U TEID (Tunnel Endpoint Identifier). The transport connection between DU and CU-UP uses a single GTP-U tunnel per DRB.

[0034] SDAP

[0035] The SDAP (Service Adaptation Protocol) Layer receives downlink data from the UPF across the NG-U interface. It maps one or more QoS Flow(s) onto a specific DRB. The SDAP header is present between the UE and the CU (when reflective QoS is enabled), and includes a field to identify the QoS flow in a specific PDU session. GTP-U protocol includes a field to identify the QoS flow and is present between CU and UPF (in the core network).

[0036] Procedures and functionality of the Fl-U interface are defined in 3GPP TS 38.425. This Fl-U interface supports NR User Plane (NR UP) protocol that provides support for flow control and reliability between CU-UP and DU for each DRB. FIG. 10 shows a Resource Allocation (MAC Scheduler), DL Data, and Flow Control Feedback (DDDS) in 5G Networks. Downlink User Data (DUD) PDU are used to carry PDCP PDUs from CU-UP to DU for each DRB. Downlink Data Delivery Status (DDDS) PDU from DU to CU-UP. The DDDS message conveys Desired Buffer Size (DBS), Desired Data Rate (DDR) and some other parameters from DU to CU-UP for each DRB as part of flow control feedback.

[0037] An E-UTRAN architecture is illustrated in FIG. 11A. The E-UTRAN comprises eNBs, providing the E-UTRAN U-plane (PDCP / RLC / MAC / PHY) and control plane (RRC) protocol terminations towards the UE. The eNBs are interconnected with each other by the X2 interface. The eNBs are also connected by the SI interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by the Sl-MME interface and to the Serving Gateway (S-GW) by the Sl-U interface. The SI interface supports a many-to-many relation between MMEs / Serving Gateways and eNBs.

[0038] E-UTRAN also supports MR-DC via E-UTRA-NR Dual Connectivity (EN-DC), in which a UE is connected to one eNB that acts as a MN and one en-gNB 106 that acts as a SN. An EN-DC architecture is illustrated in FIG. 11A. The eNB is connected to the EPC 140 via the SI interface and to the en-gNB 106 via the X2 interface. The en-gNB 106 might also be connected to the EPC 140 via the Sl-U interface and other en-gNBs 106 via the X2-U interface. In EN-DC, an en-gNB 106 comprises gNB-CU 151 and gNB-DU(s)152.

[0039] As shown in FIG. 11B, in the NG-RAN architecture, a NG-RAN node is either:a gNB, providing NR user plane and control plane protocol terminations towards the UE; ora ng-eNB, providing E-UTRA user plane and control plane protocol terminations towards the UE. (3GPP TS 38.30017.3.0.).

[0040] As shown in FIG. 11B, the gNBs 106 and ng-eNBs are interconnected with each other by the Xn interface. The gNBs 106 and ng-eNBs are also connected by the NG interfaces to the 5GC, more specifically to the AMF (Access and Mobility Management Function) by the NG-C interface and to the UPF (User Plane Function) by the NG-U interface.

[0041] The gNB 106 and ng-eNB host functions such as functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling), connection setup and release; session Management; QoS Flow management and mapping to data radio bearers; and Dual Connectivity.

[0042] In an example, control information (e.g., scheduling information) can be provided for broadcast and / or multicast operation. The UE can monitor different bundle sizes for the control channel depending on the maximum number of repetitions.

[0043] Implementations

[0044] Disclosed are implementations of technology for Massive-MIMO radio units that apply the CU-plane Antenna Calibration (AC) Receive Rx phase compensation results to a PRACH AC prior to BF.

[0045] Conventionally, the PRACH signal is received on all Massive-MIMO RU’s 32 antennas. Unlike the CU-plane AC phase compensation that is applied to all the BW (e.g., 100MHz), the PRACH AC can be applied only to the PRACH BW frequencies (e.g., 3 PRBs = 36 REs = 1.08MHz). Hence, before applying the PRACH AC compensation to all 32 antennas, the RU SW can be configured with the PRACH center frequency (CF) offset relative to the U-plane BW (e.g., PRACH CF = -48.6 MHz in the 100MHz (-50MHz to + 50MHz) BW). The PRACH offset is derived from the PRACH frequency info delivered by the DU to the RU.

[0046] FIG. 12A illustrates an exemplary architecture and flow for AC phase compensation. As shown in FIG. 12A, at block 1 the DU sends a PRACH C-plane message to the RU-FPGA. At block 2, the PL at the RU-FPGA executes PL logic to extract a frequency offset and PRACH SCS for each CC of a plurality of CCs from the C-plane message and provides it to the RU SW via a register. FIG. 17 shows an exemplary Register File (Regfile) with address offsets. At block 3 of FIG. 12A, the RU SW computes AC compensation values of 32 pipes for each CC of a plurality of CCsbased on the frequency offset and PRACH format. The PS computes 32 pipes times each of the CC values. For instance, for CC=4, 32 x 4 = 128 values. At block 4, the RU SW writes the computed 32 pipes AC compensation values to PR AC comp memory (such as, for example, by the AXI register]. At block 5, the RU PL executes PL logic to multiply the 32 pipes AC compensation values with 32 pipes PRACH data for each CC, performs BF, and sends PRACH layer packet back to the DU via a PRACH U-plane message.

[0047] FIG. 12 B shows another implementation of the disclosure. As shown in FIG. 12B, at block 11 the DU sends a PRACH C-plane message to the RU-FPGA. At block 12, the PL at the RU-FPGA executes PL logic to extract a PRACH SCS for each CC of a plurality of CCs from the C-plane message and provides it to the RU SW [PS] via a register. At block 13 of FIG. 12B, the RU SW computes AC compensation values of 32 pipes for 40 segments per CC for all segments. For instance, the 40 segments can be 1.25 SCS / 52 30KHz SCS per CC for all segments (BW / (40 or 52)]. The RW SW then computes 32 pipes x 40 / 52 segments for 1.25 KHz SCS and CC=4, 32x4x40= 2120 values. For 30 KHz, SCS and CC=4, 32x4x52 = 6656 values.

[0048] At block 14, the RU SW writes the computed 5120 / 6656 AC compensation values to PR AC comp memory (such as, for example, by the AXI register] and sends the AC comp values to the RU-FPGA PL. At block 15, the RU-FPGA PL executes PL logic to read the 32 pipes AC compensation values from 40 / 52 segments based on frequency offset data from the C-plane message and multiply the read 32 pipes AC compensation values with 32 pipes PRACH data for each CC, performs BF, and sends PRACH layer packet back to the DU via a PRACH U-plane message.

[0049] FIG. 13 is a block diagram showing an example of an implementation architecture for AC PRACH for the architectural flows of FIGS. 12A-12B.

[0050] FIG. 14 shows the block diagram and an example of implementation of an Antenna Calibration in OFDM System.

[0051] FIG. 15 shows the 5G-NR TDD-based Frame Format where the Antenna Calibration process can be performed. An exemplary Tx or Rx antenna calibration of a single antenna can be processed per 5ms.

[0052] FIG. 16 shows an AC Compensation Phase Table for RU SW for AC offset calculations. In FIG. 16, for a minimum SC SW index = 0:x = SC = (cpoo■ 16 + SCnum■ 24) / 486 = kx + bcpoQ-. C-plane PRACH offset / 16 (16-bit]

[0053] The SW is configured to read the phase from x address offset of the corresponding non-FFTshift pipe AC Compensation mem.x SC (cpc>2 T SCnum) / 2θ = kx + bx: AC Comp, address offset (non-FFTshift)cpo2: C-plane PRACH offset (16-bitSCnumNumber of SCs (100MHz: 3276

[0054] Depending on the PRACH BW, the AC compensation phase can be either a single value per antenna, or a range of phases spanning through the PRACH BW.

[0055] FIG. 17 shows an exemplary Register File (Regfile] with address offsets. FIG. 18 shows an exemplary Phase Memory (SW side].

[0056] Results

[0057] FIG. 19A shows a table for AC PRACH Enabled compared to AC PRACH Disabled for 32 antennas. As shown in FIG. 19A, the gain gap between the 2 layerswas 8db for disabled and 0.37dB for enabled. FIG. 19B shows a graph for a BJ AC PRACH Performance comparison for AC PRACH Enabled compared to AC PRACH Disabled. FIG. 19C shows a graph for a BJ AC PRACH Performance comparison for AC PRACH Enabled. FIG. 19D shows a graph for a BJ AC PRACH Performance comparison for AC PRACH Disabled.

[0058] FIG. 20A shows result measurements from AC PRACH per antenna alignment from the field. FIG. 20B is a graph showing AC PRACH FO SCS from the result measurements from AC PRACH per antenna alignment from the field.

[0059] FIG. 21A shows the PCAP PRACH level result measurements from AC PRACH per antenna alignment from the field when PRACH AC was enabled. FIG. 2 IB shows the PCAP PRACH level result measurements from AC PRACH per antenna alignment from the field when PRACH AC was disabled. As shown in FIGS. 21A-21B, there was a 4dB gain of 2 L AC for PRACH when PRACH AC was enabled.

[0060] FIGS. 22A-22D show CB and SSB Beam Sweep results.

[0061] As shown by the results above, implementation as described herein deliver the optimal gain for PRACH. Implementations of the present disclosure leverage the Massive-MIMO antennas and the AC and increases PRACH detection distance by 4 times compared to conventional systems. Implementations are also highly effective for Common Beam and SSB Beam Sweep.

[0062] It will be understood that implementations and embodiments can be implemented by computer program instructions. These program instructions can be provided to a processor to produce a machine, so that the instructions, which execute on the processor, create means for implementing the actions specified herein. The computer program instructions can be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process so that the instructions, which execute on the processor to provide steps for implementing the actions specified. Moreover, some of the steps can also be performed across more than one processor, such as mightarise in a multi-processor computer system or even a group of multiple computer systems. In addition, one or more blocks or combinations of blocks in the flowchart illustration can also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the disclosure.

Claims

CLAIMS1. A method for a radio access network (RAN) comprising:receiving, ata Radio Unit (RU), a Physical Random-Access Channel (PRACH) control message associated with a plurality of component carriers (CCs);extracting, at the RU, configuration information for each CC from the PRACH control message;computing, at the RU, compensation values for each CC based on the configuration information;writing, by the RU, the compensation values to compensation memory; andprocessing PRACH data for each CC using the compensation values.

2. The method of claim 1, wherein the PRACH control message is received from a Distributed Unit (DU) at a field-programmable gate array of the RU (RU- FPGA), the PRACH control message.

3. The method of claim 1, wherein the configuration information comprises a frequency offset and a PRACH subcarrier spacing (SCS) for each CC.

4. The method of claim 1, wherein the compensation values are antenna- calibrated (AC) compensation values.

5. The method of claim 1, wherein the compensation values are computed for a plurality of pipes for each CC.

6. The method of claim 1, wherein the compensation values for each CC are computed according to:Comp(i) = e^(j × (θ(i) + 2π × Δf × n / N)),where Comp(i) is the compensation value for the i-th antenna, 0(i) is a phase offset for the i-th antenna, Af is a frequency offset, n is a subcarrier index, and N is a total number of subcarriers.

7. The method of claim 1, wherein the PRACH data for each CC is compensated by multiplying the PRACH data with the corresponding Comp(i) for each antenna.

8. The method of claim 1, wherein processing PRACH data comprises performing beamforming.

9. The method of claim 1, further comprising sending processed PRACH data to the DU.

10. The method of claim 1, wherein the compensation values for each CC are computed according to:Comp(i) = eA(j x 0(i)) x eA(j x 2TT X Af x n / N),where Comp(i) is the compensation value for the i-th antenna, 0(i) is a phase offset for the i-th antenna, Af is a frequency offset, n is a subcarrier index, and N is a total number of subcarriers.

11. The method of claim 1, wherein the compensation values for each CC are computed according to:Comp(i) = eA(j x 0(f)) x eA(j x 2n x Af x n / N) x eA(j x <p),where <p is a global phase offset.

12. A radio access network (RAN) system comprising:a Radio Unit (RU) configured to:receive a Physical Random-Access Channel (PRACH) control message associated with a plurality of component carriers (CCs);extract configuration information for each CC from the PRACH control message;compute compensation values for each CC based on the configuration information;write, by the RU, the compensation values to compensation memory; andprocess PRACH data for each CC using the compensation values.

13. The system of claim 12, further comprising a Distributed Unit (DU) configured to transmit the PRACH control message to the RU.

14. The system of claim 12, wherein the configuration information comprises a frequency offset and a PRACH subcarrier spacing (SCS) for each CC.

15. The system of claim 12, wherein the compensation values are antenna- calibrated (AC) compensation values.

16. The system of claim 12, wherein the compensation values are computed for a plurality of pipes for each CC.

17. The system of claim 12, wherein the compensation values for each CC are computed according to:Comp(i) = e^(j × (θ(i) + 2π × Δf × n / N)),where Comp(i) is the compensation value for the i-th antenna, θ(i) is a phase offset for the i-th antenna, Δf is a frequency offset, n is a subcarrier index, and N is a total number of subcarriers.

18. The system of claim 12, wherein the compensation values for each CC are computed according to:Comp(i) = e^(j × θ(i)) × e^(j × 2π × Δf × n / N),where Comp(i) is the compensation value for the i-th antenna, θ(i) is a phase offset for the i-th antenna, Δf is a frequency offset, n is a subcarrier index, and N is a total number of subcarriers.

19. A non-transitory computer readable medium storing instructions that, when executed by one or more processors, cause a radio access network (RAN) to:receive a Physical Random-Access Channel (PRACH) control message associated with a plurality of component carriers (CCs);extract configuration information for each CC from the PRACH control message;compute compensation values for each CC based on the configurationinformation;process PRACH data for each CC using the compensation values; write, by the RU, the compensation values to compensation memory; wherein the compensation values for each CC are computed according to:Comp(i) = e^(j × (θ(i) + 2π × Δf × n / N)),where Comp(i) is the compensation value for the i-th antenna, θ(i) is a phase offset for the i-th antenna, Δf is a frequency offset, n is a subcarrier index, and N is a total number of subcarriers.

20. The non-transitory computer readable medium of claim 19, wherein the compensation values for each CC are computed according to:Comp(i) = e^(j × θ(i)) × e^(j × 2π × Δf × n / N) × e^(j × φ), where φ is a global phase offset.

Images