Beam failure recovery is a critical mechanism in 5G networks designed to ensure seamless connectivity and reliability, even in challenging radio conditions. This procedure addresses situations where the signal strength of the connected beam drops below a predefined threshold, indicating beam failure. When such an event occurs, the UE initiates a recovery process by detecting beam failure using a specific reference signal and searching for a candidate beam with better signal quality. If a sufficient number of beam failures are detected, the UE triggers the beam failure recovery process by transmitting a request to the network using a PRACH preamble linked to the candidate beam. The network then responds with the necessary configuration, completing the recovery process and re-establishing a reliable connection. This process ensures that the UE can maintain continuous communication with the network, even in dynamic or high-mobility scenarios where beam quality may vary rapidly.

Followings are the topics I am going to look into in this note

• RRC Parameters for Beam Failure Detection
• RRC Parameters for Beam Failure Recovery Configuration
• Examples
• Example 01 : Hand blockage on a mmWave phone (the textbook case)
• Example 02 : Walking around a street corner (LoS lost, reflection found)
• Example 03 : A truck passes by (the case where BFR should NOT trigger)
• Example 04 : Rotating the device / raising the phone to the ear
• Example 05 : No candidate beam is found - BFR fails and RLF follows
• Example 06 : Beam failure on an SCell in Carrier Aggregation (Release 16)
• Example 07 : A fixed wireless access CPE and a tree in the wind
• Summary of the scenarios

Beam Failure detection and recovery procedure is specified in 38.321-5.17 and can be summarized as below.

This process is illustrated as below from this paper([3])

Following is breakdown of the illustration :

• Beam Failure Detection: The process starts with the UE detecting a beam failure. This occurs when the signal strength of the connected beam, typically measured using L1-RSRP or a reference signal, falls below a predefined threshold.
• Candidate Beam Identification: After detecting the beam failure, the UE searches for a new candidate beam with better signal quality. This involves scanning the available beams in the network and selecting one that meets the required quality criteria.
• Beam Failure Recovery Request:
• The UE sends a Beam Failure Recovery Request to the network using the Physical Random Access Channel (PRACH).
• In Release 15, PRACH is used for recovery requests in the primary cell.
• In Release 16, uplink control channels are also supported for recovery requests in secondary cells during carrier aggregation.
• The use of non-contention-based PRACH ensures faster and more reliable message delivery for critical beam recovery scenarios.
• Network Response: The network (via the Transmission Reception Point, TRP) monitors and responds to the recovery request. This response includes acknowledgment or configuration details to establish communication using the newly identified beam.
• Post-Recovery Communication: After the recovery process, the UE and TRP switch to the newly identified beam(s) for ongoing communication. This ensures that the connection remains robust and uninterrupted.

NOTE : It would worth note following comments from this paper([3])

To accelerate the procedure of beam recovery and ensure the robustness of this message delivery, non-contention based channel based on physical random access channel (PRACH) (instead of contention-based) can be used for carrying beam failure recovery request for primary cell in Release 15. In Release 16, uplink control channel is additionally supported for carrying beam failure recovery request for secondary cells in the case of carrier aggregation. After this beam failure recovery process, the TRP and UE can use the newly identified beam(s) for subsequent communication

• The non-contention-based PRACH mechanism significantly accelerates the beam recovery process and ensures reliable delivery of recovery requests, especially in challenging environments.
• The enhancements in Release 16, including support for secondary cells in carrier aggregation, make beam recovery more versatile in advanced network configurations.
• This process is critical in scenarios involving high mobility, interference, or complex beamforming setups, enabling seamless communication and improving user experience.

RRC Parameters for Beam Failure Detection

The RRC Parameters for Beam Failure Detection define the configuration used by the UE to monitor and detect beam failures in 5G networks. These parameters are part of the RRC signaling protocol and specify how the UE should identify and handle beam failure scenarios.

Followings are key concepts of this RRC parameter :

• Dynamic Configuration: The configuration allows the network to dynamically add, modify, or release monitoring resources to adapt to changing conditions in the network.
• Beam Failure Detection: The UE monitors the signal quality of reference signals (SSB or CSI-RS) and compares it to predefined thresholds. If the quality drops below the threshold for a specific duration (defined by beamFailureDetectionTimer), a beam failure is detected.
• Flexible Monitoring: The configuration supports different use cases, including monitoring for beam failures (beamFailure), radio link failures (rlf), or both simultaneously.
• Network Control: These parameters are provided by the network to ensure efficient and precise monitoring, minimizing false alarms and optimizing recovery procedures

