METHOD AND DEVICE FOR LONG TERM EVOLUTION OPERATION IN THE UNLICENSED AND SHARED SPECTRUM FOR CLOUD RADIO ACCESS NETWORKS

Abstract

Procedure, comprehensive: Transmitted from a lower layer of a baseband unit (BBU) to a layer of a remote radio unit (RRU) via a fronthaul interface of a data transmission at a destination subframe agreed upon between the BBU and the RRU, with the data being sent a number of milliseconds before the RRU performs an LBT (Listen Before Talk) step for the data, wherein a control unit (CU) of the BBU is configured to set a timer based on an end-to-end latency request of the traffic, and is configured to attempt transmission in an unlicensed band.

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS

[0001] The present invention claims priority from the preliminary US patent application No. 62 / 628,538 entitled METHOD AND APPARATUS FOR LTE OPERATION IN UNLICENSED AND SHARED SPECTRUM FOR CLOUD RADIO ACCESS NETWORKS, filed on February 9, 2018, which is incorporated herein by reference in its entirety.

[0002] The present invention also claims priority from the preliminary US patent application No. 62 / 659,546 entitled METHOD AND APPARATUS FOR LTE OPERATION IN UNLICENSED AND SHARED SPECTRUM FOR CLOUD RADIO ACCESS NETWORKS, filed on April 18, 2018, which is incorporated herein by reference in its entirety.

[0003] The present invention also claims priority from the preliminary US patent application No. 62 / 668,012 entitled METHOD AND APPARATUS FOR LICENSED-ASSISTED ACCESS (LAA) FOR CLOUD RAN AND FOR MULTI-LAA CELLS, filed on May 7, 2018, which is incorporated herein by reference in its entirety. BACKGROUND OF REVELATION 1. Territory of Revelation

[0004] The present disclosure relates to systems and methods for radio access networks. 2. Description of the related prior art

[0005] Traditionally, radio access networks (RANs) were built using an integrated unit that handled all RAN processing. The RAN network typically uses application-specific hardware for processing, making it difficult to upgrade and evolve. As future networks evolve toward massive network densification to meet increased capacity demands, there is a growing need to reduce the capital and operating costs of RAN deployment and to make the solution scalable and easy to upgrade.

[0006] Cloud-based radio access networks (C-RAN) are networks where a significant portion of the RAN layer processing takes place in a central unit (CU), also known as the baseband unit (BBU), located in the cloud on commercially available (commercial off-the-shelf) servers, while the critical RF and real-time functions can be processed in the remote radio unit (RRU) or distributed unit (DU).

[0007] Traditional RANs implement the protocol stack (e.g., physical layer, PHY, medium access control, MAC, radio link control, RLC, packet data convergence control) at the base station (also known as the eNodeB or eNB). In cloud RAN, various radio functions are distributed between the RRU and the baseband unit (BBU). RRUs are deployed locally, while the BBU is virtualized in the cloud, which could be hundreds of kilometers away from the RRU. A single BBU (or vRAN) can manage multiple RRUs in different locations.

[0008] Cloud-RAN provides centralization and virtualization of RAN networks, resulting in benefits such as (a) reduced operating costs due to pooling resources and running the network on universal hardware, thereby achieving economies of scale, (b) improved performance due to better fault management, (c) remote network upgradeability and management, and (d) easier migration for adding new features and easier transition from 4G to 5G networks.

[0009] In conventional Long-Term Evolution (LTE) operation in licensed bands, mobile network operators have the exclusive right to use the spectrum. They thus have complete control over termination, resource allocation, and spectrum access. With the development of new radio technologies and due to the exponential increase in demand for wireless communication over the last decade, there has been interest in recent years in extending LTE technologies to operate in unlicensed and shared spectrum. This interest arose particularly after the FCC opened new bands for unlicensed / shared operation in the 5 GHz UNII bands and other bands. Publication WO 2017 / 206102A1 describes a method and a device for implementing LBT in a distributed RRU-BBU architecture.Publication US 2017 / 0318594A1 discloses a wireless device that receives configuration parameters to indicate an allocation restriction of a logical channel. Additionally, publication WO 2017 / 135077A1 discloses an end device for performing an uplink transmission based on an uplink authorization. SUMMARY OF THE REVELATION

[0010] The present disclosure provides embodiments of a system, a method, and devices for LTE operation in the unlicensed bands, wherein a BBU is configured to terminate non-guaranteed bitrate (non-GBR) traffic on unlicensed cells and guaranteed bitrate (GBR) traffic on licensed cells. The BBU is further configured to terminate priority classes 3 and 4 on unlicensed cells, while priority classes 1 and 2 are terminated on licensed cells.

[0011] The present disclosure also provides embodiments of a system and a method for LTE operation in the unlicensed bands in the Cloud RAN framework, wherein a BBU on the Radio Link Control (RLC) layer is configured to retransmit failed packets that were originally transmitted on the unlicensed band on a licensed band.

[0012] The present disclosure further provides embodiments of a system and a method wherein a BBU is configured to set a timer based on an end-to-end latency request from the traffic and attempts transmission on an unlicensed band. After the timer expires, the BBU can be configured to retransmit the failed packets on licensed bands. The timer threshold can be set based on the expected duration a packet requires to be received at the UE, including the expected fronthaul latency, the expected listen-before-talk (LBT) latency, and other parameters.

[0013] The present disclosure further provides a system and a method for LTE operation in the unlicensed bands in which a dynamic frequency selection process (DFS process) is triggered by an LBT failure.

[0014] In one embodiment, the present disclosure provides a method, a system and equipment therefor, comprising: Transmitted from a lower layer of a baseband unit (BBU) to a layer of a remote radio unit (RRU) via a fronthaul interface, a data transmission at a destination subframe agreed upon between the BBU and the RRU, wherein the data is sent a number of milliseconds before the RRU performs a Listen Before Talk (LBT) step on the data, wherein a control unit (CU) of the BBU is configured to set a timer based on an end-to-end latency request of the data traffic and is configured to attempt the transmission on an unlicensed band.

[0015] In this embodiment, the CU can still be configured for the following: Transferred from the CU, an amount corresponding to the RRU buffer depth (B RU) the data at a CU transmission time threshold, at which the CU must transmit the data to the RRU so that it is transmitted over the air (OTA) at Tstart, (CUT th ); Transmitted, for the target subframe, of an LBT-PDSCH (Physical Downlink Shared Channel) request to the RRU; Determine if an LBT-PDSCH response is received from the RRU at the CU; Determine whether the LBT-PDSCH response is successful and, If the LBT-PDSCH response is successful, increment a CU transfer start time (T). start ) to a buffer depth of the RRU (T start = T start + B RU ) or Resetting the LBT step if the received LBT-PDSCH response is unsuccessful.

