Beam Failure Recovery Request Encoding on PUCCH Resources
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In 5G New Radio systems using high-frequency frequencies, beamforming is prone to blockages leading to unreliable channels between user equipment (UE) and next-generation NodeB, necessitating a mechanism for detecting and reporting beam failure recovery requests (BFRQ) to switch to more reliable channels.
Innovation Solution
A method and system for reporting BFRQs involve encoding demodulation symbols with orthogonal code sequences and sending them on physical uplink control channel (PUCCH) resources allocated for scheduling request transmissions, allowing for beam failure detection and recovery in both single and multi-carrier deployments.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If beamforming is used to overcome high pathloss in 5G NR systems, then signal coverage and reliability are improved, but the channels become fragile and prone to blockages
Solution Approach 1:
The system performs preliminary beam failure detection by monitoring downlink reference signals before complete channel collapse occurs. When beam failure is detected, a BFRQ is proactively transmitted on PUCCH resources allocated for scheduling requests, enabling preemptive beam recovery before communication is completely lost.
Solution Approach 2:
The patent uses PUCCH resources originally allocated for scheduling requests as an intermediary channel for BFRQ transmission. This existing uplink control channel serves as a mediator to carry beam failure recovery information without requiring dedicated BFRQ resources, enabling efficient beam recovery while maintaining reliable communication.
2Adaptability or versatility
If dedicated BFRQ reporting mechanisms are implemented, then beam recovery capability is improved, but uplink control channel resource requirements increase
Solution Approach 1:
The patent makes PUCCH resources serve multiple functions: they are used both for traditional scheduling request transmissions and for beam failure recovery request transmissions. This multi-functionality allows the system to support beam recovery capability without increasing uplink control channel resource requirements, as the same physical resources handle both SR and BFRQ purposes.
Solution Approach 2:
The patent merges the BFRQ transmission function with existing SR-based PUCCH resources. By combining these two functions into a single resource pool, the system achieves beam recovery capability while avoiding the need for separate dedicated BFRQ resources, thereby reducing overall device and network complexity.
3Productivity
If BFRQ is transmitted on SR-based PUCCH resources, then resource utilization efficiency is improved, but distinction between SR and BFRQ signals becomes challenging
Solution Approach 1:
The patent applies local quality differentiation by using distinct demodulation symbols for different message types within the same PUCCH resource. SR transmissions use one demodulation symbol while BFRQ transmissions use another, allowing the receiver to locally distinguish between the two signal types based on the specific demodulation symbol used, even though they share the same physical resources.
Solution Approach 2:
The patent changes the modulation parameter (demodulation symbol) to differentiate between SR and BFRQ signals. By varying this parameter based on the type of information being transmitted, the system enables clear signal differentiation at the receiver side while maintaining efficient use of shared PUCCH resources for both SR and BFRQ purposes.
Data Source
AI summary
A method for sending a beam failure recovery request (BFRQ) includes setting a demodulation symbol to a first value to specify a BFRQ signal, encoding the demodulation symbol with a first orthogonal code sequence, thereby producing an encoded first sequence of symbols, and send the encoded first sequence of symbols on a first physical uplink control channel (PUCCH) resource allocated for a first scheduling request (SR) transmission.