RadioLinkMonitoringConfig ::= SEQUENCE {

   failureDetectionResourcesToAddModList     SEQUENCE (SIZE(1..maxNrofFailureDetectionResources))

                                                   OF RadioLinkMonitoringRS

   failureDetectionResourcesToReleaseList    SEQUENCE (SIZE(1..maxNrofFailureDetectionResources))

                                                   OF RadioLinkMonitoringRS-Id

   beamFailureInstanceMaxCount               ENUMERATED {n1, n2, n3, n4, n5, n6, n8, n10}

   beamFailureDetectionTimer                 ENUMERATED {pbfd1, pbfd2, pbfd3, pbfd4, pbfd5,

                                                         pbfd6, pbfd8, pbfd10}

   ...

}

RadioLinkMonitoringRS ::= SEQUENCE {

   radioLinkMonitoringRS-Id                  RadioLinkMonitoringRS-Id,

   purpose                                   ENUMERATED {beamFailure, rlf, both},

   detectionResource                         CHOICE {

                                                   ssb-Index SSB-Index,

                                                   csi-RS-Index NZP-CSI-RS-ResourceId

   },

...

}

• A sequence that defines the list of resources to add or modify for beam failure detection.
• Each entry in this list corresponds to a RadioLinkMonitoringRS, which contains the details of a specific reference signal used for monitoring beam failure.

• A sequence that defines the list of resources to be released, corresponding to previously configured monitoring resources.
• This allows the network to dynamically update the monitoring configuration by removing obsolete resources.

• An enumerated parameter that specifies the maximum number of beam failures that the UE can tolerate before triggering the recovery procedure.
• Possible values include predefined counts such as n1, n2, n3, n4, n5, n6, n8, n10.

• An enumerated timer that defines the maximum time duration for monitoring and detecting beam failures.
• The timer values include pbfd1, pbfd2, pbfd3, pbfd4, pbfd5, pbfd6, pbfd8, pbfd10, where "pbfd" refers to "Physical Beam Failure Detection."

RRC Parameters for Beam Failure Recovery Configuration

The RRC Parameters for Beam Failure Recovery Configuration specify the configuration for managing beam failure recovery in 5G networks. These parameters define how the UE (User Equipment) interacts with the network to re-establish communication when a beam failure occurs.

BeamFailureRecoveryConfig ::= SEQUENCE {

   rootSequenceIndex-BFR              INTEGER (0..137) OPTIONAL, -- Need M

   rach-ConfigBFR                     RACH-ConfigGeneric OPTIONAL, -- Need M

   rsrp-ThresholdSSB                  RSRP-Range OPTIONAL, -- Need M

   candidateBeamRSList                SEQUENCE (SIZE(1..maxNrofCandidateBeams))

                                         OF PRACH-ResourceDedicatedBFR OPTIONAL, -- Need M

   ssb-perRACH-Occasion               ENUMERATED {oneEighth, oneFourth, oneHalf, one, two,

                                                  four, eight, sixteen} OPTIONAL, -- Need M

   ra-ssb-OccasionMaskIndex           INTEGER (0..15) OPTIONAL, -- Need M

   recoverySearchSpaceId              SearchSpaceId OPTIONAL, -- Need R

   ra-Prioritization                  RA-Prioritization OPTIONAL, -- Need R

   beamFailureRecoveryTimer           ENUMERATED {ms10, ms20, ms40, ms60, ms80,

                                                  ms100, ms150, ms200} OPTIONAL, -- Need M

   ...,

   [[

      msg1-SubcarrierSpacing-v1530 SubcarrierSpacing OPTIONAL -- Need M

   ]]

}

rootSequenceIndex-BFR: Specifies the root sequence index for the PRACH (Physical Random Access Channel) preamble used in beam failure recovery.

rach-ConfigBFR: Contains the configuration for PRACH resources used for beam failure recovery, as defined in the RACH-ConfigGeneric structure (explained later).

rsrp-ThresholdSSB: Defines the RSRP (Reference Signal Received Power) threshold for SSB (Synchronization Signal Block) detection. Beams with an RSRP above this threshold are considered candidates for recovery.