[0016] In this embodiment, the CU can still be configured for the following: Incrementing the CU transfer start time (T start) increase the buffer depth of the RRU (T start = T start + B RU ), if it is determined that the LBT-PDSCH response from the RRU is successful; Determine if the remaining data is smaller than the buffer depth of the RRU (B RU ) and, If this is the case, transfer the remaining data to the RRU at the CU transfer time threshold CUT. th , or If not, only the B is transferred. RU -Data amount to the RRU. If the CU determines that the LBT-PDSCH response from the RRU is not received at the CU, the CU is further configured to: Determine if a current time is the latest time at which the CU is expected to receive the LBT-PDSCH response from the RRU (T NOW = LBT TH ); If so, update the time at which the data should be transferred OTA (OTA T). start = T start + [B RU]), and proceed to determine if the LBT-PDSCH response from the RRU is not being received at the CU. If the CU determines that the current time is not the latest time at which the CU is expected to receive the LBT-PDSCH response from the RRU (T NOW = LBT TH The CU can also be configured to: Determine if the current time equals the CU transfer time threshold (CUT). th is, and: if so, transfer of data worth B RU ; or if not, re-determine whether the LBT-PDSCH response has been received.

[0017] In this implementation, the RRU can be configured for the following: Determine if an LBT-PDSCH (Physical Downlink Shared Channel) request is being sent from the CU; Starting an LBT spectrum sensing when the LBT-PDSCH request is received from the CU; Determine if an LBT timer for LBT spectrum acquisition has expired; and if the LBT timer has expired, send a failure message to the CU and terminate the LBT process, or If the LBT timer has not expired, determine that a current time is a start time (T start ) is and whether no channel was acquired; and if no channel was acquired, increment the T start to x(T start = T start + x) and continue with LBT spectrum acquisition. The RRU can further be configured to: determine whether a channel was acquired at time Tacq; and if no channel was acquired, discard all expired symbols from an RRU buffer and buffer any newly received data and continue with LBT spectrum acquisition. The RRU can further be configured to: If the channel has been acquired, send an LBT-PDSCH success message to the CU; Sending a reservation signal OTA up to the T start ; Sending buffered data OTA and updating T start as (T start = T start + B RU ); Determine if the buffered data is smaller than the buffer depth of the RRU B. RU and, If so, proceed with sending the buffered data OTA, and if the remaining buffered data is not smaller than the buffer depth of the RRU B RU , Sending the remaining buffered data OTA and performing a data reception check.

[0018] In one embodiment, the present disclosure provides a system comprising: a baseband unit (BBU) configured to calculate average utilization rates of all valid channel combinations and to select a channel with the minimum utilization rate when the difference between the two lowest average utilization rates is greater than a threshold.

[0019] In one embodiment, the present disclosure provides a method for an eNB as well as a system and devices therefor, comprising: Selecting a cell to add to a user equipment (UE) using a weighted sum of factors, wherein the selection involves checking a plurality of cell loads from both licensed and unlicensed cells according to a criterion; Testing a plurality of channel gains from both licensed and unlicensed cells according to the criterion; If all licensed channels are fully utilized, use unlicensed channels for new UEs, and Switching between UEs in licensed and unlicensed channels based on UE capabilities. The criterion can be selected from criteria that include the following: Determine whether a load on a licensed cell is less than a previously defined threshold, with the Enb adding the licensed cell to the UE if the load on the licensed cell is less than the previously defined threshold; and Determine whether the difference between the load of the licensed cell and the load of an unlicensed cell is less than a previously defined threshold, with the Enb adding the licensed cell to the UE if the difference between the load of the licensed cell and the load of the unlicensed cell is less than the previously defined threshold.

[0020] In one embodiment, the present disclosure provides a system comprising: A remote radio unit (RRU) configured to operate on an optimal channel from an unlicensed band, wherein the RRU is configured to perform periodic channel measurements and report these measurements to a control unit (CU) of a baseband unit (BBU); and wherein the CU is configured to use the measurements to select the optimal channel to use and reconfigures the RRU to use the selected optimal channel. The CU can be configured to issue instructions for dynamic frequency selection in accordance with Ro(fc*)≥Roth or P¯(fc*)≥Pth used to select an optimal channel based on RRU measurements.

[0021] In one embodiment, the present disclosure provides a system comprising: a baseband unit (BBU) comprising a control unit (CU) configured to send a pilot message to a remote radio unit (RRU) prior to a data link time to compensate for fronthaul latency; and wherein the RRU is configured to respond to the BBU with messages indicating a time at which the RRU can receive the pilot message; and wherein the CU is configured to adjust a transmission rate to the RRU based on the buffer size at the RRU and the fronthaul latency.

[0022] In one embodiment, the present disclosure provides a method, a system and equipment therefor, comprising: Transmitted from a lower layer of a baseband unit (BBU) to a layer of a remote radio unit (RRU) via a fronthaul interface, a Discovery Reference Signal (DRS) transmission; wherein a control unit (CU) of the BBU is configured to: Sending the DRS signal at a time DRS th,1 or at a time DRS th,2 ; Sending an LBT-DRS request to a target subframe for a Listen Before Talk (LBT) capture and Determine if a Discovery Measurement Timing Configuration (DMTC) offset time has elapsed; and If so, send the DRS transmission.

[0023] In this embodiment, the CU can also be configured for the following: When the CU determines whether the Discovery Measurement Timing Configuration (DMTC) offset time has elapsed, determine whether a current time DRS is available. th,1 or DRS th,2 is (Tnow = DRS th,1 or T now = DRS th,2 ?); and if so, send the DRS. The CU can also be configured to: when the CU determines that the current time is not the DRS time th,1 or the DRS time th,2 is (T now = DRS th,1 or T now = DRS th,2 ?), Determine if the RRU has received an LBT-DRS request; and if not, determine if the DMTC offset time has elapsed and continue the DRS transmission; When the CU determines that the RRU has received the LBT-DRS request, determine if the result is successful, and if so, terminate the DRS transmission; If the CU determines that the LBD-DRS request was unsuccessful, determine if the DMTC offset time has expired and proceed with the DRS transmission process.

[0024] In this embodiment, the RRU can be configured for the following: Determine if the DRS has been received, and if so, buffer the DRS; If the DRS was not received, continue listening for the DRS; If the DRS is buffered, determine if the RRU has received an LBT-DRS request from the CU and, If so, determine if the detection measurement time window (DMTC) offset time has elapsed, and if so, terminate the process. The RRU can be configured for the following: If the DMTC offset time has not elapsed, determine whether a new DRS has been received; if not, start an LBT spectrum acquisition at a configured time; When a new DRS is received, the existing buffered DRS is deleted and a new DRS is buffered, and LBT spectrum acquisition is started at the configured time. The RRU can also be configured to: determine if LBT spectrum acquisition is successful; if not, send an LBT DRS failure message to the CU; determine if the DMTC offset time has elapsed; if so, send an LBT DRS success message to the CU and transmit the DRS to the target device via an air interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Non-restrictive and non-comprehensive embodiments are described with reference to the following drawings. In the drawings, the same reference numerals in all the various figures refer to the same parts unless otherwise indicated. For better understanding, reference is made to the following detailed description, which should be read in conjunction with the accompanying drawings. Fig. Figure 1 is an example of a C-RAN system architecture and a functional fronthaul split. Fig. Figure 2 shows 8 options for splitting between a BBU and an RRU. Fig. 3 are different embodiments of an Intra-PHY split option. The Fig. Figures 4-10 are embodiments of data transmission supported by licensed-assisted access (LAA). Fig.11 is an embodiment of message transmission between a lower layer split CU and an RRU. Fig. 12 is an embodiment of message transmission between a lower layer split CU and an RRU. Fig. Figure 13 is a flowchart for an embodiment of a Physical Downlink Shared Channel (PDSCH) transmission algorithm for a CU. The Fig. 14A-14B are flowcharts for an embodiment of a PDSCH transmission algorithm for an RRU. The Fig. Figures 15-18 show examples of Fronthaul Normal Subframe (SF) support. Fig. Figure 19 shows examples of PDSCH transmission support. Fig. Figure 20 is a flowchart for an embodiment of a Discovery Reference Signal (DRS) transmission algorithm for a CU. Fig.Figure 21 is a flowchart for an embodiment of a DRS transmission algorithm for an RRU. Fig. Figure 22 shows an example of a DRS transmission for LBT. Fig. Figure 23 is a flowchart for an embodiment of a DRS transmission algorithm for a RU. Fig. 24 is an example of a DRS transmission for LBT. Fig. 25 is an embodiment for assigning LAA- and non-LAA-capable user equipment (UE) to licensed and unlicensed component carriers (CCs). Fig. 26 is an embodiment of a configuration and a method for adjusting the fronthaul rate. DETAILED DESCRIPTION OF THE EXECUTION FORMS

[0026] Reference is made to the 3GPP (Third Generation Partnership Project) system according to embodiments of the present disclosure. This application uses abbreviations, terms, and technologies defined in accordance with the 3GPP (Third Generation Partnership Project) technology standards, including the following standards and definitions. The 3GPP technical specifications (TS) and technical reports (TR), incorporated herein in full by reference, define the following related terms and architectural reference models. Abbreviations 3GPP: Third Generation Partnership Project ARQ: Automatic Repeat Request BBU: Baseband Unit BPSK: Binary Phase Shift Keying CA: Carrier Aggregation CBRS: Citizens Broadband Radio Services CC: Component Carrier CCA: Clear Channel Assessment CCE: Control Channel Element(s) CMS: Centralized Management System CoMP: coordinated multipoint transmission COTS: mass-produced (commercial off-the-shelf) CP: Cyclic prefix CQI: Channel Quality Indicator C-RAN: Cloud Radio Access Network CRC: Cyclic Redundancy Checking CRS: Cell-Specific Reference Signal CSAT: Carrier-sense adaptive transmission CSI: Channel State Information CSI-RS: Channel state information - reference signal CU / lls-CU: Central Unit. In this document, CU and lls-CU are used synonymously and refer to the central unit or processing unit in the cloud that communicates with an RU / RRU (Radio Unit / Remote Radio Unit). DCI: Downlink Control Indicator DFS: Dynamic Frequency Selection DM-RS: Demodulation - reference signal DRS: Discovery Reference Signals DMTC: Discovery Measurement Timing Configuration DL: Downlink DU: Distribution Unit EPC: LTE core structure (Evolved Packet Core) E-UTRA: LTE Air Interface (Evolved Universal Terrestrial Radio Access) eNB: Evolved Node B FDD: Frequency Division Duplex FEC: Forward Error Correction FFT: Fast Fourier Transform iFFT: Inverse Fast Fourier Transform ISM radio bands (Industrial, Scientific and Medical Radio Bands) HARQ: Hybrid Automatic Repeat Request HARQI: Hybrid Automatic Repeat Request Information IoT: Internet of Things JP: Joint Processing JR: Joint Reception KPI: Key Performance Indicator LAA: Licensed-Assisted Access LBT: Listen Before Talk lls: split on lower layer (lower-layer split) LCM: Life Cycle Management LTE: Long Term Evolution LTE-A: LTE Advanced MAC: Media Access Control MBSFN: Multicast Broadcast Single-Frequency Network MCOT: Maximum Channel Occupancy Time MCS: Modulation and Coding Scheme MIB: Master Information Block MIMO: Use of multiple transmit and receive points (Multiple Input, Multiple Output) MMSE-IRC: Minimum Mean Square Error (MQM) - Interference Rejection Combining MMSE-MRC: Minimum Mean Square Error - Maximum Ratio Combining mmWave: Millimeter wave MNO: Mobile Network Operator NR: New Radio OAM: Operation and Management OSS: Operator Service System OTA: Over-the-Air (OTA) PBCH: Physical broadcast channel PCFICH: Physical Control Format Indicator Channel PDCCH: Physical Downlink Control Channel PDCP: Packet Data Convergence Protocol PDSCH: Physical Downlink Shared Channel PHICH: Physical Hybrid ARQ Indicator Channel PHY: Bitübertragungsschicht (Physical Layer) LPHY: untere Bitübertragungsschicht (Lower Physical Layer) UPHY: obere Bitübertragungsschicht (Upper Physical Layer) PNF: Physical Network Function P-SS: Primary Synchronization Signal PUCCH: Physical Uplink Control Channel PUSCH: Physical Uplink Shared Channel QAM: Quadratur-Amplituden-Modulation QPSK: Vierphasen-Modulation (Quadrature Phase Shift Keying) RACH: Random Access Channel PRACH: Physical Random Access Channel REST API: Representational State Transfer Application Programming Interface RF: Radio Frequency Interface RI: Rank Indicator RLC: Radio Link Control RRC: Radio Resource Control RRM: Radio Resource Management RU / RRU: Radio Unit / Remote Radio Unit. In this document, RU and RRU are used synonymously. RS: Reference Signal RSSI: Received Signal Strength Indicator SCell: Secondary Cell SF: Subframe SFN: System Frame Number SIMO: Single Input, Multiple Output SINR: Signal-to-Interference-Plus-Noise Ratio SON: self-organizing network SRS: Sounding Reference Signal S-SS: Secondary Synchronization Signal TB: Transport Block (Transport Block) TTI: Transmission Time Interval TDD: Time Division Duplex TPC: Transmission Power Control UCI: Uplink Control Information UE: User Equipment UL: Uplink UL DMRS: Uplink Demodulation Reference Signal ULSCH: Uplink Shared Channel UNII radio band: Unlicensed National Information Infrastructure radio band (UNII Radio Band) vBBU: Virtualized Baseband Unit VNF: Virtual Network Function

[0027] The present disclosure provides embodiments of systems, devices and methods for LTE operation in the unlicensed and shared spectrum for cloud RANs, such as licensed assisted access (LAA), MulteFire, Citizens Broadband Radio Services (CBRS) and the like.

[0028] The present disclosure relates to wireless data transmission over an air interface (OTA) using PDSCH transmission. However, it should be self-evident that the same procedures / methods are applied to other channels / signals (e.g., reference signals, control channels, and the like) that are multiplexed using PDSCH.

[0029] Fig.Figure 1 is an example of a C-RAN system architecture 100 and a functional fronthaul split 101 for the Cloud-RAN 100 with a central processing unit (CU) 102 containing a BBU 103 or BBU pools 103 and one or more distributed units (DUs) 104, including an RRU / RU. The BBU pools 103 can be interconnected with other BBU pools and connected to the EPC (Evolved Packet Core) network 106 via an S1 interface. The RRUs 105 connect a user device (UE) 107 to the network.

[0030] In order for the RRU 105 to operate in and access the unlicensed / shared spectrum, various module configurations are integrated into the Cloud-RAN and configured for functions such as carrier selection, Listen-Before-Talk (LBT), Dynamic Frequency Selection (DFS), reference signal transmission (e.g., Discovery Reference Signal or DRS), and the like.

[0031] Implementations such as those described here address the challenges of enabling LTE technologies in unlicensed bands. These challenges arise from the fact that the separation between different LTE layers can lead to communication latency between layers entering the BBU 103 and those entering the RRU 105. Uncertainty regarding spectrum access due to spectrum capture, especially when combined with the fronthaul latency in the BBU 103-RRU 105 link, presents a further problem for C-RAN. One of the main limitations of LAA is that an RRU 105 is configured to take over the spectrum immediately after LBT success (i.e., within a 9 µs capture window) to prevent other Wi-Fi / eNBs from using the channel.Implementations such as those described here address the fronthaul latency (from a few hundred microseconds to a few milliseconds) for implementing LAA in C-RANs.

[0032] This disclosure provides embodiments of systems, methods, and devices or apparatuses for enabling LTE operation in unlicensed / shared spectrum by splitting at a lower layer (intra-PHY, MAC-PHY, and the like) between the CU 102 and the DUs 104. These embodiments maximize transport efficiency and provide the flexibility to support many of the features required for the virtualization and commercialization of C-RAN technology. While this disclosure describes embodiments for using unlicensed spectrum for LTE operation with C-RAN, various embodiments are also applicable to licensed LTE operation with C-RAN. Similarly, various embodiments are applicable to unlicensed LTE operation with conventional RANs as well as with C-RANs.

[0033] In conventional LTE networks, the LTE functionalities and the layers of the LTE protocol stack reside in the eNB small cell, which is deployed on-site. The C-RAN solution (i.e., splitting the BBU 103 and the RRU) offers several advantages compared to conventional LTE networks.

[0034] C-RAN offers mobile network operators (“MNOs”) the flexibility to optimize system performance in real time by varying different configuration and system parameters using the cloud-based infrastructure.

[0035] With the emergence of new wireless technologies and standards, MNOs need to upgrade their eNB small cells, which is typically very expensive. With C-RAN, most LTE functions in the BBU 103 can be software-based, making it easy to update as new wireless technologies emerge. This significantly reduces upgrade costs.

[0036] Having a software-based BBU 103 in the cloud has further advantages, such as the flexibility to add new services and the significant reduction in operating and management costs (OAM).

[0037] To enable the C-RAN solution, the LTE functionalities must be split between the BBU 103 in the cloud and the RRU 105 on-site.

[0038] 3GPP has defined 8 options for the split between the BBU 103 and the RRU 105 in TR 38.801 V14.0.0 (2017-03), as described in Fig. 2 are shown, with each set of arrows indicating the division between the layers in the CU 102 on the right and the DU 104 on the left: Option 1

[0039] -RRC is in CU 102. PDCP, RLC, MAC, physical layer and RF are in DU 104. Option 2

[0040] RRC and PDCP are located in the central processing unit. RLC, MAC, physical layer, and RF are located in the DU 104. Option 3 (Intra-RLC split)

[0041] The low RLC (a sub-function of the RLC), MAC, physical layer, and RF are located in the Distributed Unit. PDCP and high RLC (the other sub-function of the RLC) are located in CU 102. Option 4 (RLC-MAC split)

[0042] The MAC, physical layer, and RF are located in the Distributed Unit. PDCP and RLC are located in CU 102. Option 5 (Intra-MAC split)

[0043] The RF, physical layer, and part of the MAC layer (e.g., HARQ) are in DU 104. The upper layer is in CU 102. Option 6 (MAC-PHY split)

[0044] The physical layer and RF are in DU 104. The upper layers are in CU 102. Option 7 (Intra-PHY-Split)

[0045] Part of the functionality of the physical layer and RF is in DU 104. The upper layers are in CU 102. Option 8 (PHY-RF split)

[0046] -The RF functionality is in the DU 104 and the upper layer is in the CU 102.

[0047] There are several factors that influence the choice of fronthaul split option.

[0048] Bandwidth: Different split options have varying bandwidth requirements, which ultimately plays a role in determining the fronthaul design. For example, Option 8 (PHY-RF split) places very high demands on fronthaul bandwidth, which can lead to higher resource consumption and increased costs in transport sizing (link capacity, equipment, and the like). On the other hand, one of the advantages of Option 5 (Intra-MAC split) is that it reduces the bandwidth required for fronthaul.

[0049] Latency: In the LTE protocol stack, the split between BBU 103 and RRU 105 affects latency. For example, a split between L3 and L2 in Option 1 has very low latency requirements. This split option is helpful for handling some edge computing or low-latency use cases where user data needs to be close to the point of transmission. Another example is split option 3 within the RLC layer. The split in Option 3-1 is more sensitive to latency than the split with ARQ in DU 104 because retransmissions are subject to transport network latency across a split transport network. In contrast, Option 3-2 is insensitive to the transport network latency between CU 102 and DU 104. In split option 5 (Intra-MAC), time-critical functions reside in the low-MAC sublayer, including functions with stringent delay requirements (e.g.,HARQ) or functions where performance is proportional to latency (e.g., radio channel and signal measurements from the PHY, Random Access Control) are included. This allocation helps to reduce the latency requirements at the fronthaul interface. In contrast, Option 8 places very high demands on fronthaul latency, which can lead to limitations regarding network deployments in terms of network topology and available transport options.

[0050] Implementation costs: Higher splits generally have higher implementation costs compared to lower splits, as lower splits allow for more virtualization. For example, with split option 8, separating RF and PHY enables pooling of PHY resources, which can allow for more cost-effective sizing of the PHY layer. Separating RF and PHY allows operators to share RF components, which can reduce system and site costs. Conversely, high fronthaul bandwidth requirements result in higher resource consumption and increased transport sizing costs (link capacity, equipment, etc.).

[0051] Other factors include virtualization benefits, fronthaul interface complexity, expansion flexibility, computing power, and storage requirements.

[0052] Although the present disclosure provides the standardization of splitting option 7 (i.e., Intra-PHY-Split) as an example to illustrate the detailed aspects, the present disclosure is not limited to the example of splitting option 7 and is intended to include other splitting options mentioned above (e.g., splitting options 5, 6, and 8). Option 7 (Intra-PHY-Split)

[0053] Several implementations of this option are possible, including asymmetric configurations that independently lead to advantages for different sub-options for UL and DL (e.g., option 7-1 is used for UL and option 7-2 is used for DL). A compression technique may be able to reduce the required transport bandwidth between the DU 104 and the CU 102.

[0054] In the UL, FFT and CP distance are located in DU 104. The remaining functions are located in CU 103.

[0055] In the downlink, iFFT and CP addition are located in DU 104. The rest of the PHY is located in CU 103.

[0056] Fig. Figure 3 illustrates different embodiments of the Intra-PHY split option 7 and the associated advantages.

[0057] Options 7-1, 7-2 and 7-3 have the following in common: Options 7-1, 7-2, and 7-3 allow for the centralization of traffic aggregation between NR and E-UTRA transmission points. They can also facilitate the management of traffic load between NR and E-UTRA transmission points.

[0058] These options are expected to reduce fronthaul requirements in terms of data throughput.

[0059] Centralized scheduling is possible because the MAC address is located in CU 102 (e.g., CoMP). Joint processing (both transmit and receive) is also possible with these options, as the MAC address is located in CU 102. Option 7-1 Description:

[0060] In the UL, the FFT, CP removal and, if applicable, PRACH filtering functions are located in the DU 104, the rest of the PHY functions are located in the CU 102.

[0061] In the DL, the iFFT and CP addition functions are located in the DU 104, the rest of the PHY functions are located in the CU 102. Option 7-1 also allows the implementation of advanced receivers. Option 7-2 Description:

[0062] In the UL, the functions FFT, CP removal, resource demapping and, if necessary, pre-filtering are located in the DU 104, the remaining PHY functions are located in the CU 102.

[0063] In the DL, the functions iFFT, CP addition, resource mapping and precoding are located in the DU 104, the remaining PHY functions are located in the CU 102.

[0064] Option 7-2 enables the optimal use of advanced receivers. Option 7-3 (only for DL) Description:

[0065] Only the encoder is located in the CU 102 and the rest of the PHY functions are located in the DU 104.

[0066] This option can reduce fronthaul requirements in terms of data throughput compared to baseband bit rates, since the payload for Option 7-3 is encoded data.

[0067] For the purposes of this disclosure, the prior art does not provide any technological solutions that address, among other things, the configuration of the fronthaul interface between the UPHY and the LPHY in partitioning option 7. This disclosure describes embodiments that enable LTE operation in the unlicensed and shared spectrum for C-RANs. LAA

[0068] Carrier aggregation (CA) with at least one SCell operating in the unlicensed spectrum is referred to as LAA. Although this disclosure describes embodiments of technology for LAA, these embodiments are also applicable to other unlicensed spectrum technologies, such as Multefire, CBRS spectrum, and the like. In LAA, the configured set of serving cells for an UE therefore includes at least one SCell operating in the unlicensed spectrum according to the Type 3 framework structure, also referred to as the LAA SCell. Unless otherwise specified, LAA SCells function as regular SCells.

[0069] The 5150-5925 MHz range, or portions thereof, is / are potentially available for Licensed Assisted Access to unlicensed operation. This represents a substantial amount of spectrum that operators can use to expand their service offerings on licensed bands. The aforementioned range can be operated under a license-free scheme or ISM, but must be shared with existing mobile services and other established services.

[0070] The service quality offered by a licensed scheme cannot be achieved. Therefore, unlicensed access is considered complementary and, given the increasing demand for wireless broadband access, does not reduce the need for additional allocations for licensed operation. Different regulatory requirements exist for various regions and bands, as described in 3GPP TR 36.889 V13.0.0 (2015-06), which is incorporated herein in full by reference. 3GPP provides specifications that can work for all regions. LAA configuration

[0071] This text describes embodiments of an LAA configuration.

[0072] LAA provides a unified global solution framework that enables compliance with all regional legal requirements. A unified global solution framework for LAA is defined, where appropriate, to ensure that LAA can be operated in accordance with all regional legal requirements. Furthermore, the LAA design should be sufficiently configurable to allow efficient operation across different geographic regions. LAA configurations ideally aim for fair coexistence with existing Wi-Fi networks, so that they do not impact Wi-Fi services in terms of data throughput and latency more than an additional Wi-Fi network on the same carrier. The LAA configuration ideally aims for fair coexistence between LAA networks provided by different operators, so that the LAA networks can achieve comparable performance in terms of data throughput and latency. LAA functionalities: Listen-before-talk (Clear Channel Assessment).

[0073] The Listen-Before-Talk (LBT) procedure is defined as a mechanism by which a user device performs a Clear Channel Assessment (CCA) check before using the channel. The CCA uses at least energy sensing to determine the presence or absence of other signals on a channel, thus establishing whether a channel is occupied or free. European and Japanese regulations mandate the use of LBT in unlicensed bands. Beyond legal requirements, carrier sensing via LBT is a way to fairly share the unlicensed spectrum and is therefore a feature of fair and cooperative operation in the unlicensed spectrum within a single global solution framework. Discontinuous transmission on a carrier with a limited maximum transmission duration.

[0074] Channel availability cannot always be guaranteed in the unlicensed spectrum. Furthermore, certain regions, such as Europe and Japan, prohibit continuous transmission and limit the maximum duration of a transmission burst in the unlicensed spectrum. Therefore, discontinuous transmission with a limited maximum transmission duration is a necessary functionality for LAA (Last-Time Access). Dynamic frequency selection for radar avoidance in certain bands / regions.

[0075] Dynamic Frequency Selection (DFS) is a legal requirement for some frequency bands, e.g. to detect interference from radar systems and to avoid co-channel operation with these systems by selecting a different carrier on a relatively slow timescale. Carrier selection

[0076] Because there is a large available bandwidth of unlicensed spectrum, LAA nodes must perform carrier selection to choose carriers with low interference and achieve good coexistence with other deployments in the unlicensed spectrum. Transmit power control

[0077] Transmit Power Control (TPC) is a legal requirement in some regions, which requires the transmitting device to be able to reduce its transmit power by a ratio of 3 dB or 6 dB compared to the maximum nominal transmit power. RRM measurements including cell identification

[0078] Radio Resource Management (RRM) measurements, including cell identification, enable mobility between SCells and robust operation in the unlicensed area.

[0079] Automatic Gain Control (AGC) setting, coarse synchronization, frequency / time fine estimation at least for demodulation, channel state information (CSI) measurement, including channel and interference.

[0080] These are used to perform RRM measurements and for the successful reception of information on the unlicensed tape. Discovery Reference Signal (DRS)

[0081] TS 36.211 V14.3.0 (2017-06) describes DRS as supporting the switching on / off of small cells, including the ability to switch off secondary CCs, except for periodic DRS transmissions. DRS is used by the UE to perform mobility measurements and maintain synchronization. The signals that comprise DRS include PSS, SSS, CRS, and, where applicable, CSI-RS.

[0082] The UE is configured with a Discovery Measurement Timing (DMTC) configuration, which is a time window in which the UE can expect to receive the DRS.

[0083] Although a DRS event can occur at any point in the DMTC, the UE can assume that the DRS is transmitted from a given cell in such a way that the duration between successive DRS transmissions is fixed (e.g. 40, 80 or 160 milliseconds).

[0084] LBT regulations in some regions may allow the DRS to be transmitted as a short control transmission without LBT (however, this is not permitted in some regions, e.g. Japan).

[0085] DRS are also used in LAA (which precedes CCA) and form the basis for radio resource management, including cell identification.

[0086] When LBT is applied to DRS transmissions, there may be some cases where the DRS cannot be transmitted periodically (e.g., DRS transmitted on a cell within the licensed spectrum). The following two options can then be considered for the DRS design for LAA. 1) Under LBT, DRS is transmitted at a fixed time position in the configured DMTC. 2) Under LBT, the DRS may be transmitted at at least one of different time positions in the configured DMTC.

