Beamforming is an essential part of the 5G NR air interface and improves the uplink and downlink link budget by increasing the antenna gain at the gNB. Improving this budget is particularly important in high bands (i.e., mmWave) where coverage is limited and also helps achieve better uplink and downlink SINR due to more directional transmission and reduced inter-cell and intra-cell interference.
Beam Management - A Quick View
Beam Management involves many processes that start during Initial access and continue when the UE moves from RRC Idle to RRC-connected mode. The gNB performs beam sweeping in the cell when it transmits the coverage beams (SSB beams), and the UE performs beam determination. Once the UE is in RRC-connected mode, it is instructed to measure the coverage or traffic beams' RSRP and report it to the gNB, followed by beam refinement and possible beam switching to maintain the optimum beam quality. Beam management also includes beam failure detection and beam recovery to keep the user connected with the best beam in those situations where beam switching has failed, the UE has run out of coverage, or has experienced high levels of interference.
In normal operating conditions, as the radio conditions change over time and within the cell's coverage area, the gNodeB commands the UE to switch beams to maintain the best service. The UE assists during the beam switching procedure by providing the gNB with CSI reports, including SSBRI (SSB Resource Indicator) and/or CRI (CSI Resource Indicator) and their corresponding L1-RSRP measurement.
Sudden changes in the radio conditions not giving enough time to the UE and the gNB to exchange beam-switching related messages, e.g., a mobile user entering a shadowed region of a high-rise building or its coverage being obstructed by a big moving vehicle, may lead to beam failures.
The beam failure detection and recovery process is an L1/L2 procedure in which the UE detects several beam failures in each amount of time, followed by a recovery process. The Physical layer of the UE detects the beam failure instance(s) and reports it (them) to the MAC layer, which increases the BFI (beam failure indication) counter and starts/restarts beamfailuredetectiontimer. When the number of beam failures detected reaches beamfailureinstancemax while beamfailuredetectiontimer is running, the UE starts the beam failure recovery process.
Parameters (beamfailureinstancemax and beamfailuredetectiontimer) are provided to the UE via the RRC Setup message in 5G SA and the RRC reconfiguration message in the 5G NSA network during the SgNB addition process. The beam failure recovery process consists of a random-access procedure with the cause: Beam Failure. This entire process is transparent to RRC Layer.
How does UE detect the Beam failure instance?
Let's try to understand more in detail how the physical layer at the UE reports the beam failure instance(s) to the MAC layer.
In many real-world situations, the beam pair correspondence can break so severely that there is insufficient time for the beam adjustment procedure to switch to a better beam resulting in Beam Failure. The UE can use the configured CSI-RS or SSB resources for detecting beam failure as dictated by the gNB. Beam failure detection occurs in NR based on Q_out and Q_in, like LTE's In-Synch and Out-of-Sync parameters. Unlike LTE, these parameters are configurable in NR. The default value for Q_out is 10% and corresponds to a degraded beam quality such that a hypothetical baseline PDCCH would have more than a 10% block error rate if transmitted in those RF beam conditions. If this error rate is maintained over a given period, the UE declares a single instance of beam failure. If the beam quality improves and the Block Error Rate (BLER) drops below 2% within a predetermined duration, no beam failure is counted.
While the threshold Q_in (corresponding to the in-sync block error rate (BLERin) is defined as the level at which the downlink radio link quality can be received with significantly higher reliability than at Q_out. Q_out and Q_in are derived based on hypothetical PDCCH transmission (Q_out assumes a transfer of DCI format 1_0 with CCE aggregation level 8 and core-set spanning 2 symbol, and Q_in assumes a transfer of DCI format 1_0 with CCE aggregation level 4 and core-set spanning 2 symbol), Refer to 3GPP Spec 38.133.
The value of both Q_out and Q_in is determined from the network configuration via the parameter rlmInSyncOutOfSyncThreshold signaled by higher layers. When UE is not configured with rlmInSyncOutOfSyncThreshold from the network, UE determines out-of-sync and in-sync block error rates from the below default Configuration #0.
Does a beam failure detection mean we had a dropped call? What happens if the beam failure recovery process is unsuccessful? Will this mean we have a drop? Let's take a break and tackle these questions in Part 2: Is Beam failure a connection drop in 5G?