candidateBeamRSList: Specifies a list of candidate beams for recovery. Each entry corresponds to a PRACH-ResourceDedicatedBFR, which indicates whether the candidate beam uses SSB or CSI-RS (Channel State Information Reference Signal).

ssb-perRACH-Occasion: Defines the number of SSBs mapped to each PRACH occasion. This value can range from oneEighth to sixteen, controlling the granularity of beam failure recovery attempts.

ra-ssb-OccasionMaskIndex: Indicates the mask index for RA (Random Access) SSB occasions to identify which beams are active for beam recovery.

recoverySearchSpaceId: Specifies the search space ID used by the network to monitor and respond to recovery requests. This ensures the recovery process is efficiently managed.

ra-Prioritization: Contains parameters for prioritizing random access resources during recovery, such as power ramping steps and scaling factors for priority-based resource allocation.

beamFailureRecoveryTimer: Sets the timer for beam failure recovery, with values ranging from ms10 to ms200. This controls how long the UE waits for a response before retrying.

msg1-SubcarrierSpacing-v1530: Specifies the subcarrier spacing used for the PRACH message during beam failure recovery.

PRACH-ResourceDedicatedBFR ::= CHOICE {

   ssb                               BFR-SSB-Resource,

   csi-RS                            BFR-CSIRS-Resource

}

BFR-SSB-Resource ::= SEQUENCE {

   ssb                               SSB-Index,

   ra-PreambleIndex                  INTEGER (0..63),

   ...

}

BFR-CSIRS-Resource ::= SEQUENCE {

   csi-RS                            NZP-CSI-RS-ResourceId,

   ra-OccasionList                   SEQUENCE (SIZE(1..maxRA-OccasionsPerCSIRS))

                                        OF INTEGER (0..maxRA-Occasions-1) OPTIONAL, -- Need R

   ra-PreambleIndex                  INTEGER (0..63) OPTIONAL, -- Need R

   ...

}

ssb

• Refers to an SSB resource used for beam failure recovery, including:
• SSB-Index: Identifies the SSB associated with the recovery.
• ra-PreambleIndex: Specifies the preamble index for the PRACH resource.

csi-RS

• Refers to a CSI-RS resource used for beam failure recovery, including:
• NZP-CSI-RS-ResourceId: Identifies the CSI-RS resource.
• ra-OccasionList: Lists the RA occasions for the CSI-RS.
• ra-PreambleIndex: Specifies the preamble index for the PRACH resource.

RACH-ConfigGeneric ::= SEQUENCE {

   prach-ConfigurationIndex          INTEGER (0..255),

   msg1-FDM                          ENUMERATED {one, two, four, eight},

   msg1-FrequencyStart               INTEGER (0..maxNrofPhysicalResourceBlocks-1),

   zeroCorrelationZoneConfig         INTEGER(0..15),

   preambleReceivedTargetPower       INTEGER (-202..-60),

   preambleTransMax                  ENUMERATED {n3,n4,n5,n6,n7,n8,n10,n20,n50,n100,n200},

   powerRampingStep                  ENUMERATED {dB0, dB2, dB4, dB6},

   ra-ResponseWindow                 ENUMERATED {sl1, sl2, sl4, sl8, sl10, sl20, sl40, sl80},

   ...

}

prach-ConfigurationIndex: Defines the PRACH configuration index, which determines the time and frequency resources for PRACH transmissions.

msg1-FDM: Specifies the number of PRACH occasions in frequency-domain multiplexing (one, two, four, or eight).

msg1-FrequencyStart: Indicates the starting frequency for PRACH occasions in the resource grid.

zeroCorrelationZoneConfig: Configures the zero-correlation zone, used to reduce interference between preambles.

preambleReceivedTargetPower: Sets the target power level for the received PRACH preamble, ranging from -202 dB to -60 dB.

preambleTransMax: Specifies the maximum number of preamble transmissions, with values such as n3, n4, n5, up to n200.

powerRampingStep: Defines the step size for power ramping during PRACH transmissions (dB0, dB2, dB4, dB6).

ra-ResponseWindow: Indicates the time window for the UE to wait for a random access response from the network.

RA-Prioritization ::= SEQUENCE {

   powerRampingStepHighPriority      ENUMERATED {dB0, dB2, dB4, dB6},

   scalingFactorBI                   ENUMERATED {zero, dot25, dot5, dot75} OPTIONAL, -- Need R

   ...

}

powerRampingStepHighPriority: Sets the power ramping step size for high-priority PRACH occasions.