[0087] Two cases for DRS transmission. Case 1:

[0088] If the DRS is transmitted together with the PDSCH: it is automatically subject to LBT CAT 4.

[0089] Simultaneous transmission (or multiplexing) of a DRS and a PDSCH is only possible in subframes 0 and 5. Case 2:

[0090] If the DRS is not part of a transmission burst, the DRS must be preceded by a 25 µs spanning CCA (i.e., LBT CAT 2).

[0091] Because the exact time at which the DRS is transmitted depends on the CCA, the detection signal can drift in time, and the instrument must detect whether a DRS is being transmitted or not before basing measurements on it. This is not required in licensed spectrum.

[0092] In traditional RANs (or upper-layer splits), where the MAC, scheduler, PHY, and RF are all located in the same box, the RRU 105 competes for the spectrum using LBT techniques. Once the LBT is successful, the PHY informs the scheduler / MAC of the target subframe / slot at which transmission begins. The scheduler / MAC, in turn, sends the data to be transmitted OTA. The RRU 105 then transmits this data OTA. It can be seen that there is conventionally very little or no communication latency between the lower layers. With regard to the present disclosure, there is no work concerning the implementation of unlicensed LTE technologies for lower-layer splits. As can be seen, embodiments can also be applied to other unlicensed LTE technologies, such as MulteFire and CBRS.

[0093] Fig. 4 shows a shading code that is used in the following Fig. 4-10 is used. A prerequisite for supporting LAA in C-RAN with a non-ideal fronthaul is that the BBU 103 is forced to send the terminated data to the RRU 105 in advance. The reason for this is that the RRU 105 should acquire the channel (and send the data OTA) immediately after spectrum acquisition is complete (within 9 µs). Due to the presence of reference signals, data originating from the BBU 103 is TTI-specific (i.e., data transmitted in the TTI is a function of the specific TTI index). However, the BBU 103 does not know the specific TTI in which the RRU 105 begins transmission, as this depends on several random variables, such as the number of eNB and Wi-Fi APs sharing the spectrum, the LBT result, interference channels, and the like.

[0094] In the Fig.Figures 4-10 describe embodiments of methods for handling the non-ideal LAA support described above. Let MCOT = N ms (e.g., N = 8 ms for priority classes 3 and 4 when Wi-Fi is allowed to use the channel). The RRU 105 transmits for only, for example, 7 ms, since the first subframe is typically wasted sending reservation signals after LBT success. Assumption: no partial subframes. Although the following figures use N = 8 as an example, the embodiments are not limited to a specific priority class or MCOT duration.

[0095] It should also be noted that some of the following exemplary embodiments apply not only to data transmission but also to DRS transmission. The DRS duration is much shorter than for data (approximately 12 OFDM symbols < 1 ms). Design 1:

[0096] Fig.Figure 5 shows an embodiment in which L2 (BBU) sends N - 1 ms data to the LPHY (RRU) via the fronthaul interface. This data is assembled based on the assumption that the OTA transmission only starts at a specific, predefined subframe. In this example, the data transmission starts, for instance, at subframe 0, but both BBU 103 and RRU 105 can agree on any other subframe index.

[0097] This data is sent a few milliseconds before the RRU 105 is scheduled to perform the LBT. For example, the BBU 103 can send the data to the RRU 105, say, 30 ms before the start of the LBT process for that specific data.

[0098] In each LTE frame, the RRU 105 competes for the channel at the beginning of the subframe preceding the target subframe for data transmission. In this example, the RRU 105 competes in subframe 9 of each frame.

[0099] If the RRU 105 gains access before the end of subframe 9, it will next send a reservation signal until the end of subframe 9 and then transmit the N - 1 subframes OTA.

[0100] If the RRU 105 does not gain access before the end of subframe 9, it remains silent and competes again in the following 9th subframe.

[0101] Exemplary advantages of this implementation include a simple scheduler design, where a fixed amount of terminated data is guaranteed and subframes are not dropped. Another advantage is optimized operation when no other technology shares the spectrum, as few subframes are wasted.

[0102] From another perspective, the method can be applied to DRS transmission. The DRS position is fixed to a specific subframe (e.g., subframe 0 in each DMTC period). The BBU 103 sends the DRS signal to the RRU 105 one or two subframes before the terminated subframe (e.g., subframe 8). The RRU 105 competes for the channel at the preceding subframe (e.g., subframe 9). If the channel is idle, the RRU 105 sends the DRS signals, for example, at subframe 0. If the channel is occupied, the RRU 105 skips the DRS transmission and again competes for the channel after DMTC. Design 2:

[0103] Fig.Figure 6 shows an embodiment in which L2 in the BBU 103 sends data, for example with a value of 10 ms, to the LPHY in the RRU 105 via the fronthaul interface. The RRU 105 competes for the channel as soon as it receives the DL data in any subframe (i.e., there are no restrictions regarding the subframe used for LBT).

[0104] After the RRU 105 gains channel access, it drops the 10 - N + 1 subframes that do not overlap with the OTA transmission and transmits the remaining N - 1 subframes. For example, if the RRU 105 receives idle LBT on subframe 7 (assuming N = 8), the RRU 105 drops 3 subframes (subframes 5, 6, and 7) and transmits on subframes 8, 9, 0, 1, 2, 3, and 4.

[0105] An RLC layer is configured to handle dropped subframes and retransmit them on licensed carriers.

[0106] One exemplary advantage of the embodiment is, for example, that the RRU 105 competes for the channel at any given time, therefore there is no latency in spectrum acquisition and a higher spectrum efficiency is achieved.

[0107] In another aspect of the embodiment, assuming an MCOT of 10 ms (as an example), the BBU 103 sends 10 ms of data to the RRU 105. The RRU 105 competes for the channel at any given time as soon as it receives the data from the BBU 103. The RRU 105 then reorganizes the data based on the subframe at which it gains access to the channel. If the RRU 105 begins transmission on subframe 3 (as an example), it appends the data terminated for subframes 0, 1, and 2 to the end of the MCOT. In this case, the RRU 105 transmits subframes 3-9, then subframes 0, 1, and 2. Design 3:

[0108] Fig.Figure 7 shows an embodiment which is a modification of embodiment 2.

[0109] The RRU 105 drops 3 subframes (assuming N = 8) for each frame based on the LBT success time. In embodiment 3, the RRU 105 queues these subframes in a buffer. The RRU 105 then competes again for a smaller MCOT (to transmit the dropped subframes) whenever an opportunity arises (e.g., no data in the RRU 105's buffer, no strict latency requirements for regular data in the RRU 105's buffer, and the like). Since the queued data (left over from previous frames) is assembled for transmission on specific subframes, the RRU 105 can use the proxy / reservation signal to block the channel until the target time occurs.

[0110] The RRU 105 places dropped subframes into a corresponding OTA subframe for the correct positioning of reference signals and a PDCCH-CCE index. Additionally, the RRU 105 can block the channel between subframes based on the subframe index of the remaining data. If data is present in the RRU 105's buffer, the RRU 105 can aggregate and transmit the dropped subframes as soon as subframes can be aggregated into a single MCOT (or in a transmission shorter than the MCOT). The RRU 105 can maintain two buffers: one for traditional data and another for aggregated subframes.

[0111] One exemplary advantage of this embodiment is, among others, that the RRU 105 competes for the channel at any given time, resulting in no latency in spectrum acquisition and increased spectrum efficiency. Another exemplary advantage is the reduced probability of subframes being dropped. Design 4

[0112] Fig. Figure 8 shows an embodiment in which the reference signals are generated in the RRU 105 instead of the BBU 103. L2 (BBU 103) sends only PDSCH to L1 (RRU 105), with all resource elements (REs) for reference signals being empty (PSS / SSS / CRS and the like). The RRU 105 assembles these reference signals based on the time at which it gains access to the channel.

[0113] One exemplary advantage of the embodiment is high spectrum efficiency (no latency for measurement, no dropped subframes). Design 5

[0114] Fig. Figure 9 shows an embodiment which is a modification of embodiment 2.

