Cloud radio access network agnostic to hyperscale cloud hardware

Abstract

A Cloud Radio Access Network (C-RAN) includes at least one cloud node. In a flexi-split architecture, the at least one cloud node implements at least a portion of L1 processing for a distributed unit (DU) using a first at least one processing core and L2 processing for the DU using a second at least one processing core. The L1 and L2 processing can be implemented in the same or different cloud node and/or server as each other. The L1 processing and the L2 processing communicate via a network functional application platform interface (nFAPI). The cloud node(s) also determine at least one self-configuration decision, based on an available hardware configuration, which indicates a number of processor cores needed to implement the C-RAN using the hardware configuration and/or a channel configuration for the C-RAN to use when exchanging RF signals with a plurality of UEs.

1 . A cloud radio access network (C-RAN) comprising:
 at least one cloud node implementing:
 at least a portion of layer-1 (L1) processing for a distributed unit (DU) using a first at least one processing core; 
 layer-2 (L2) processing for the DU using a second at least one processing core; and 
   wherein the L1 processing and the L2 processing are for an air interface used by the C-RAN to exchange radio frequency signals with at least one user equipment (UE);   wherein the L1 processing and the L2 processing communicate via a network functional application platform interface (nFAPI).   
     
     
         2 . The C-RAN of  claim 1 , wherein the at least one cloud node implements the L1 processing on a first cloud node and the L2 processing on a second cloud node. 
     
     
         3 . The C-RAN of  claim 1 , wherein the at least one cloud node implements the L1 processing and the L2 processing on a same cloud node. 
     
     
         4 . The C-RAN of  claim 1 , wherein the L2 processing converts data from a first protocol to a second protocol before transmitting to the L1 processing. 
     
     
         5 . The C-RAN of  claim 4 , wherein the L2 processing communicates with the L1 processing via nFAPI with a buffering window to align latency requirements of the L2 processing and the L1 processing. 
     
     
         6 . The C-RAN of  claim 4 , wherein a respective buffer for the L1 processing and the L2 processing accounts for delays caused by the converting of the data from the first protocol to the second protocol, transport latency between the L1 processing and the L2 processing, and L1 polling between the L1 processing and the L2 processing. 
     
     
         7 . The C-RAN of  claim 1 , wherein the at least a portion of the L1 processing comprises processing for any of the following: a Physical Downlink Shared Channel (PDSCH), a Physical Downlink Control Channel (PDCCH), a Physical Uplink Control Channel (PUCCH), a Sounding Reference Signal (SRS), a Physical Broadcast Control Channel (PBCH), a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSS), a Cell Specific Reference Signal (CS-RS), a Tracking reference Signal, a Demodulation Reference Signal (DMRS), a Phase Tracking Reference Signal, a Physical Uplink Shared Channel (PUSCH), scheduling, and a Physical Random Access Channel (PRACH). 
     
     
         8 . The C-RAN of  claim 1 , wherein the at least a portion of the L1 processing comprises processing for any of the following: the nFAPI interface, a Sounding Reference Signal (SRS), a Synchronization Signal Block (SSB), and a fronthaul interface between the at least one cloud node and at least one remote unit using nFAPI. 
     
     
         9 . The C-RAN of  claim 1 , wherein the at least a portion of the L1 processing comprises any of the following: channel coding, resource element mapping, MIMO mapping, scrambling, and modulation. 
     
     
         10 . The C-RAN of  claim 1 , wherein the L2 processing comprises processing for any of the following: Medium Access Control (MAC), Radio Link Control (RLC), MAC scheduling. 
     
     
         11 . The C-RAN of  claim 1 , wherein the L2 processing comprises processing for any of the following: Hybrid Automatic Repeat Request (HARD), Physical Random Access Channel (PRACH), and the nFAPI interface. 
     
     
         12 . The C-RAN of  claim 1 , further comprising at least one remote unit that exchanges the radio frequency signals with the at least one UE, wherein the at least one remote unit performs additional layer-1 processing comprising any of the following: digital-to-analog conversion, RF upconversion, RF downconversion, amplification, radiation, pre-coding, beamforming, and analog RF control processing. 
     
     
         13 . The C-RAN of  claim 1 , wherein the at least one cloud node further implements a central unit (CU) on a same or different cloud node implementing the L2 processing, the CU comprising a controller unit user-plane (CU-UP) portion and a controller unit control-plane (CU-CP) portion. 
     
     
         14 . The C-RAN of  claim 13 , wherein the CU-CP portion performs S1 interface processing, X2 interface processing, and Radio Resource Control (RRC) processing, wherein the CU-CP portion communicates with the second cloud node using the any of an F1-C interface, 5G NGc and 5G NGu interfaces, an S1-U interface, and an S1MME interface. 
     
     
         15 . The C-RAN of  claim 13 , wherein the CU-UP portion performs Service Data Adaptation Protocol (SDAP) processing and Packet Data Convergence Protocol (PDCP) processing, wherein the CU-UP portion communicates with the second cloud node using an F1-U interface. 
     
     
         16 . A method for layer-1 (L1) and layer-2 (L2) processing in a cloud radio access network (C-RAN) comprising:
 performing at least a portion of L1 processing for a distributed unit (DU) in at least one cloud node using a first at least one processing core;   performing L2 processing for the DU in the at least one cloud node using a second at least one processing core; and   wherein the L1 and L2 processing are for an air interface used by the C-RAN to exchange radio frequency signals with at least one user equipment (UE);   wherein the L1 processing and the L2 processing communicate via a network functional application platform interface (nFAPI).   
     
     
         17 . The method of  claim 16 ,
 wherein performing at least a portion of the L1 processing for the DU comprises performing at least a portion of the L1 processing for the DU in a first cloud node;   wherein performing the L2 processing for the DU comprises performing the L2 processing for the DU in a second cloud node.   
     
     
         18 . The method of  claim 16 , wherein the L1 processing is performed on a same cloud node as the L2 processing. 
     
     
         19 . The method of  claim 16 , wherein the L2 processing comprises converting data from a first protocol to a second protocol before transmitting to the L1 processing. 
     
     
         20 . The method of  claim 19 , wherein the L2 processing communicates with the L1 processing via nFAPI with a buffering window to align latency requirements of the L2 processing and the L1 processing. 
     
     
         21 . The method of  claim 19 , wherein a respective buffer for the L1 processing and the L2 processing accounts for delays caused by the converting of the data from the first protocol to the second protocol, transport latency between the L1 processing and the L2 processing, and L1 polling between the L1 processing and the L2 processing. 
     
     
         22 . The method of  claim 16 , wherein the performing at least a portion of L1 processing comprises processing for any of the following: a Physical Downlink Shared Channel (PDSCH), a Physical Downlink Control Channel (PDCCH), a Physical Uplink Control Channel (PUCCH), a Sounding Reference Signal (SRS), a Physical Broadcast Control Channel (PBCH), a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSS), a Cell Specific Reference Signal (CS-RS), a Tracking reference Signal, a Demodulation Reference Signal (DMRS), a Phase Tracking Reference Signal, a Physical Uplink Shared Channel (PUSCH), scheduling, and a Physical Random Access Channel (PRACH). 
     
     
         23 . The method of  claim 16 , wherein the performing at least a portion of L1 processing comprises processing for any of the following: the nFAPI interface, a Sounding Reference Signal (SRS), a Synchronization Signal Block (SSB), and a fronthaul interface between the at least one cloud node and at least one remote unit using nFAPI. 
     
     
         24 . The method of  claim 16 , wherein the performing at least a portion of L1 processing comprises any of the following: channel coding, resource element mapping, MIMO mapping, scrambling, and modulation. 
     
     
         25 . The method of  claim 16 , wherein the performing L2 processing comprises processing for any of the following: Medium Access Control (MAC), Radio Link Control (RLC), MAC scheduling. 
     
     
         26 . The method of  claim 16 , wherein the performing L2 processing comprises processing for any of the following: Hybrid Automatic Repeat Request (HARD), Physical Random Access Channel (PRACH), and the nFAPI interface. 
     
     
         27 . The method of  claim 16 , further comprising:
 exchanging, using at least one remote unit, the radio frequency signals with the at least one UE; and   performing, at the at least one remote unit, additional layer-1 processing comprising any of the following: digital-to-analog conversion, RF upconversion, RF downconversion, amplification, radiation, pre-coding, beamforming, and analog RF control processing.   
     
     
         28 . The method of  claim 16 , further comprising performing layer-3 (L3) processing for a central unit (CU) on a same or different cloud node implementing the L2 processing, the CU comprising a controller unit user-plane (CU-UP) portion and a controller unit control-plane (CU-CP) portion. 
     
     
         29 . The method of  claim 28 , wherein performing, at the CU-CP portion, S1 interface processing, X1 interface processing, and Radio Resource Control (RRC) processing, wherein the CU-CP portion communicates with the second cloud node using the any of an F1-C interface, 5G NGc and 5G NGu interfaces, an S1-U interface, and an S1MME interface. 
     
     
         30 . The method of  claim 28 , wherein performing, at the CU-UP portion, Service Data Adaptation Protocol (SDAP) processing and Packet Data Convergence Protocol (PDCP) processing, wherein the CU-UP portion communicates with the second cloud node using an F1-U interface. 
     
     
         31 . A cloud radio access network (C-RAN) implemented at least partially using at least one node, the at least one node configured to:
 determine a hardware configuration available to implement at least some components and configuration of the C-RAN; and   determine, based on at least the hardware configuration, at least one self-configuration decision indicating any of the following:
 a number of processor cores needed to implement the C-RAN using the hardware configuration; and 
 a channel configuration for the C-RAN to use when exchanging radio frequency (RF) signals with a plurality of user equipment (UEs). 
   
     
     
         32 . The C-RAN of  claim 31 , wherein the at least one node is further configured to determine additional self-configuration decisions that indicate whether the available hardware configuration supports the following in light of the hardware configuration: a particular RF bandwidth, a particular duplexing scheme, a particular number of MIMO layers, a particular number of RUs, a particular number of UEs transmitting in each timing slot, a particular number of UEs that can be attached to the C-RAN at once. 
     
     
         33 . The C-RAN of  claim 31 , wherein the hardware configuration indicates any of the following: a number of processing cores available in the at least one node, a clock frequency of the processing cores, a make of a central processing unit (CPU) in the at least one node, an amount of memory available in the at least one node, Ethernet bandwidth supported in the at least one node, operating system implemented in the at least one node, virtualization support in the at least one node, Peripheral Component Interconnect Express (PCIe) configuration of the at least one node, and hardware acceleration supported in the at least one node. 
     
     
         34 . The C-RAN of  claim 31 , wherein the channel configuration indicates any of the following: an RF bandwidth, a number of radio resources allocated over a slot duration, a duplexing scheme, a number of MIMO layers, a number of RUs to support, a number of UEs per slot, and a number of UEs that can be attached to the C-RAN at once. 
     
     
         35 . The C-RAN of  claim 31 , wherein the self-configuration decision further indicates a number of processor cores needed to implement any of the following processing: Physical Downlink Shared Channel (PDSCH), a Physical Uplink Shared Channel (PUSCH), scheduling, and a Physical Random Access Channel (PRACH), a Physical Downlink Control Channel (PDCCH), a Physical Uplink Control Channel (PUCCH), a Sounding Reference Signal (SRS), a Physical Broadcast Control Channel (PBCH), a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSS), a Cell Specific Reference Signal (CS-RS), a Tracking reference Signal, a Demodulation Reference Signal (DMRS), and a Phase Tracking Reference Signal. 
     
     
         36 . The C-RAN of  claim 31 , wherein the self-configuration decision further indicates which containers will run on which processing cores and nodes. 
     
     
         37 . The C-RAN of  claim 31 , wherein the at least one node is further configured to assign a priority to each of a plurality of containers implementing the C-RAN based on latency constraints of processes implemented by the respective container, each container implementing at least one process. 
     
     
         38 . The C-RAN of  claim 37 , wherein different processes implemented by a same container are assigned different priorities based on the latency constraints of the different processes. 
     
     
         39 . The C-RAN of  claim 37 , wherein the at least one node is further configured to add or remove one or more of the containers based on any of the following: UE demand, demand on RAN workload, available resources at a given time for each container, and the priority of the container. 
     
     
         40 . The C-RAN of  claim 37 , wherein the at least one node is further configured to assign a higher priority to each container implementing at least one process subject to real-time constraints than for each container implementing at least one process not subject to real-time constraints. 
     
     
         41 . The C-RAN of  claim 40 , wherein the at least one node is further configured to add at least one PUSCH process in response to UE demand increasing. 
     
     
         42 . A method for self-configuring a cloud radio access network (C-RAN) implemented at least partially using at least one node, the method being performed by the at least one node, comprising:
 determining a hardware configuration available to implement at least some components and configuration of the C-RAN; and   determining, based on at least the hardware configuration, at least one self-configuration decision indicating any of the following:
 a number of processor cores needed to implement the C-RAN using the hardware configuration; and 
 a channel configuration for the C-RAN to use when exchanging radio frequency (RF) signals with a plurality of user equipment (UEs). 
   
     
     
         43 . The method of  claim 42 , further comprising determining additional self-configuration decisions that indicate whether the available hardware configuration supports the following in light of the hardware configuration: a particular RF bandwidth, a particular duplexing scheme, a particular number of MIMO layers, a particular number of RUs, a particular number of UEs transmitting in each timing slot, a particular number of UEs that can be attached to the C-RAN at once. 
     
     
         44 . The method of  claim 42 , wherein the hardware configuration indicates any of the following: a number of processing cores available in the at least one node, a clock frequency of the processing cores, a make of a central processing unit (CPU) in the at least one node, an amount of memory available in the at least one node, Ethernet bandwidth supported in the at least one node, operating system implemented in the at least one node, virtualization support in the at least one node, Peripheral Component Interconnect Express (PCIe) configuration of the at least one node, and hardware acceleration supported in the at least one node. 
     
     
         45 . The method of  claim 42 , wherein the channel configuration indicates any of the following: an RF bandwidth, a number of radio resources allocated over a slot duration, a duplexing scheme, a number of MIMO layers, a number of RUs to support, a number of UEs per slot, and a number of UEs that can be attached to the C-RAN at once. 
     
     
         46 . The method of  claim 42 , wherein the self-configuration decision further indicates a number of processor cores needed to implement any of the following processing: Physical Downlink Shared Channel (PDSCH), a Physical Uplink Shared Channel (PUSCH), scheduling, and a Physical Random Access Channel (PRACH), a Physical Downlink Control Channel (PDCCH), a Physical Uplink Control Channel (PUCCH), a Sounding Reference Signal (SRS), a Physical Broadcast Control Channel (PBCH), a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSS), a Cell Specific Reference Signal (CS-RS), a Tracking reference Signal, a Demodulation Reference Signal (DMRS), and a Phase Tracking Reference Signal. 
     
     
         47 . The method of  claim 42 , wherein the self-configuration decision further indicates which containers will run on which processing cores and nodes. 
     
     
         48 . The method of  claim 42 , further comprising assigning a priority to each of a plurality of containers implementing the C-RAN based on latency constraints of processes implemented by the respective container, each container implementing at least one process. 
     
     
         49 . The method of  claim 48 , wherein different processes implemented by a same container are assigned different priorities based on the latency constraints of the different processes. 
     
     
         50 . The method of  claim 49 , further comprising adding or removing one or more of the containers based on any of the following: UE demand, demand on RAN workload, available resources at a given time for each container, and the priority of the container. 
     
     
         51 . The method of  claim 49 , further comprising assigning a higher priority to each container implementing at least one process subject to real-time constraints than for each container implementing at least one process not subject to real-time constraints. 
     
     
         52 . The method of  claim 51 , further comprising adding at least one PUSCH process in response to UE demand increasing.