scalingFactorBI: A scaling factor applied to determine the priority of beam recovery attempts. Values include zero, dot25, dot5, and dot75.

Examples

All the parameters described above look very abstract when you read them one by one in the ASN.1 structure. So in this section, let me put them into situations that actually happen in the real world. In every scenario I will follow the same story : what happens physically -> what the UE measures -> which parameter decides what -> what you would see in a log.

Before going into the individual cases, it is worth being clear about one thing that confuses many people. Beam failure is not the same thing as radio link failure, and it is not a handover either. The three of them look similar because all of them are triggered by bad signal quality, but they work at completely different levels and on completely different time scales.

NOTE : This is why beam failure recovery exists at all. Without it, every hand movement in a mmWave network would end up as a radio link failure. BFR is a fast, local repair mechanism that keeps the small problems from becoming big ones.

The scenarios below are ordered roughly from the most common to the least common.

Example 01 : Hand blockage on a mmWave phone (the textbook case)

You are downloading a file on a mmWave (FR2) connection and you shift your grip on the phone. Your hand now covers the antenna module that was pointing at the gNB.

What happens physically : the human hand is almost a perfect blocker at 28 GHz. This is not a gentle fade like in FR1 - the signal can drop by 20 to 30 dB within a few milliseconds. The beam is not misaligned at all. It is still pointing in exactly the right direction, but the path is simply closed.