[0115] The RRU 105 employs more intelligent subframe dropping from a transmission burst. The BBU 103 sends (for example) 10 ms of data to the RRU 105 via the fronthaul interface. The RRU 105 continuously transmits data from transmission bursts, dropping one subframe for LBT each time. In this case, if a channel is available, only one subframe is dropped, reducing the RLC overhead. If the channel is occupied, the RRU 105 drops the subframes that were terminated during the LBT process (in Fig. 6. For example, RRU 105 drops subframes 5-9. Data dropped at RRU 105 can be recovered through RLC retransmissions triggered by UE RLC NACKs. RLC retransmissions are always performed on a licensed primary cell. Design 6

[0116] Fig. Figure 10 shows an embodiment in which the fronthaul delay is assumed to be known and to be 10 ms.

[0117] The expected time required to gain access to the channel is estimated, i.e., the LBT delay profile – as explained below. Multiple copies (e.g., 3 copies) of the TBs for the MCOT duration are sent to RRU 105 based on the delay profile (most probable delays). RRU 105 holds the multiple copies in different queues. Based on the actual time access to the channel is gained, RRU 105 selects the correct queue and sends the data to the UE. RRU 105 updates BBU 103 with respect to the selected copy so that BBU 103 knows when to expect the HARQ ACK (note that the HARQ ACK does not have a process number).

[0118] It is noted that the BBU 103 receives the RRU 105 update (i.e., which copy was transmitted) before the corresponding HARQ ACK reaches the MAC address at the BBU 103 from the licensed carrier (which is transmitted 4 ms after data reception at the UE). This assumes that the variance of the fronthaul delay is very small.

[0119] In various embodiments, this configuration and method can be used for low-traffic cases (a small number of UEs with low usage) or applications (e.g., IoT).

[0120] One exemplary advantage of this embodiment is its high spectrum efficiency. LBT delay profile. First: Offline phase:

[0121] An LBT delay profile can be empirically estimated offline for different environments and interference conditions (e.g., number of neighboring Wi-Fi STAs, indoor vs. outdoor location, etc.). For each delay profile, there is a LUT for the number of copies and delay taps (for example, 3 copies for n - 2, n, and n + 2, where n is the subframe index based on the online expected LBT delay). Second: Online phase, assessment based on the history:

[0122] During startup, the RRU 105 executes the LBT code internally (i.e., listens for the medium without actual transmission) and receives an estimate of the actual LBT delay. Measurements are signaled to the BBU. Periodically, and in low-traffic scenarios, the RRU 105 repeats the measurements and the report to the BBU. Transfer phase:

[0123] The RRU 105 checks the operating conditions and selects the appropriate delay profile, number of copies, and delay taps. Model 7

[0124] In embodiment 7, embodiment 6 is a modification. Instead of sending multiple copies of the same data with different transmission start times, the vBBU 103 can send different data streams with different transmission start times to the RRU 105. After gaining access to the channel, the RRU 105 selects the stream that best matches the start TTI. After completing the selection process, the RRU 105 reports the selected data stream to the vBBU 103. Whenever a data stream becomes stale, the vBBU 103 is also updated. The vBBU 103 updates its termination schedule based on the reports from the RRU 105 and re-terminates the stale data streams at the RRU 105 for new LAA transmissions. Once the packets have exceeded a certain delay threshold (waiting for transmission on unlicensed spectrum), they are retransmitted by the RLC layer on the licensed band. Design 8

[0125] In embodiment 8, the TTI-dependent bits on the RRU 105 are first modified. Then, the LBT delay is estimated. A single transmission (MCOT) is sent to the RRU 105 based on the best estimate. Along with the transmission, pointers to the TTI-dependent bits on the RRU 105 are sent, or changes required on the RRU 105 for different start times based on the LBT delay profile are sent. The RRU 105 then competes for the medium using LBT and waits for the idle result.

[0126] Once an idle result is received, (a) the RRU 105 either transmits the received MCOT as is (if the LBT delay estimate is accurate) or (b) modifies the TTI-dependent bits based on the pointers sent by the vBBU 103 to account for the change in the MCOT's start TTI (if any). The RRU 105 sends an update report to the vBBU 103 regarding the changes made at the RRU 105.

[0127] In the following embodiment, the following sections refer to the XRAN-FH.CUS.0-v01.00.02 (2018-04-04) standard, which is incorporated herein in its entirety by reference, with the section headings applying to Chapter 5, C-Layer Protocol. 5.3.2 LAA command transmission procedure

[0128] The LAA command transfer procedure is used to exchange C-layer messages between the lls-CU and the RU. The primary purpose of these messages is to support the LAA functionality in the RU / lls-CU. 5.3.2.1 LBT procedure

[0129] The LBT procedure is used to configure the RU with the parameters required to perform LBT prior to PDSCH or DRS OTA transmission. The RU must report the outcome of the LBT process (either success or failure) in the notification message.

[0130] Unlike licensed spectrum, where the RU can continuously transmit data or reference signals OTA, in unlicensed spectrum the RU can only transmit discontinuous data bursts (of length MCOT) or periodic DRS signals. In an embodiment as described in Fig.As shown in Figure 11, an "LBT_DL_CONFIG.request" message 10 is sent once before each OTA transmission on the LAA-SCell. This includes both DRS and PDSCH (i.e., MCOT burst) transmissions. The RU responds to each LBT_DL_CONFIG.request message 10 with the "LBT_DL.indication" message 12, which contains the LBT result.

[0131] For the DRS signal, the lls-CU first configures the RU with the DRS parameters (DMTC period and DMTC offset) via the M layer.

[0132] Before each DRS period, the lls-CU sends the LBT_DL_CONFIG.request message and the DRS signal. The RU performs LBT and transmits the DRS signal OTA. The RU must then send the LBT_DL.indication message.

[0133] The DRS signal can be transmitted via the fronthaul interface, similar to other reference signals such as PSS / SSS / CRS.

[0134] The following describes message fields and settings for message delivery that relate to Fig. 11 are described. 5.4 Elements for the C-Layer Protocol 5.4.1 General

[0135] C-layer messages are encapsulated using a two-layer header approach. The first layer has a common eCPRI header and corresponding fields used to specify the message type, while the second layer is an application layer containing the fields required for control and synchronization. Within the application layer, a "section" defines the characteristics of U-layer data to be transmitted or received by a beam, using a pattern ID. A LAA section type 7 is supported in the C layer for LAA messages. LAA messages, communicated bidirectionally between the lls-CU and the RU, enable LBT for PDSCH / DRS transmission. Initial carrier selection and dynamic frequency selection (DFS) are enabled by communicating a small number of messages between the lls-CU and the RU using the management layer (M layer).

[0136] Table 1 describes the section types supported in the C layer. Table 1 Section type Target scenario Notes 0 Unused resource blocks or symbols in downlink or uplink The RU indicates that certain resource blocks or symbols are not in use (idle periods, watch periods). Similarly, there are no associated U-layer messages with IQ data for this section type. The purpose is to inform the RU that transmissions may be paused during the specified idle interval, for example, to conserve energy or to provide an interval for calibration. 1 Most DL / UL radio channels Here, "most" refers to channels that do not require a time or frequency offset, as is needed for channels with mixed numerology. 2 Reserved for future use 3 PRACH channels and channels with mixed numerology Channels that require time or frequency offsets, or channels with a different numerology than the nominal SCS values 4 Reserved for future use 5 UE termination information (UE ID assignment to section) Provides scheduling information to the UE IDs 6 Channel information Sends UE-specific channel information from the lls-CU to the RU 7 LAA Messages communicated between the lls-CU and the RU in both directions to enable LBT for PDSCH / DRS transmission, initial carrier selection and dynamic frequency selection (DFS) 8-255 Reserved for future use

[0137] The fields of section type "7" used to support LAA are as follows: ▪ Common header fields ▪ dataDirection (Data Direction (gNB Tx / Rx)) field: 1 bit ▪ payloadVersion (payload version) field: 3 bits • Value = “1” should be set (1st protocol version for user data and time reference format) ▪ filterIndex (filter index) field: 4 bits ▪ frameld (frame identifier) ​​field: 8 bits ▪ SubframeId (Subframe Identifier) ​​field: 4 bits ▪ slotID (Slot Identifier) ​​field: 6 bits ▪ startSymbolid (start symbol identifier) ​​field: 6 bits ▪ numberOfsections (number of sections) field: 8 bits ▪ sectionType (section type) field: 8 bits • Value = “7” should be set ▪ Reserved (reserved for future use) field: 8 bits ▪ Section fields sectionId (section ID) field: 16 bits

[0138] A value of "0" should be used for LBT_DL_CONFIG.request 10 The following setting should be enabled: LBT_PDSCH_REQ ▪ handle (an unclear handling returned in the LBT_PDSCH_RSP) field: 16 bits ▪ deferFactor (shift factor when measuring slots, as described in 3GPP TS 36.213 section 15.1.1) field: 3 bits ▪ backoffCounter (LBT backoff counter when measuring slots, as described in 3GPP TS 36.213 section 15.1.1) field: 10 bits ▪ offset (LBT start time in microseconds from the start of the subframe terminated in this message): 10 bits ▪ MCOT (LTE TXOP duration in subframes) field: 4 bits ▪ txopSfnSfEnd (SFN / SF where TXOP must end) field: 12 bits ▪ IbtMode (part of multi-carrier support. Indicates whether the full LBT process is carried or a partial LBT process is carried (multi-carrier mode B according to 3GPP TS 36.213 section 15.1.5.2)) field: 1 bit: • 0 - full LBT (regular LBT) • 1 - Partial LBT (Looking back 25 µs before transmission, as specified in 3GPP TS 36.213 Section 15.1.5.2)

[0139] A value of "1" should be set for LBT_DL_CONFIG.request 10: LBT_DRS_REQ ▪ handle (an unclear handling returned in the LBT_PDSCH_RSP) field: 16 bits ▪ offset (LBT start time in microseconds from the start of the subframe terminated in this message): 10 bits ▪ sfnSfEnd (SFN / SF, where the DRS window must end) field: 12 bits ▪ IbtMode (part of multi-carrier support. Indicates whether the full LBT process is carried or a partial LBT process is carried (multi-carrier mode B according to 3GPP TS 36.213 section 15.1.5.2)) field: 1 bit: • 0 - full LBT (regular LBT) • 1 - partial LBT (looking back 25 µs before transmission, as specified in 3GPP TS 36.213 Section 15.1.5.2) ▪ Reserved (reserved for future use) field: 1 bit

[0140] A value of "2" should be set for LBT_DL.indication 12: LBT_PDSCH_RSP ▪ handle (an unclear handling returned in the LBT_PDSCH_RSP) field: 16 bits ▪ IbtResult (LBT result of SFN / SF) field: 1 bit • 0 - SUCCESS - indicates that the channel was successfully acquired. • FAILURE - indicates that the channel could not be acquired by SFN / SF at the end of the campaign. ▪ lteTxopSymbols (Actual LTE TXOP in symbols. Valid if LBT result = SUCCESS) field: 14 bits ▪ initialPartialSF (Indicates whether the first SF in the LBT process is complete or partial) field: 1 bit • 0 - full SF (two slots, 14 symbols) • 1 - partial SF (only second slot, the last 7 symbols)

[0141] A value of "3" should be set for LBT_DL.indication 12: LBT_DRS_RSP ▪ handle (an unclear handling returned in the LBT_PDSCH_RSP) field: 16 bits ▪ IbtResult (LBT result of SFN / SF) field: 1 bit • 0 - SUCCESS - indicates that DRS is being sent • 1 - FAILURE - indicates that DRS is not being sent ▪ Reserved (reserved for future use) field: 7 bits 5.4.5 Encoding of Information Elements - Application Layer, Sections

[0142] Descriptions and coding of information elements in the aforementioned fields are as follows: 5.4.5.19 handle

[0143] Description: This parameter provides a marker that is included in the configuration request message (e.g., LBT_PDSCH_REQ, LBT_DRS_REQ) sent from the lls-CU to the RU and returned in the corresponding response message (e.g., LBT_PDSCH_RSP, LBT_DRS_RSP). Value range: {0000 0000 0000 0000b-1111 1111 1111 1111b} Type: unsigned integer. Field length: 16 bits. 5.4.5.20 deferFactor (shift factor)

[0144] Description: Shift factor when measuring slots, as described in 3GPP TS 36.213, Section 15.1.1. This parameter is used for LBT CAT 4 and can take one of three values: {1, 3, 7} based on the priority class. Four priority classes are defined in 3GPP TS 36.213. Value range: {001b, 011b, 111b} or {1, 3, 7} in the decimal system. Type: unsigned integer. Field length: 3 bits. 5.4.5.21 backoffCounter (Backoff counter)

[0145] Description: LBT backoff counter for slot measurement, as described in 3GPP TS 36.213, section 15.1.1. This parameter is used for LBT CAT 4 and can take one of nine values: {3, 7, 15, 31, 63, 127, 255, 511, 1023} based on priority class. Four priority classes are defined in 3GPP TS 36.213. Value range: {3, 7, 15, 31, 63, 127, 255, 511, 1023} in decimal. Type: unsigned integer. Field length: 10 bits. 5.4.5.22 offset

[0146] Description: LBT start time in microseconds from the beginning of the subframe terminated by this message. Value range: {00 0000 0000b - 11 1110 0111b} or {0 - 999} in the decimal system Type: unsigned integer. Field length: 10 bits. 5.4.4.23 MCOT (Maximum Channel Occupancy Time)

[0147] Description: LTE TXOP duration in subframes, as described in 3GPP TS 36.213, section 15.1.1. This parameter can take one of four values: {2, 3, 8, 10} based on the priority class. Four priority classes are defined in 3GPP TS 36.213. Value range: {0010, 0011, 1000, 1010} or {2, 3, 8, 10} in the decimal system. Type: unsigned integer. Field length: 4 bits. 5.4.5.24 txopSfnSfEnd (TXOP-SFN / SF-End)

[0148] Description: SFN / SF, where TXOP must end Value range: SFN: {0000 0000b - 1111 1111b} or {0 — 255} in the decimal system, SF: {0000 — 1001} or {0 — 9} in the decimal system. Type: unsigned integer. Field length: 12 bits. 5.4.5.25 IbtMode (LBT mode)

[0149] Description: Part of the multi-carrier support. Indicates whether a full LBT process is carried or a partial LBT process is carried (multi-carrier mode B according to 3GPP TS 36.213, section 15.1.5.2). 0 - full LBT (regular LBT). 1 - partial LBT (review 25 µs before transmission, as specified in 3GPP TS 36.213, section 15.1.5.2). Value range: {0, 1} Type: unsigned integer. Field length: 1 bit. 5.4.5.26 sfnSfEnd (SFN / SF-End)

[0150] Description: SFN / SF, at which the DRS window must end Value range: SFN: {0000 0000b - 1111 1111b} or {0 — 255} in the decimal system, SF: {0000b - 1001b} or {0 — 9} in the decimal system. Type: unsigned integer. Field length: 12 bits. 5.4.5.27 IbtResult (LBT result)

[0151] Description: LBT result of SFN / SF. 0 - SUCCESS - indicates that the channel was successfully acquired. 1 - FAILURE - indicates that the channel could not be acquired by the end of the SFN / SF. Value range: {0,1} Type: unsigned integer. Field length: 1 bit. 5.4.5.28 lteTxopSymbols (LTE TXOP symbols)

[0152] Description: Actual LTE TXOP in symbols. Valid if LBT result = SUCCESS. Value range: For LTE {00 0000 0000 1110b - 000000 1000 1100b} or {14 - 140 symbols} in the decimal system. Type: unsigned integer. Field length: 14 bits. 5.4.5.29 initialPartialSF (Initial partial SF)

[0153] Description: Indicates whether the initial SF in the LBT process is full or partial. 0 - full SF (two slots, 14 symbols). 1 - partial SF (second slot only, last 7 symbols). Value range: {0, 1} Type: unsigned integer. Field length: 1 bit. Carrier selection (dynamic frequency selection)

[0154] Because LAA uses unlicensed spectrum for communication, which is shared with Wi-Fi and other technologies, RRU 105 must select the best channel to use from the unlicensed band (e.g., UNII band or band 46). This process must be performed initially (carrier selection) and periodically (dynamic frequency selection).

[0155] In another embodiment, as in Fig.As shown in Figure 12, a channel selection and a DFS procedure are used by the RU to report initial and periodic RRU 105 channel measurements 14 to the lls-CU 102. Based on the received measurements and other statistics collected during operation, the lls-CU 102 can send a cell reconfigure message 16 to reconfigure the LAA-SCell with a new unlicensed channel to operate on. The RRU 105 acknowledges 18 the receipt of the cell reconfigure message. In this embodiment, the procedure can be executed once for the initial carrier selection (i.e., before the OTA transmission). After the OTA transmission has started, this procedure can be executed periodically, as configured by the M layer.

[0156] To select the best channel, the RRU 105 performs periodic measurements and reports these measurements to the BBU 103. The RRU 105 can perform various measurements, such as calculating the average RSSI, the utilization rate, and the like.

[0157] The BBU 103 uses these measurements to select the "optimal" channel to use and then reconfigures the RRU 105 with the newly selected channel.

[0158] The BBU 103 receives two metrics from the LPHY in the RRU 105 for each channel f c ∈ A, where A is the set of channels in the unlicensed band (e.g. A = [5,745, 5,765, ..., 5,825] if the selected band is the UNII-3, which has five channels):

[0159] Capacity utilization rate R o (f c ): Percentage of the ON duration of the total measurement duration (e.g. 100 ms).

[0160] Average RSSI P(f c): Average RSSI over the entire measurement period.

[0161] Next, the present disclosure explains how L3 in BBU 103 initially selects the unlicensed channel or channels on which to work, and further explains how the Dynamic Frequency Selection (DFS) is performed periodically to reselect the best channel or channels while minimizing service interruption.

[0162] The present disclosure first describes the case of a single LAA-SCell and then moves on to the case of multiple cells. Single LAA-SCell Initial Carrier Selection

[0163] The selected channel fc* can be calculated using the following methods. For illustrative purposes, it is assumed that the BBU / RRU uses the UNII-3 band, which consists of five channels: fc*={argmin{Ro(fC1),Ro(fc2),…,Ro(fc5)},fc∈Aif (Ro(fcmin+1)−Ro(fcmin))>RoThGapargminfc∈A{P¯(fCmin),P¯(fcmin+1)},otherwise

[0164] This gives fc*min+1 the immediate f c with a higher occupancy rate or RSSI than the minimum and RoThGap is the threshold difference between the utilization rates (zBRoThGap=20%) Dynamic frequency selection

[0165] Implementations of configurations and methods for dynamic frequency selection (DFS) are described to avoid frequent frequency hopping.

[0166] In one embodiment (1) the DFS period is increased to a larger number (e.g. 10 s) and the main equation is applied (i.e. selection of the best channel in each DFS period).

[0167] In another embodiment (2), the RRU 105 continues to use the same channel until Ro(fc*)≥Roth or P¯(fc)≥pth. Once one of the conditions is met, the BBU 103 will be configured to operate using instructions for DFS in accordance with Ro(fc*)≥Roth or P¯(fc)≥pth works and selects the best channel based on the measurements of the RRU 105.

[0168] In another embodiment, the system operates similarly to the preceding embodiment (2), except that a restriction regarding the LBT delay is added. More precisely, the RRU 105 continues to use the same (initially selected) channel until the average LBT delay exceeds a previously defined threshold. Once this condition is met, the BBU 103 operates using instructions for DFS according to Ro(fc*)≥Roth or P¯(fc)≥pth and selects the best channel based on the measurements of the RRU 105.

[0169] This document describes embodiments of configurations and procedures in which the DFS period is a configurable parameter that can be changed by the BBU 103 based on channel availability.

[0170] Measurements could be carried out continuously by sniffers in RRU 105.

[0171] In one embodiment (1): the RRU 105 reports a summary of measurements averaged over a period of time. In this embodiment, the RRU 105 collects measurements locally for a period, processes them, and sends the final metrics to the BBU 103, which is to decide which channel to use. An exemplary advantage of this embodiment is that it reduces fronthaul overhead. The embodiment also adds more processing to the RRU 105.

[0172] In one embodiment (2): the RRU 105 continuously reports individual measurements to the BBU 103.

[0173] In one embodiment (3): the BBU 103 adapts the measurement report procedure based on the traffic, the processing capabilities of the RRU 105 and the like. Carrier aggregation (two or more LAA cells)

[0174] Implementation methods for carrier aggregation for a plurality of LAA-SC cells are described.

[0175] As can be seen, 3GPP TS 36.300 V14.3.0 (2017-06) specifies a standard limitation stating: “If the absence of IEEE 802.11n / 11ac devices sharing the carrier cannot be guaranteed long-term (e.g., due to the level of regulation) and if, for this version, the maximum number of unlicensed channels on which E-UTRAN can transmit concurrently is equal to or less than 4, the maximum frequency separation between any two carrier center frequencies on which LAA-SCell transmissions are carried out should be less than or equal to 62 MHz. The UE must support the frequency separation according to TS 36.133

[21] .” Consequently, combinations of 4 adjacent channels are permitted.

[0176] One embodiment of channel selection for the LAA-CA case is described using the example of the BBU / RRU, which uses the UNII-3 band. The UNII-3 band consists of 5 channels, as shown below in Table 1.

[0177] Based on the 3GPP restriction 3GPP TS 36.300 specified above, the BBU / RRU may have restricted combinations available when performing CA on unlicensed cells. For example, based on the example shown in Table 2, all two-channel combinations are permitted except for the pair (149, 165). For illustration, the aforementioned channels are described using channel indices 1, 2, ..., 5.

[0178] The selected channels FC* and FC** can be calculated as follows: (fc*,fc**)={argminfc∈A{(Ro(fc1)+Ro(fc2)2),(Ro(fc1)+Ro(fc3)2),…,(Ro(fc4)+Ro(fc5)2)},if (Ro¯(fcmin+1,f'cmin+1)−Ro¯(fcmin,f'cmin))>RoThGapargminfc∈A{βavg(fcmin,f'cmin),P¯avg(fcmin+1,'fcmin)},otherwise

[0179] The BBU 103 then calculates the average utilization rates of all valid channel combinations. If the difference between the two lowest average utilization rates exceeds a certain threshold, the BBU 103 selects the channel with the lowest utilization rate.

[0180] Otherwise, the BBU 103 goes to a second comparison level, where it selects the channel with the minimum average RSSI (from the two channels with the lowest utilization levels). Cell addition for LAA-enabled UEs

[0181] Implementation methods for adding cells to LAA-capable UEs are described.

[0182] One problem faced by LAA-enabled eNBs in a C-RAN architecture or in traditional RANs is cell addition for LAA-enabled UEs, including cases where both licensed and unlicensed cells are available. As described here, licensed spectrum is more reliable than unlicensed spectrum because, unlike unlicensed spectrum shared by different technologies, operators have exclusive usage rights. However, licensed spectrum is scarce and expensive, while unlicensed spectrum is plentiful and free.

[0183] This document describes embodiments that address cell addition in the licensed and unlicensed spectrum for LAA-enabled UEs. One embodiment, as described here, enables the eNB (or the BBU 103 in the C-RAN architecture) to select the best cell to add to the UE based on various metrics, such as cell load, channel status information (CSI), UE capabilities, and the like. For simplification, embodiments are described that assume the eNB attempts to add a second (licensed or unlicensed) cell to a UE that is already attached to the eNB using the licensed primary cell.

[0184] In one embodiment, the eNB considers a weighted sum of the following factors while selecting the cell to be added to the UE. In another embodiment, the process begins with a first step (i.e., loads in the cell) and then considers a second step (i.e., channel gains) only if the first step leads to an indeterminate decision (e.g., values ​​close to the thresholds).

[0185] In one embodiment (1), the eNB first checks the cell loads of both licensed and unlicensed cells. One criterion determines whether the load in a licensed cell is less than a predefined threshold (e.g., 70%), and the eNB adds the licensed cell to the UE. The reason for this selection is that licensed cells are more reliable than unlicensed cells and should be used whenever available. Another criterion can determine whether the difference between the load in the licensed and the unlicensed cell is less than a predefined threshold (i.e., both cells have comparable loads, e.g., within 20%), and the eNB adds the licensed cell to the UE. Otherwise, the unlicensed cell is added to the UE.

[0186] Next, (2) the eNB checks the channel gains of both the licensed and unlicensed cells and follows similar criteria as described above (1) when selecting the cell to add to the UE.

[0187] If all licensed channels are overloaded, then (3) the unlicensed channels can be used for new UEs that require more data throughput. At this point, the periodic switching of UEs back and forth between licensed and unlicensed channels is performed, taking into account the UE capabilities (i.e., legacy traffic versus Rel. 13-capable UEs). LBT parameter update

[0188] A characteristic of LTE in unlicensed bands (e.g., LAA) is the dependency between LBT parameters (e.g., contest window) and the UE HARQ feedback. RRU 105 must vary the contest window parameters based on LBT Category 4 rules (e.g., double the contest window on each collision).

[0189] In C-RAN systems, the LBT parameters are sent from the BBU 103 to the RRU 105 for each MCOT. This causes a problem for systems with a non-zero fronthaul latency, as the BBU 103 must send the LBT parameters to the RRU 105 before the HARQ even reaches the BBU. Several implementations are configured to address this issue.

[0190] In one embodiment, a false NACK message is used to update LBT parameters. In this embodiment, the RRU 105 updates the LBT parameters (e.g., the competition window) provided that a false NACK is received from the UE. For example, for priority class 3, the RRU 105 uses CW ~ [0,15] for the 1st attempt, [0,31] for the 2nd attempt, and [0,63] for > the 3rd attempt, until the current data stream ends.

[0191] In one embodiment, a HARQ ACK estimation message is based on the number of freeze times (N). FT ) during the LBT. In this embodiment, the RRU 105 internally estimates the HARQ feedback based on the number of timer freeze times during the LBT. For example, if N FT If ≤ 1, HARQ ACK is assumed; otherwise, HARQ NACK is assumed.

[0192] In one embodiment, a false NACK message is sent for LBT parameter updates until a first HARQ ACK / NACK is received. In this embodiment (assuming priority class 3), the RRU 105 CW uses approximately [0.15] for the first attempt, [0.31] for the second attempt, and [0.63] for the third attempt or higher. Once the first HARQ ACK / NACK message is received at the BBU 103, the LBT parameters are updated with a delay (due to fronthaul latency). This method is well-suited for cases where there is a high correlation between the HARQ ACK / NACK results of adjacent MCOTs.

[0193] In the following embodiments, the following sections refer, among other things, to the XRAN-FH.CUS.0-v01.00.02 (2018-04-04) standard, which is incorporated here in its entirety by reference.

[0194] RU / lls-CU messages are described in Table 3. Table 3 function RU / lls-CU message Direction of the message Layer xRAN Scheduling RU RU capability request downstream M Initial handshake (Ils-CU requests regarding RU capability) RU Ability Info (Support for LAA, Number of LAA cells, upstream M After each RU ability request message configuration Maximum RU buffer size in symbols (per CC), RU processing time, supported tapes, supported BW, etc.) RU Config (No. LAA-SCells, For each LAA CC: {DMTC period, DMTC offset, initial band, total carrier selection measurement duration, DFS measurement reporting period, LBT timer}) downstream M After each RU capability update. Reconfigure the RU with new parameters (e.g., measurement periods, etc.) as needed. Carrier selection and DFS startMeasurements: (carrier selection or DFS) downstream M Lls-CU orders the RU to start the measurements. stopMeasurements (only for DFS) downstream M Lls-CU orders the RU to stop the measurements. RU measurements upstream M After the RU has finished sampling all channels in the configured band cellConfig / Reconfig downstream M After the Ils-CU has received the RU measurements and when a new channel needs to be configured cellReconfigACK upstream M After the RU received the cell reconfiguration message LBT_DL_CONFIG. request: LBT_PDSCH_REQ downstream C Before each MCOT, to achieve the RU at / in front of the target SFN / SF for measurement. LBT LBT_DL_CONFIG. request: LBT_DRS_REQ downstream C Before each DRS, to reach the RU at / before the target SFN / SF for measurement LBT_DL.indication: LBT_PDSCH_RSP upstream C After each LBT for PDSCH (success or failure result, if the timer expires) LBT_DL.indication: LBT_DRS_RSP upstream C After each LBT for DRS (success or failure result if channel is occupied) bufferError (overflow or underflow) upstream C If the data received at the RU is larger than the RU buffer size, or if the buffer is empty at the destination transmission time

[0195] Although the disclosure describes in the examples given below that messages between the lls-CU and the RU can be communicated via the management layer (M layer), it should be clear and self-evident that this can also occur via the control layer (C layer). It should also be self-evident that these messages can also be transmitted between the RU and the DU 104, or the RU and the CU 102, or the RU and the lls-CU 102, depending on the C-RAN split used. Message details:

[0196] RU capability request (Management Layer or M-Layer): The lls-CU 102 sends a message to the RU requesting that it report its capabilities.

[0197] RU capability information (M-layer): The RU responds to the capability request message with its capabilities, such as whether it supports LAA or not, the number of LAA cells it can support, the maximum buffer size per component carrier (CC), the RU processing time, the supported bands, the supported bandwidths, and the like.

[0198] RU Config: The lls-CU configures the RU with the required parameters, such as the number of LAA CCs and the like. It also configures the RU for each unlicensed CC with the required parameters, such as the DMTC period, DMTC offset, default band to operate on, default total measurement duration of the carrier selection, default DFS measurement reporting period, LBT timer, measurements to be performed (e.g., utilization rate, average RSSI), and the like. It should be noted that other similar parameters could be added to the RU configuration message to help configure the RU with the default / required parameters. This can be sent initially (in the initial RU configuration) or during operation to reconfigure the RU.

[0199] Start Measurements: The lls-CU instructs the RU to start measurements for either carrier selection or DFS. This can be indicated by a single bit. The Start Measurement message also includes the bands and specific channels to be sampled or measured (e.g., by sending the carrier frequency in kHz or the EARFCN: Evolved-UTRA Absolute Radio Frequency No.). It also includes the total measurement duration (in the case of carrier selection) or the measurement reporting period (in the case of DF). It can also include the type of measurements to be performed (e.g., utilization rate, average RSSI, and the like). It can also contain any other information the RU needs to perform the measurements.

[0200] Stop Measurements: The lls-CU orders the RU to stop the DFS measurements.

[0201] RU Measurements: The RU reports the measurements to the lls-CU for each band and channel configured in the Start Measurement message. The reported measurements are taken for the identified measurement types (e.g., utilization rate, average RSSI, etc.).

[0202] A value of "n" should be set for RRU measurements. ▪ bandNumber (3GPP band number) field: 8 bits ▪ Carrier frequency (kHz) field: 32 bits ▪ averageRSSI field: 8 bits ▪ Occupancy Ratio (utilization level) field: 8 bits ▪ Carrier frequency (kHz) field: 32 bits ▪ averageRSSI field: 8 bits ▪ Occupancy Ratio (utilization level) field: 8 bits...

[0203] A value of "n" should be set for cell reconfig 16. ▪ Carrier frequency (kHz) field: 32 bits

[0204] A value of "n" should be set for cell reconfig ACK 18. ▪ ack (Acknowledgment, German:bestätigung) field: 1 bit bandNumber (Band number)

[0205] Description: 3GPP band number. Value range: {0000 0000b — 1111 1111b} Type: unsigned integer. Field length: 8 bits. carrierFrequencyKHz (carrier frequency in kHz)

[0206] Description: Carrier frequency in kHz when measurements are being taken. The upper limit is 52.6 GHz. Value range: {0 — 52600} in the decimal system. Type: unsigned integer. Field length: 16 bits. averageRSSI

[0207] Description: Average RSSI of the channel specified in the parameter carrierFrequencyKHz over the measurement period. Value range: {0000 0000b - 1111 1111b} or {0 dBm to -127 dBm} in the decimal system. Type: signed integer. Field length: 8 bits. Occupancy ratio (occupancy rate)

[0208] Description: Percentage of the ON duration of the total measurement duration (e.g., 100 ms) Value range: {0000 0000b — 0110 0100b} or {0 — 100} in the decimal system. Type: unsigned integer. Field length: 8 bits. Carrier frequency utilization rate R o (f c ): Ro(fc)=TONTON+TOFF ack (Acknowledgment, German:bestätigung)

[0209] Description: Acknowledgment 18 for receiving the cell reconfig message 16. Value range: {0,1} Type: unsigned integer. Field length: 1 bit. Definitions / Assumptions: General Assumptions

[0210] D owMaximum one-way fronthaul latency (e.g., up to 500 µs).

[0211] P CU : Maximum lls-CU processing time (reading a C-layer message from an upstream RU, MAC processing, sending the downstream U-layer data) (e.g.: up to 1 ms).

[0212] P RU : Maximum RU processing time (sending an upstream C-layer message, receiving downstream U-layer data, transmitting U-layer data OTA) (e.g., up to 1 ms).

[0213] B RU RU buffer depth (for LAA), limited to an integer number of OFDM symbols in µs (up to 140 symbols (e.g., MCOT)). This corresponds to the minimum amount of data that must be buffered at the RU. This parameter could be less than or equal to the actual RU buffer size sent in the LAA RU capability information.

[0214] Each RU must satisfy the following equation: BRU≥2 × Dow+PCU+PRU

[0215] Expired symbol: Symbol where the current time at the RU exceeds its target transmission time (i.e., SFN / SF) OTA.

[0216] Assuming a normal (partially filled) SF: T start This is the start of the transmission time, which occurs at the first SF (slot) boundary that the RU encounters after the LBT CAT 4 process has started. It is initially known to the CU 102 (since it sends the LBT start time) and can be updated in real time based on the LBT result and the communication between the lls-CU and the RU.

[0217] LBT_DL.indication Threshold (LBT_DL.indication-Threshold) (LBT th ): The latest time at which the lls-CU is expected to receive the LBT_DL.indication message from the RU. LBTth=Tstart−(PRU+Dow+PCU)

[0218] CU 103 Transmission time threshold (CU 103-Transmission time threshold) (CUT) th): The time at which the lls-CU must send the data to the RU, which OTA at time T start to be transferred CUTth=Tstart−(PRU+Dow+PCU)x={1 ms, Normal SF0,5 ms,Partially filled SF Guidelines for LAA implementation at Cloud-RAN:

[0219] The RU should have a buffer that satisfies the following equation: BRU≥2 × Dow+PCU+PRU

[0220] The lls-CU should prevent buffer overflow or underflow at the RU.

[0221] The lls-CU should only transmit data worth B for each individual transfer. RU Send to the RU.

[0222] The lls-CU should only be configured to receive data at the RU via P. RU expected before the actual OTA transmission time at RU.

[0223] The RU should avoid a buffer overflow or underflow at the RU.

[0224] The RU should empty its buffer (by dropping any expired symbols) as soon as any symbol has expired (i.e., the current time is greater than the terminated time of the symbol).

[0225] The RU should immediately send an LBT success message to the lls-CU as soon as the channel has been acquired.

[0226] With LBT CAT 4, the lls-CU can configure the RU (via the M layer) with the threshold for the LBT CAT 4 duration (e.g., 8 ms). After this threshold is exceeded, the RU sends an LBT failure message to the lls-CU, which in turn sends back a new LBT configuration request. The RU can then restart the LBT CAT 4 process.

[0227] The data signal can be received at the RU before or after the LBT_PDSCH_REQ.

[0228] The lls-CU can send a new LBT configuration message for each LBT message, or it can receive multiple LBT messages (with failure results) and send a new LBT configuration message only when it receives a success message. At this point, it resets the LBT phase and starts a new one with a new LBT configuration message. Generally, the LBT message could be sent after each measurement period (e.g., every 9 microseconds), or it could be sent only for the success result (i.e., after acquiring the channel).

[0229] Fig. Figure 13 is a flowchart representing a PDSCH transmission algorithm for a CU 102. After a start block 200, the CU 102 sends a B at block 201. RU -Data volume to the RRU at CUT th, which is to be transmitted OTA. At block 202, for the target SFN / SF, CU 102 sends an LBT_PDSCH_REQ request. At block 203, CU 102 determines whether the LBT_PDSCH_RSP response from the RU is received at the CU. If the response indicates a successful result, CU 102 determines at block 204 whether the LBT_PDSCH_RSP response is successful. If not (e.g., LBT timer expired), the LBT process is reset at block 205, and CU 102 terminates the transmission at block 210. If the LBT_PDSCH_RSP response from the RU is successful at block 204, CU 102 increments T at block 206. start to the buffer depth T start = T start + B RU . In block 207, the CU 102 also determines whether the remaining data is smaller than the buffer depth of the RU B. RU If this is the case, CU 102 sends the remaining data to RU at block 209. thIf the remaining data is not smaller than the buffer depth of the RU B RU , the CU 102 only sends data with a value of B at block 208. RU to the RU.

[0230] If CU 102 determines at block 203 that the LBT_PDSCH_RSP response was not received from the RU, CU 102 determines at block 211 whether the current time is the latest time at which the lls CU is expected to receive the LBT_DL.indication message from the RU. NOW = LBT TH If this is the case, the lls-CU 102 updates the time at which data should be transmitted OTA at block 212, T start = T start + [B RU], and returns to block 203 to wait for the LBT_PDSCH_RSP response and continue the process from there ([a]: is the boundary of the number "a" to the next x, where x is 1 ms for a normal SF and 0.5 ms for a partially filled SF). If this is not the case, CU 102 determines at block 213 whether the current time equals the transmission time threshold CUT. th The CU is 102. If so, the CU sends data with the value of B at block 214. RU If not, CU 102 then returns to block 203 to determine whether the LBT_PDSCH_RSP response has been received and continues the process from there.

[0231] The Fig.Figures 14A-14B are a flowchart for a PDSCH transfer algorithm for a RU. After a start block 300, the RU determines at block 301 whether data is being received. If not, the RU continues checking to determine if data is being received. If the RU determines that data is being received, it determines at block 302 whether the amount of data is greater than the buffer B. RU The RU. If so, the RU sends an error message to the CU at block 303. If the amount of data does not exceed the RU's buffer, the RU buffers the data at block 304.

[0232] At block 305, the RU determines whether it has received an LBT_PDSCH_REQ request from the CU. If, at block 306, it is confirmed that the request has been received, the RU starts an LBT CAT 4 spectrum acquisition. At block 307, the RU determines whether the LBT CAT 4 timer has expired. If so, at block 308, the RU sends a failure message (LBT_PDSCH_RSP: failure outcome) to the CU and terminates the process at block 319. If, at block 307, the LBT CAT timer has not expired, the RU determines at block 309 whether the current time is the start time and whether the channel has not been acquired. If so, at block 310, the RU increments the T start at x, T start = T start+ x and returns to block 306 to continue LBT CAT 4 spectrum acquisition. If not, the RU determines at block 311 whether a channel has been acquired at Tacq. If the channel has not been acquired, the RU discards all expired symbols from the buffer at block 312 and buffers any newly received data. The RU then returns to block 306 to continue LBT CAT 4 spectrum acquisition.

[0233] Once the channel is acquired at block 311, the RU sends a success message (LBT_PDCH_RSP: success outcome) to the CU at block 313. At block 314, the RU sends a reservation signal OTA to the T START At block 315, the RU sends the buffered data OTA. At block 316, the RU updates T start as T start = T start + B RU At block 317, the RU also determines whether the received data is smaller than the buffer depth of the RU B. RUIf this is the case, the RU continues to send the buffered data OTA at block 318. The process ends at block 319. If the remaining data is not less than the buffer depth of the RU B RU , the RU returns to block 315 to send buffered data OTA and performs the data reception check again at block 317.

[0234] Fig. 15 is a shading code for RU spectrum acquisition (points), reservation signal (diagonal lines), and OTA data transmission (horizontal lines), which is used in the Fig. 15-19, 22 and 24 are used.

[0235] The Fig. Figures 15-18 are an embodiment and examples relating to fronthaul normal SF support, as described above in the Fig. Described in sections 13-15B, the following assumptions apply: 2 x D ow : 5 symbols duration P CU : 1 Symbol duration (shared between UL and DL processing) PRU : 1 Symbol duration (shared between UL and DL processing) B RU : Data worth 1 slot Normal CP

[0236] As you will see, the parameters do not have to be an integer number of OFDM symbols. This is only assumed for simplification. Design example 1:

[0237] Fig. 15 is an embodiment in which the LBT is less than one subframe. Example 2

[0238] Fig. 16 is an embodiment in which the LBT comprises more than one subframe. Example 3

[0239] Fig. 17 is an embodiment in which the LBT is less than one slot. Example 4

[0240] Fig. 18 is an embodiment in which the LBT has more than one slot. Design 2

[0241] Fig.19 is another embodiment and examples of PDSCH transmission (with the options of normal and partially filled SFs) support, as above in the Fig. Described in sections 13-14B. The assumptions for the following examples are as follows: Restriction: B¯RU≥Dow+PCU+PRU

[0242] CU Transmission time threshold (CU-Übertragungszeitschwelle) (CUT th ): The time at which the lls-CU must send the data to the RU, which at time T start OTA transfers are to be made CUTth=Tstart−(PRU+Dow+PCU)

[0243] One variant of the first embodiment consists of the lls-CU continuously sending the data to the RU in data blocks of B. RU starting at the time CUT th and with period B RU to allow streaming until it receives the LBT_PDSCH_RSP with a success result.

[0244] At this point, the lls-CU calculates the number of remaining symbols to be transmitted until the end of the MCOT.

[0245] The lls-CU is streaming the B RU Data blocks with period B RU until the end of the MCOT.

[0246] The RU follows the same algorithm as in embodiment 1. The B RU However, it must be passed through B RU be replaced.

[0247] One exemplary advantage of embodiment 2 is that it has a smaller RU buffer constraint than embodiment 1. Example 4

[0248] Fig. Figure 19 shows an embodiment in which the LBT is longer than a subframe. DRS transmission

[0249] Regarding DRS transmission, it should be noted that: • PSS / SSS, which are part of a DRS, can occur outside of subframes 0 and 5. • CRS / CSI-RS / PSS / SSS should not vary with the subframe number, but should remain unchanged across subframes 0-4 (designated as DRS_v1) and 5-9 (DRS_v2). • The DRS transmission (from the CU to the RU) can be performed once at the beginning (e.g., during the initial configuration or at the first DRS transmission time) and can optionally be sent in each DRS period (from the CU to the RU).

[0250] Assumption: The OTA transmission of DRS begins at the SF boundaries. It should be self-evident that the proposed procedure can be adapted and applied to allow the DRS transmission start time at any OFDM symbol. The same concept can be used for both cases.

[0251] The DRS signal can be received before or after the LBT_DRS_REQ. DRSth,1=SF0−(PRU+Dow+PCU) DRSth,2=SF5−(PRU+Dow+PCU) SF0: The launch of SF0 SF5: The launch of SF5

[0252] At DRS th,1 The lls-CU sends DRS_v1 (i.e., what should be transmitted within SFs 0-4).

[0253] At DRS th,2 The lls-CU sends DRS_v2 (i.e., what should be transmitted within SFs 5-9).

[0254] Optional: The lls-CU can send a new LBT_DRS_REQ (with the new acquisition parameters) for each failure result it receives.

[0255] Optional: The RU can generate the reference signals (e.g. DRS) locally and keep them in its buffer.

[0256] Optional: The lls-CU can send the reference signals to the RU once during initial configuration. The RU can then buffer them and use them as needed.

[0257] An LBT message with a failure result could be sent for each measurement period. DRS transmission algorithm

[0258] Fig.Figure 20 is a flowchart illustrating a DRS transmission algorithm for a CU. After a start block 400, the CU sends a corresponding DRS at block 401. th,1 or DRS th,2 At block 402, at the target SFN / SF for measurement, the CU sends an LBT_DRS_REQ request. At block 403, the CU determines whether the DMTC offset time has elapsed (this can happen automatically at the RU and the lls-CU, or the lls-CU can send a warning message to the RU to stop the DRS transmission process). If so, the CU terminates the process at block 408. If not, the system determines at block 404 whether the current time DRS th,1 or DRS th,2 is (T now = DRS th,1 or T now = DRS th,2If so, the CU sends the corresponding DRS at block 405. If not, the CU determines at block 406 whether the RU has received the LBT_DRS_RSP response. If not, the CU returns to block 403 to determine if the DMTC offset time has elapsed and continues the process. If the RU has received the request, the CU determines at block 407 whether the result is successful and terminates the process at block 408 if so. If not, the CU returns to block 403 to determine if the DMTC offset time has elapsed in order to continue the process.

[0259] As you will see, the DRS transmission algorithm for the lls-CU is the same as for an RU configured and performing 25 µs capture, as described below in relation to Fig. 21 is shown, or for a RU that is configured for and performs LBT CAT 4 acquisition, as described below in relation to Fig. 22 is shown.

[0260] Fig. Figure 21 is a flowchart for an embodiment of a DRS transmission algorithm for a RU performing 25 µs acquisition. After a start block 500, the RU determines at block 501 whether a DRS is being received, and if so, it buffers the DRS at block 502. If the DRS is not received, the RU continues listening for the DRS.

[0261] After the DRS is buffered, the RU determines at block 503 whether it has received an LBT_DRS_REQ request from the CU. If so, the RU determines at block 504 whether the DMTC offset time has elapsed. If so, the RU terminates the process at block 512. If not, the RU determines at block 505 whether a new DRS has been received. If not, the RU starts the LBT spectrum acquisition (25 µs) at a configured time at block 507. If a new DRS has been received, the RU stores any existing DRS buffered at block 502 at block 506 and buffers the new DRS. Then, the RU starts the LBT spectrum acquisition (25 µs) at the configured time at block 507.

[0262] At block 508, the RU determines whether the LBT spectrum acquisition was successful. If not, the RU sends a failure message (LBT_DRS_RSP: failure outcome) at block 509 and returns to block 504 to determine whether the DMTC offset time has elapsed and continues the process. If so, the RU sends a success message (LBT_DRS_RSP: success outcome) at block 510, and at block 511, the RU sends the DRS OTA to the target device(s). Block 512 terminates the process. Example 5:

[0263] Fig. 22 is an example of DRS - 25 µs LBT, as shown in the flowcharts of the Fig. 20-21 is shown.

[0264] Fig.Figure 23 is a flowchart illustrating a DRS transmission algorithm for a RU. After a start block 600, the RU determines at block 601 whether a DRS is being received, and if so, it buffers the DRS at block 602. If the DRS is not received, the RU continues listening for the DRS. If not, the RU determines at block 603 whether an LBT_DRS_REQ request has been received. If not, the RU continues listening and determines whether the request has been received. If so, the RU determines at block 605 whether the DMTC offset time has elapsed. If so, the RU terminates the process at block 614. If not, the RU determines at block 605 whether a new DRS has been received. If not, the RU starts LBT CAT capture at a configured time at block 607. When a new DRS is received, the RU removes existing DRS buffered in block 502 at block 606 and buffers the new DRS.Then the RU starts the LBT CAT acquisition at block 607 at the configured time.

[0265] At block 608, the RU determines whether the LBT CAT4 timer has expired. If so, the RU sends a failure message (LBT_DRS_RSP: failure outcome) at block 609 and terminates the process at block 614. If not, the RU determines at block 610 whether a channel has been acquired. If not, the RU returns to block 604 to determine whether the DMTC offset time has elapsed and continues the process from there.

[0266] When a channel is acquired at block 610, the RU sends a success message (LBT_DRS_RSP: success outcome) at block 611, and at block 612, the RU sends the reservation signal OTA to the target device up to the SF boundary. At block 613, at the SF boundary, the RU sends the DRS OTA. Block 614 terminates the process. Example 6:

[0267] Fig.24 is an example of DRS - LBT CAT 4 according to the procedure of Fig. 20 and Fig. 23.

[0268] Multi-cell LAA: Assigning LAA-enabled and non-LAA-enabled UEs to a cloud RAN solution that supports carrier aggregation between multiple licensed and unlicensed component carriers (CCs).

[0269] Fig. 25 is an embodiment for assigning LAA- and non-LAA-capable UEs to licensed and unlicensed component carriers (CCs).

[0270] Tables 5-7 show a summary of UNII bands: Table 5 E-UTRA operation UNII-Band UL / DL frequency range (GHz) Number of 20 MHz channels DFS / TPC band 46a UNII-1 5,15 - 5,25 4 not needed 46b UNII-2A 5,25 - 5,35 4 required for radar 46c UNII-2C 5,47 - 5,725 12 required for radar 46d UNII-3 5,725 - 5,85 5 not needed UNII-4 5,85 - 5,925 N / A (mainly used for DSRC / ITS) not needed Table 6 UNII-1 Channel Number Carrier frequency (MHz) 36 5180 40 5200 44 5220 48 5240 Table 7 UNII-3 Channel Number Carrier frequency (MHz) 149 5745 153 5765 157 5785 161 5805 165 5825

[0271] 3GPP TS 36.300 V15.1.0 (2018-04-03) describes a specification limitation when aggregating multiple LAA cells:

[0272] "If the absence of IEEE 802.11n / 11ac devices sharing the carrier cannot be guaranteed in the long term (e.g., due to the level of regulation) and if, for this version, the maximum number of unlicensed channels on which E-UTRAN can transmit simultaneously is equal to or less than 4, the maximum frequency spacing between any two carrier mid-frequencies on which LAA-SCell transmissions are carried out should be less than or equal to 62 MHz. The UE must support the frequency spacing according to TS 36.133

[21] ."

[0273] For illustrative purposes, some assumptions regarding the number of LAA cells, supported bands, and the like are made in the following description. It will be clear to the average person with expertise in the field that the following procedures can be generalized to such an extent that these assumptions are not necessary. However, these assumptions are made only for illustration (and to provide examples) and not to limit the exemplary procedures described.

[0274] Band combinations for 3 and 4 LAA cells are shown below (as an example). For simplification and illustration, only bands that do not require coexistence with radar (i.e., UNII-1 and UNII-3) are described and shown below in Table 8. Table 8 3 unlicensed LAA cells 4 unlicensed LAA cells 3 UNII-1 4 UNII-1 2 UNII-1 + 1 UNII-2A 3 UNII-1 + 1 UNII-2A 1 UNII-1 + 2 UNII-2A 2 UNII-1 + 2 UNII-2A 3 UNII-2A 1 UNII-1 + 3 UNII-2A 3 UNII-2C 4 UNII-2A 2 UNII-2C + 1 UNII-3 4 UNII-2C 1 UNII-2C + 2 UNII-3 3 UNII-2C + 1 UNII-3 3 UNII-3 2 UNII-2C + 2 UNII-3 1 UNII-2C + 3 UNII-3 4 UNII-3

[0275] The following algorithm assumes that the CA combination between licensed and unlicensed tapes is supported by the UE based on 3GPP TS 36.104 V15.2.0 (2018-04-06). The lls-CU can filter the tapes supported by the RU to the CA combinations supported by 3GPP. Algorithm 1: lls-CU / RU handshake algorithm for initial channel selection (M layer).

[0276] During the initial configuration, the RU informs the lls-CU about its capabilities. This includes whether it supports LAA, the maximum number of LAA CCs it can support, the RU buffer size per CC, the supported bands on the RU (e.g., 46a, 46d), supported bandwidths, and the like.

[0277] Based on the supported bands, the lls-CU commands the RU to start measurements for these bands (e.g., to sample band 46a (UNII-1) and band 46d (UNII-3 band only)).

[0278] In the message “startMeasurements”, the lls-CU informs the RU about the band numbers, the carrier frequency of the channels and the total measurement duration.

[0279] The RU calculates the average RSSI and utilization rate for each channel and sends the measurements back to the lls-CU.

[0280] The lls-CU lists all “valid” available combinations of unlicensed tapes based on RU capabilities (e.g., the lls-CU can select either the UNII-1 or the UNII-3 tape to work on if only these two tapes are supported, i.e., 3 or 4 CCs in UNII-1 or 3 or 4 CCs in UNII-3).

[0281] As an example (nk)=n!(n−k)+!k! for n = 4 channels (UNII-1 band only) and k=3 CCs→(43)=4 Combination. The RU may ONLY select valid combinations.

[0282] As another example, for n=5 channels and k=3 CC, there are 10 combinations. 3 of these are invalid: 149 / 153 / 157 149 / 153 / 161 149 / 153 / 165**invalid 149 / 157 / 161 149 / 157 / 165**invalid 149 / 161 / 165**invalid 153 / 157 / 161 153 / 157 / 165 153 / 161 / 165 157 / 161 / 165

[0283] Based on the received measurements, the lls-CU calculates the average RSSI and utilization levels for various band combinations, as shown below. As an example, for 4 CC, the lls-CU averages the measurements (RSSI and utilization levels) for the four channels in a single combination. Table 9 Band combination index Example for 4 CCs (if only UNII-1 and 3 are supported) Average RSSI across 4 CCs Occupancy rate across 4 CCs Occupancy rate ranking (1: best) Exceeded occupancy rate threshold selected combination 1 36 / 40 / 44 / 48 2 Yes 2 149 / 153 / 157 / 161 1 Yes selected 3 153 / 157 / 161 / 165 3 Table 10 Band combination index Example for 3 CCs (if only UNII-1 and 3 are supported) Average RSSI across 3 CCs Occupancy rate across 3 CCs Occupancy rate ranking (1: best) Exceeded occupancy rate threshold selected combination 1 36 / 40 / 44 5 Yes 2 36 / 40 / 48 3 Yes selected 3 36 / 44 / 48 4 Yes 4 40 / 44 / 48 6 5 149 / 153 / 157 11 6 149 / 153 / 161 1 Yes 7 149 / 157 / 161 10 8 153 / 157 / 161 7 9 153 / 157 / 165 9 10 153 / 161 / 165 2 Yes 11 157 / 161 / 165 8

[0284] The lls-CU creates a ranking of the band combinations based on the utilization levels.

[0285] The lls-CU filters the combinations based on a utilization threshold (i.e., generating a set of combinations with utilization levels below a previously defined threshold, for example, 20%).

[0286] The lls-CU selects the band combination with the minimum RSSI from the filtered set (i.e., combinations with a utilization rate below the utilization rate threshold). Algorithm 2: DFS algorithm for MultiCell (M-layer)

[0287] The RU periodically collects measurements regarding the supported unlicensed bands and sends these measurements to the lls-CU based on the configuration parameters in the initial handshake (e.g., DFS measurement reporting period).

[0288] These measurements can be started by a "startMeasurements" message (which includes the bands to be sampled, the carrier frequencies of the channels and the measurement reporting period) and stopped by a "stopMeasurements" message.

[0289] For each measurement report, the lls-CU repeats algorithm 1 by calculating the average parameters across the channels of a single band combination, creating a ranking based on the utilization levels, filtering the set based on the previously defined threshold, and selecting the best combination based on the minimum average RSSI.

[0290] In one example implementation of the algorithm, the DFS measurement reporting period can be adjusted by the lls-CU based on how frequently frequency hopping is permitted. For example, the lls-CU might allow DFS only 1-4 times per day to minimize service disruption.

[0291] In another exemplary implementation of the algorithm, the lls-CU can only switch band combinations if the difference between the average RSSI of the currently used combination and the minimum average RSSI (after DFS measurement) is greater than a previously defined threshold.

[0292] In another exemplary implementation of the algorithm, the lls-CU can only switch band combinations if the difference between the utilization level of the currently used combination and the minimum utilization level (according to the DFS measurement) is greater than a previously defined threshold.

[0293] In another exemplary implementation of the algorithm, the lls-CU can only switch band combinations if the difference between the average RSSI of the currently used combination and the minimum average RSSI (according to DFS measurement) is greater than a previously defined threshold, or if the difference between the utilization level of the currently used combination and the minimum utilization level (according to DFS measurement) is greater than a previously defined threshold. Algorithm 3: Assignment / allocation of UEs to licensed / unlicensed cells. Part 1: Initial assignment:

[0294] Dividing the teaching units into two groups: teaching units that are capable of LAA (Learning Assistant) and teaching units that are not capable of LAA.

[0295] Assigning non-LAA-enabled UEs to licensed CCs.

[0296] Assigning LAA-enabled UEs to licensed CCs until the load on the licensed cells reaches a maximum threshold (licensed CC usage threshold: LCU). th ) (e.g. LCU) th = 70%).

[0297] If there are still no LAA-enabled UEs allocated while the maximum threshold of all licensed CCs has been reached, allocate LAA-enabled UEs to unlicensed CCs (based on algorithm 3.1 described below). Part 2: Real-time operation and optimization:

[0298] For each new UE, if the UE is not LAA-enabled, assign it to a licensed CC (this may lead to an increase in the use of licensed CCs; however, this can be resolved through the periodic redistribution of LAA-enabled UEs). If the UE is LAA-enabled, assign it to an unlicensed CC (based on Algorithm 3.1).

[0299] For each period T alloc (e.g. T alloc(= 60 min) the lls-CU distributes all LAA-enabled UEs across licensed and unlicensed channels with the following objectives:

[0300] Reduction in the use of licensed CCs at LCU th .

[0301] Optimal allocation of LAA-enabled UEs to unlicensed CCs based on the reported CQI of the respective UE.

[0302] Balancing the load across all CCs.

[0303] The periodic redistribution of LAA-eligible UEs is carried out similarly to the initial allocation.

[0304] Assigning LAA-enabled UEs to licensed CCs until the load on the licensed cells reaches a maximum threshold (licensed CC usage threshold): LCU th ) achieved (e.g. LCU) th = 70% usage).

[0305] If there are still no LAA-enabled UEs allocated while the maximum threshold of all licensed CCs has been reached, allocate LAA-enabled UEs to unlicensed CCs (based on algorithm 3.1).

[0306] T alloc should be based on the deviation from LCU th be adapted. With increasing use of licensed CCs, T should alloc decrease to avoid blocking non-LAA-enabled UEs to licensed CCs.

[0307] Algorithm 3.1: Allocation of LAA-enabled UEs to unlicensed CCs after reaching LCU th with the licensed CCs.

[0308] If the number of unlicensed CCs is one, assign all LAA-enabled UEs to the unlicensed CC.

[0309] If the number of unlicensed CCs is ≥ 1:

[0310] Creating a matrix for the utility function of LAA-enabled UEs for various unlicensed CCs. There are four parameters that influence the UE allocation to unlicensed CCs (i.e., the utility function): • Cell load • UE channel amplification (or CQI) • DFS measurements: Capacity utilization rate • DFS measurements: average RSSI

[0311] The simplified utility function for a user (i) working via CC (j) can be represented as follows: Uij=(1−Roj)∗PSj∗B∗log(1+PTj∗|hij|2​NoB+Ij)

[0312] This includes: - R oj The last reported utilization level (derived from carrier selection / DFS measurements) for the unlicensed CC j. This takes channel congestion into account. - P sj The probability of the user terminating over the channel (j). This takes into account the cell load. P sj = 1 / N Uj , where NUj The current number of UEs being added to CC j. - B: Channel bandwidth. - P Ti the transmission power of RU via CC j. - h ij the channel amplification of UE (i) via CC j under the assumption that the reciprocal CSI is known at RU. - N o the noise power spectral density at the UE (which is assumed to be constant for all UEs when no information is available). - I j The approximate external interference at the UE (e.g., from neighboring Wi-Fi access points, etc.) can be derived from the last RSSI value (i.e., for carrier selection / DFS) reported by the RU during channel measurement. This is based on the assumption that the external interference per CC is uniform between the RU and UEs.