What the UE does : the UE is continuously measuring the BFD-RS (the reference signals listed in failureDetectionResourcesToAddModList, usually a periodic CSI-RS of the serving beam). Assume the CSI-RS period is 10 ms and beamFailureInstanceMaxCount is n3.

  t (ms)   what happens
  ------   ---------------------------------------------------------------------------------
     0     the hand covers the antenna module ; L1-RSRP of the serving beam drops ~25 dB
    10     BFD-RS #1 : quality worse than Qout,LR  -> BFI_COUNTER = 1   (BFD timer starts)
    20     BFD-RS #2 : still bad                   -> BFI_COUNTER = 2
    30     BFD-RS #3 : still bad                   -> BFI_COUNTER = 3 = beamFailureInstanceMaxCount
                                                   -> BEAM FAILURE IS DECLARED
    32     UE scans candidateBeamRSList, finds SSB#5 above rsrp-ThresholdSSB
    36     UE sends the dedicated preamble (ra-PreambleIndex of SSB#5) on a PRACH occasion
                                                   -> beamFailureRecoveryTimer starts
    44     UE finds a PDCCH for its C-RNTI in recoverySearchSpaceId  -> recovery complete

So the whole repair took about 45 ms, and the user saw nothing except a small dip in the throughput graph. This is exactly what the mechanism is designed for.

Which parameters matter here

• beamFailureInstanceMaxCount and the BFD-RS period together decide the detection speed. 3 instances at 10 ms means about 30 ms. If you set n10 instead, the same blockage would take about 100 ms to be detected, and the user would probably notice the stall.
• candidateBeamRSList decides whether there is anywhere to escape to. If the network only put one SSB in this list, the UE has no alternative and this scenario turns into Example 05.
• rsrp-ThresholdSSB decides how good the escape beam must be. Setting it too high means the UE finds no candidate ; setting it too low means the UE jumps to a beam that is almost as bad as the failed one and fails again a moment later (a "ping-pong" of BFR attempts).

What you see in a log : a burst of beam failure instance indications in the UE MAC log, then a contention free PRACH with a preamble index that you can trace back to one specific entry of candidateBeamRSList, then a PDCCH in the recovery search space. On the network side, a PRACH arriving on a dedicated preamble that was never assigned for a handover is the fingerprint of BFR.

Example 02 : Walking around a street corner (LoS lost, reflection found)

You are walking along a street with a good line of sight to a mmWave small cell on a lamp post, and you turn the corner into a side street. The building at the corner now stands between you and the gNB.

What happens physically : the direct path disappears completely and it does not come back. Unlike the hand blockage, this is a permanent change of the propagation environment for as long as you stay in the side street. However, mmWave signals reflect quite well from glass and concrete, so there is very often a usable path bouncing off the building on the opposite side of the street.

What the UE does : the detection part is exactly the same as Example 01. The interesting part is the candidate beam search. The beam that the UE picks now is not pointing at the gNB at all - it is pointing at a wall. From the UE point of view this does not matter in the slightest. It only knows that SSB#12 has an L1-RSRP above rsrp-ThresholdSSB, and that the network told it which preamble to use for SSB#12.

This is a good example of why the candidate beam list has to be built from real measurements and not from geometry. A planning tool would say "there is a building in the way, no service here", but the reflected beam works perfectly well.

The difference from Example 01 : because the change is permanent, what follows the recovery is also different. After BFR the network will normally update the TCI states so that PDCCH, PDSCH and CSI-RS all move to the new beam, and the UE goes back to normal operation on the reflected path. In the hand blockage case, the original beam usually becomes good again within a second, and the network moves the UE back.

NOTE : This scenario is also the reason why an operator cares about the number of SSB beams in a mmWave cell. More beams means a better chance that a reflected path is covered by one of them, which means fewer BFR failures. It also means a longer SSB burst and more overhead, so it is a trade off.

Example 03 : A truck passes by (the case where BFR should NOT trigger)

You are standing at a bus stop with a good beam, and a bus drives between you and the gNB. The blockage lasts about 200 ms and then everything is fine again.

This scenario is included because it shows the other side of the parameter tuning. Recovering fast is good, but recovering from something that would have healed by itself is a waste, and it is not free :

• The PRACH transmission costs uplink power and takes a dedicated preamble resource.
• The network has to reconfigure the beam, then reconfigure it back a moment later.
• During the switching, scheduling is interrupted anyway, so an unnecessary recovery can hurt the throughput more than the blockage itself.

The two parameters that protect against this are worth understanding together, because they work as a pair.

• beamFailureInstanceMaxCount is the "how many bad measurements in a row" counter. Raising it makes the UE more patient.
• beamFailureDetectionTimer is the "forget about it" timer. Every time a bad instance is reported, the timer is restarted. If the timer expires without a new bad instance, the counter is reset to zero. Note that its values (pbfd1, pbfd2 ...) are counted in periods of the BFD reference signal, not in milliseconds.

So the real question that the UE is asking is not "is the beam bad ?" but "has the beam been bad, continuously, for long enough that I should stop hoping ?". A single bad measurement caused by a passing car is forgotten by the timer. A real blockage produces bad instances back to back and reaches the counter.

In practice, an operator tunes this against the mobility profile of the cell. A cell covering a busy road with a lot of passing vehicles is usually configured to be more patient than a cell covering a fixed installation.

Example 04 : Rotating the device / raising the phone to the ear

You are in a video call holding the phone in front of you, and you raise it to your ear to talk. The phone rotates by roughly 90 degrees in about half a second.

What happens physically : a mmWave phone has several antenna modules (panels) - typically one at the top, one at the side and one at the back - precisely because no single panel can cover all directions once a hand and a head are involved. When the device rotates, the panel that was serving the connection now faces the wrong way, and at the same time it may become blocked by the head.

What is special about this case : the recovery is not just a change of the gNB beam, it is a change of which UE panel is used. The candidate beam that the UE reports may even be the same SSB index that was serving before - the gNB side did not change at all - but the UE now receives it through a different panel with a different receive beam.

This is invisible in the signalling, because the specification never talks about UE panels in Release 15. The UE simply says "I want SSB#7" by sending the preamble mapped to SSB#7, and how it internally receives SSB#7 is entirely up to the implementation. This is one of the reasons why two phones with the same chipset but different antenna placement can behave very differently in the same spot.

NOTE : Because the rotation is a mechanical movement, it is slow compared with the radio. Half a second is an eternity for a MAC layer working in tens of milliseconds. This means that a good implementation usually finishes BFR (or avoids it completely, by reporting a better beam through normal CSI reporting before the failure occurs) well before the movement is finished.

Example 05 : No candidate beam is found - BFR fails and RLF follows

You walk into an elevator, or into a basement corridor, while connected on mmWave. The serving beam dies, and so does every other beam of that cell.

This is the negative case, and it is important to understand because it shows the boundary of what BFR can do. Beam failure recovery repairs a beam problem. It cannot repair a coverage problem. If the cell simply cannot reach you any more, no amount of beam switching will help.

What happens step by step :

• The BFI counter reaches beamFailureInstanceMaxCount as usual, and beam failure is declared.
• The UE goes through candidateBeamRSList and finds that no entry has an L1-RSRP above rsrp-ThresholdSSB.
• Because there is no candidate with a dedicated preamble, the UE falls back to an ordinary contention based random access on the best SSB it can find, if any.
• Each preamble attempt is repeated with power ramping (powerRampingStep) up to preambleTransMax attempts. Meanwhile beamFailureRecoveryTimer is running.
• When the attempts are exhausted, the MAC layer reports a random access problem to RRC. Together with the radio link monitoring result, this leads the UE to declare radio link failure and start RRC re-establishment - typically on the LTE anchor or on an FR1 NR cell, which is where the service actually continues.

Why this matters in practice : in a real FR2 deployment this is the normal end of a mmWave session, and it is not a fault. The network is designed so that FR2 gives you high throughput while it is available, and FR1 or LTE catches you when it is not. What an engineer should check in this situation is not "why did BFR fail" but "how quickly did the UE get back onto a usable cell".

NOTE : This is exactly why beamFailureRecoveryTimer exists and why it is short (ms10 to ms200). It puts an upper bound on how long the UE is allowed to keep trying the dedicated BFR resources. Without this bound, the UE would waste time trying to repair a beam in a place where there is no coverage at all, instead of falling back and recovering the service.

Example 06 : Beam failure on an SCell in Carrier Aggregation (Release 16)

A UE is aggregating an FR1 PCell with an FR2 SCell. The FR2 beam is blocked, but the FR1 connection is perfectly healthy.

Everything described so far assumed that the failed beam is the only way to reach the network. In carrier aggregation that assumption is wrong, and Release 16 takes advantage of it.

• In Release 15, the BFR request is carried by PRACH. This makes sense for the primary cell, because if the PCell beam is broken there is no other way to talk to the network. But sending a PRACH on the SCell to report an SCell problem is slow and clumsy when a perfectly good uplink already exists on the PCell.
• In Release 16, the UE instead sends a scheduling request on the PCell and then reports the failure with a BFR MAC CE, which carries the index of the failed SCell and the index of the new candidate beam. No PRACH is involved on the failing carrier at all.

This is a good example of a general principle in the design of 5G : the recovery mechanism is chosen according to what is still working. If nothing is working, use random access, because it is the only channel that needs no prior configuration. If something is still working, use it, because it is faster.

From a testing point of view, this also means that an SCell beam failure and a PCell beam failure look completely different in a log even though the physical cause may be identical. If you are looking for PRACH and you do not find it, check the MAC CEs on the PCell before concluding that nothing happened.

Example 07 : A fixed wireless access CPE and a tree in the wind

An FWA (Fixed Wireless Access) modem is mounted on the outside wall of a house, aimed at a mmWave site 200 m away. There is a tree between them. Everything works perfectly in winter, and the customer complains in spring.

This scenario is interesting because it is the opposite of everything above : the device never moves, and yet beam failure happens repeatedly.

• Foliage : leaves attenuate mmWave heavily. A path that has 5 dB of margin through bare branches can lose 15 dB or more once the tree is in leaf, which is why the problem appears seasonally.
• Wind : this is what turns a static loss into a beam failure. The branches move, so the attenuation fluctuates by several dB on a time scale of a second or so. Every gust can push the quality below Qout,LR for a few measurement periods.
• Rain : adds its own attenuation, and wet leaves are considerably worse than dry ones.

What you see in the network statistics is a cell with a normal average RSRP but an abnormally high BFR count, concentrated on one or two UEs, and correlated with the weather rather than with the traffic. This pattern - high BFR rate with good average signal level - almost always means an intermittent blocker rather than a coverage hole.

The fix is usually physical (move or re-aim the CPE so that it uses a different, cleaner path, which may well be a reflected one) rather than a parameter change. But on the parameter side, this is the classic case for making the UE more patient : a larger beamFailureInstanceMaxCount so that a one second gust does not trigger a recovery, since for a fixed installation the beam will almost certainly be the same one afterwards anyway.

Summary of the scenarios

Putting all of them side by side makes the pattern easy to see.

If you read the table from left to right, you will notice that only two questions really decide everything : how long is the blockage, and is there another beam to go to. Every parameter on this page exists to help the UE answer one of those two questions correctly, and every tuning mistake comes from answering one of them too quickly or too slowly.

Reference

• 3GPP TS 38.214 - 5G;NR; Physical layer procedures for data
• 3GPP TS 38.331 - 5G;NR;Radio Resource Control (RRC); Protocol specification
• Beam Management in Millimeter-Wave Communications for 5G and Beyond