[0313] It will be clear to the average professional that other utility functions that map the aforementioned parameters (or any other parameters that affect the performance of the UEs) can also be used to model the allocation problem. Table 11 CC1 CC2 ... CCu U1 U 11 U 12 U 1u U2 U 21 U 22 U 2u ... ... To U m1 U m2 U mu Solution 1: Iterative Hungarian method:

[0314] One exemplary solution is to use a modified version of the Hungarian method. The Hungarian method can be used to solve assignment problems in polynomial time 0(n). 3 ) to solve.

[0315] Goal: to maximize the sum of utility functions while maintaining the same load balance across all unlicensed CCs.

[0316] Step X: Create a submatrix from the original matrix with a number of UEs equal to the number of unlicensed CCs. This is the cost matrix (with negative benefits).

[0317] Solving the allocation problem using the regular Hungarian method (now each UE of the submatrix is ​​assigned to a single unlicensed CC and each unlicensed CC receives a single UE from the submatrix).

[0318] Remove the rows from the original matrix that correspond to UEs already assigned to unlicensed CCs. Rename this new matrix the original matrix.

[0319] Continue with step X. Solution 2:

[0320] Another exemplary solution, which should lead to a higher overall benefit but does not maintain a comparable load balance between unlicensed CCs, is as follows: Step Y: Iterate over the UEs in the original matrix.

[0321] Select the unlicensed CC that yields the maximum utility function for each UE.

[0322] Check if the selected CC has reached its maximum permissible load (can be defined as a function of the number of UEs previously).

[0323] If so, remove the CC column from the original matrix. Name this new matrix the original matrix. Proceed to step Y.

[0324] If no, proceed to step Y. Adjusting the fronthaul transmission rate

[0325] In C-RANs, the BBU 103 pre-transmits the data packets to the RRU 105 to compensate for fronthaul latency. This fronthaul latency is a function of several factors, including the physical distance between the BBU 103 and the RRU 105, the transport network, network congestion, and the like.

[0326] One problem faced by C-RANs (for both licensed and unlicensed spectrum) is determining the number of data packets that need to be transferred from the BBU 103 to the RRU 105 to avoid buffer overflow and buffer underflow at the RRU. Typically, a single BBU 103 can support multiple RRUs.

[0327] Fig. 26 is an embodiment of a configuration and a method for adjusting the fronthaul rate, which is described as follows. 1) After the RRU 105 is powered up, the BBU 103 sends several pilot messages to the RRU 105, each containing a timestamp for the transmission time (at the BBU 103). 2) The RRU 105 responds to each pilot message with a reply message, and each reply contains the time at which the RRU 105 can receive the pilot message. 3) Based on the buffer size at the RRU 105 and the fronthaul latency, the BBU 103 adjusts the transmission rate to the RRU 105 (this differs from the OTA transmission rate).

[0328] The first pilot / response messages exchanged between BBU 103 and RRU 105 capture the latency due to the physical distance between BBU 103 and RRU 105, the transport network latency, and other fixed parameters that introduce a fixed latency. 4) To cover other dynamic changes in fronthaul latency, the RRU 105 periodically sends the buffer status to the BBU 103. 5) BBU 103 and RRU 105 periodically exchange pilot / response messages to refine the estimated fronthaul latency. 6) The BBU 103 adjusts the fronthaul transmission rate based on the fronthaul latency and the buffer size of the RRU 105. 7) If the fronthaul latency increases, the BBU 103 can briefly increase the fronthaul transmission rate to compensate for this delay and then return it to normal. The same applies in reverse. A similar principle applies to the buffer size of the RRU 105. 8) For LAA, a similar concept (used for varying fronthaul latencies) can be applied to varying LBT delays. a. The LBT delay is defined as the amount of time the RRU 105 needs to acquire the spectrum for the transmission of specific data packets. b. LBT delay can vary based on various metrics, such as network density, traffic priority class, traffic volume, and the like. c. A varying LBT latency plays a crucial role in determining the buffer size of the RRU 105. d. The BBU 103 adjusts the fronthaul transmission rate based on the LBT latency in a similar way to the fronthaul latency.

[0329] Systems and components thereof for carrying out embodiments of the present disclosure may include a central processing unit (CPU) or any other processor. The input unit may include a receiver, a transceiver, or any other means of receiving. The output unit may include a transmitter, a transceiver, or any other means of transmitting. The input and output units of the device may be functionalities that run on the processor of the device, or alternatively, they may be separate functional components. They may also be implemented as integrated transceivers. The input and output units may, for example,They can be implemented as physical transmitters / transceivers for sending / receiving via an interface, as routing units for sending / receiving data packets in a packet-switched network, or as any suitable combination thereof. Systems and their components can also exchange information via internal interfaces.

[0330] Each component can be configured to process various data inputs and control the input and output units. Each component can also include memory. This memory can be used to store code for executing the procedures according to the examples of the present embodiments.

[0331] A person skilled in the art will recognize that the architecture of the systems described herein are non-limiting examples illustrating at least part of at least one embodiment. As such, more or fewer components can be used and / or arranged differently without altering the scope of the innovations described herein.

[0332] The technology standards and reports of the Third Generation Partnership Project (3GPP) referenced herein and incorporated in full by reference include: 3GPP TR 38.801 V14.0.0 (2017-03) 3GPP TR 36.889 V13.0.0 (2015-06) 3GPP TS 36.211 V14.3.0 (2017-06) 3GPP TS 36.300 V15.1.0 (2018-04-03) XRAN-FH.CUS.0-v01.00.02 (2018-04-04) 3GPP TS 36.213 V15.1.0 (2018-03)

Claims

[1] Method comprising: Transmitting from a lower layer of a baseband unit (BBU) to a layer of a remote radio unit (RRU) via a fronthaul interface a data transmission on a destination subframe agreed between the BBU and the RRU, wherein the data is sent a number of milliseconds before the RRU performs an LBT (Listen Before Talk) step for the data, wherein a control unit (CU) of the BBU is configured to set a timer based on an end-to-end latency requirement of the data traffic and is configured to attempt transmission in an unlicensed band. [2] The method of claim 1, wherein the CU is further configured to: Transfer, from the CU, an amount of data corresponding to the RRU buffer depth (B RU) at a CU transmission time threshold at which the CU must transmit the data to the RRU so that it can be received at T start transmitted over the air (OTA) (CUT th ); Transmit, for the destination subframe, an LBT Physical Downlink Shared Channel (PDSCH) request to the RRU; Determine whether an LBT-PDSCH response is received from the RRU at the CU; Determine whether the LBT-PDSCH response is successful; and If the LBT PDSCH response is successful, incrementing a CU transmission start time (T start ) to set a buffer depth of the RRU (T start. = T start + B RU ), or Reset the LBT step if the received LBT-PDSCH response is unsuccessful. [3] The method of claim 2, wherein the CU is further configured to: Incrementing the CU transmission start time (T start ) to the buffer depth of the RRU (T start. = T start+ B RU ) if it is determined that the LBT-PDSCH response from the RRU is successful; Determine whether the remaining data is less than the RRU buffer depth (B RU ); and if this is the case, transfer the remaining data to the RRU at the CU transmission time threshold CUT th , or if not, transfer only data set B RU to the RRU. [4] The method of claim 3, wherein, if the CU determines that the LBT-PDSCH response from the RRU is not received at the CU, the CU is further configured to: Determine whether a current time is a latest time at which the CU is expected to receive the LBT-PDSCH response from the RRU (T NOW = LBT TH ); if yes, update the time at which the data should be transferred OTA ( OTA Tstart.=Tstart+⌈BRU⌉ ); and Continue to determine if the LBT-PDSCH response from the RRU is not received at the CU. [5] The method of claim 3, wherein if the CU determines that the current time is not the latest time at which the CU is expected to receive the LBT-PDSCH response from the RRU (T NOW = LBT TH ), the CU is further configured to: Determine whether the current time is equal to the CU transmission time threshold CUT th is, and: if so, transferring data worth B RU ; or if not, return to determine whether the LBT-PDSCH response was received. [6] The method of claim 1, wherein the RRU is configured to: Determine whether an LBT Physical Downlink Shared Channel (PDSCH) request is being transmitted by the CU; Starting an LBT spectrum acquisition when the LBT PDSCH request is received from the CU; Determine whether an LBT spectrum acquisition timer has expired; and if the LBT timer has expired, send a failure message to the CU and terminate the LBT process; or if the LBT timer has not expired, determine that a current time has a start time (T start ) and whether no channel has been acquired, and If no channel has been acquired, increment the T start by x(T start = T start + x) and continue LBT spectrum acquisition. [7] The method of claim 6, wherein the RRU is further configured to: Determine whether a channel has been acquired at time Tacq, and if no channel has been acquired, discarding all expired symbols from a buffer of the RRU and buffering all newly received data and Proceed with LBT spectrum acquisition. [8] The method of claim 7, wherein the RRU is further configured to: if the channel has been acquired, sending an LBT-PDSCH success message to the CU; Sending a reservation signal OTA to T start ; Sending the buffered data OTA and updating T start as T start = T start + B RU ; Determine whether the buffered data is less than the buffer depth of RRU B RU , and if so, continue sending the buffered data OTA, and if the remaining buffered data is not less than the buffer depth of RRU B RU , sending the remaining buffered data OTA and performing a data reception check. [9] System comprising: a baseband unit (BBU) comprising a control unit (CU) configured to send a pilot message to a remote radio unit (RRU) prior to a data link time to compensate for fronthaul latency; and wherein the RRU is configured to respond to the BBU with messages specifying a time at which the RRU can receive the pilot message, and wherein the CU is configured to adapt a transmission rate to the RRU based on the buffer size at the RRU and the fronthaul latency. [10] A method comprising: Transmitting, from a lower layer of a baseband unit (BBU) to a layer of a remote radio unit (RRU) via a fronthaul interface, a Discovery Reference Signal (DRS) transmission, wherein a control unit (CU) of the BBU is configured to: Sending the DRS signal at a time DRSth,1 or a point in time DRS th,2 ; Sending an LBT-DRS request to a target subframe for a Listen Before Talk (LBT) acquisition; and Determine whether a Discovery Measurement Timing Configuration (DMTC) offset time has passed; and if so, send the DRS transmission. [11] The method of claim 10, wherein the CU is further configured to: If the CU determines whether the Discovery Measurement Timing Configuration (DMTC) offset time has not passed, determine whether a current time DRS th,1 or DRS th,2 . is (T now = DRS th,1 or T now = DRS th,2 ?); and if so, send the DRS. [12] The method of claim 11, wherein the CU is further configured to: if the CU determines that a current time is not the DRS time th,1 or the time DRS th,2 is (T now = DRS th,1 or Tnow = DRS th,2 ?), Determine whether the RRU has received an LBT-DRS request, and if not, determine whether the DMTC offset time has expired and continue with the DRS transmission; If the CU determines that the RRU has received the LBT DRS request, determine whether the result is successful and, if so, terminate the DRS transmission; If the CU determines that the LBD DRS request was unsuccessful, determine whether the DMTC offset time has expired and continue with the DRS transmission process. [13] The method of claim 10, wherein the RRU is configured to: Determine whether the DRS is received and, if so, buffer the DRS; if the DRS is not received, continue listening for the DRS; if the DRS is buffered, determine whether the RRU has received an LBT DRS request from the CU; and If yes, determine whether the discovery measurement time window (DMTC) offset time has expired, and if yes, terminate the process. [14] The method of claim 13, wherein the RRU is configured to: if the DMTC offset time has not elapsed, determine whether no new DRS has been received; if not, start an LBT spectrum acquisition at a configured time; if a new DRS has been received, dropping the existing buffered DRS and buffering a new DRS; and Start LBT spectrum acquisition at a configured time. [15] The method of claim 14, wherein the RRU is configured to: Determine whether the LBT spectrum acquisition is successful; if not, send an LBT-DRS failure response to the CU; Determine whether the DMTC offset time has passed; if yes, send an LBT-DRS success response to the CU and Sending the DRS over an air interface to the target device.

Images