Systems and methods for recovery from a beam failure of a opportunistic device

Abstract

The present disclosure relates to recovery from beam failure for opportunistic devices. Disclosed herein are systems and procedures for measuring link metrics for a plurality of reference signals associated with a plurality of beams from a base station. These systems and methods are used to determine that a link metric value is less than or equal to a predetermined threshold. These systems and procedures include detecting a beam failure, classifying a beam recovery as high priority, opportunistic beam failure recovery, and performing an optimal random access channel (RACH) procedure through intelligent selection of beams and modules.

Description

[0001] Priority requirements

[0002] This application claims priority to U.S. Patent Application Serial No. 63 / 248,308, filed September 24, 2021, pursuant to 35 U.S. SC §119(e), the entire contents of which are incorporated herein by reference. Background Technology

[0003] Wireless communication networks provide an integrated communication platform and telecommunications services to wireless user equipment. Exemplary telecommunications services include telephone, data (e.g., voice, audio, and / or video data), messaging, internet access, and / or other services. The wireless communication network has wireless access nodes that exchange wireless signals with the wireless user equipment using wireless network protocols, such as those described in various telecommunications standards issued by the 3rd Generation Partnership Project (3GPP). Exemplary wireless communication networks include Long Term Evolution (LTE) and 5G New Radio (5G NR). Summary of the Invention

[0004] This specification describes a system and procedure for device recovery from beam failures, such as for 5G NR networks. When a beam failure is detected, the UE immediately begins attempting to recover the beam. The UE does not wait for the BeamFailureIndication counter to run out or the BeamFailureDetection timer to expire. Typically, when a beam failure is detected, the UE begins counting beam failure detections. When a threshold number of detections is reached and the beam failure timer expires, the UE begins beam recovery using Random Access Channel (RACH) messages. While waiting for the counter to run out or the timer to expire, the legacy UE reconnects to the NR network (if available). The procedure described herein allows the UE to bypass timer and counter requirements and recover the beam more quickly.

[0005] When a User Equipment (UE) operates in Evolved Universal Terrestrial Radio Access - New Radio (EN-DC), the base station serving the UE (e.g., a gNodeB (gNB)) configures the UE to transmit measurement reports of Channel State Information Reference Signal (CSI-RS) resources, Synchronization Signal Block (SSB) resources (also known as SS / Physical Broadcast Channel (PBCH) or SS / PBCH), or both CSI-RS resources and SSB resources. Each SSB resource may be associated with beams from multiple beams called SSB beams. The UE searches for and measures SSB beams. The UE maintains a candidate beam set. The candidate beam set may contain beams from multiple cells in the network. The UE uses the Physical Cell ID (PCI) and beam ID to identify a specific beam in the set.

[0006] The UE reports the SSB ID and corresponding Reference Signal Received Power (RSRP) in the Channel State Function. The network, which assigns Transmit Configuration Indicator (TCI) states in the MAC-CE, instructs the UE to move to a specific TCI corresponding to the SSB ID. The TCI states are dynamically sent in Downlink Control Information (DCI) messages. DCI messages include configurations such as the quasi-co-address (QCL) relationship between downlink (DL) reference signals (RS) and physical data shared channel (PDSCH) demodulation reference signals (DMRS) ports in a CSI-RS set. The UE can configure a list of up to “M” TCI-State configurations within the higher-layer (RRC ReConfig) parameter PDSCH-Config to decode the PDSCH based on the detected PDCCH with DCI for the UE and a given serving cell, where M depends on the UE capability maxNumberActiveTCI-PerBWP.

[0007] Each TCI state contains parameters for configuring the QCL relationship between one or two downlink reference signals and the DM-RS port of the PDSCH, the DM-RS port of the PDCCH, or the CSI-RS port of the CSI-RS resource. The QCL relationship is configured by the qcl-Type1 parameter of the first DLRS (RRC Reconfig) and the qcl-Type2 parameter of the second DLRS. A maximum of two qcl-types can be configured for each TCI state. For the case of two DLRSs, the QCL types are different regardless of whether the reference is for the same DLRS or different DLRSs.

[0008] The UE uses the SSB ID received in MAC-CE. In some implementations, the SSB signal can be affected by the UL block bit error rate (BLER). The base station may misinterpret the SSB index encoded in the CSF due to UL BLER. UL UCI may be lost. As a result, the UE uses a relatively weak beam (e.g., an incorrect or suboptimal beam) and does not switch to a better beam. Using a weaker beam can result in a relatively high BLER compared to using a stronger beam. The beam may eventually fail, causing the UE to initiate a beam failure recovery process, followed by NR secondary cell group (SCG) connectivity failure. In another example, the UE selects a beam with poor energy metric, resulting in a high BLER. The UE eventually enters beam failure recovery mode, followed by NR removal. The result is a poor user experience because data stagnates on 5G-NR. Users may not be able to use 5G NR and experience lower data throughput.

[0009] To overcome these potential problems, the UE performs opportunistic beam fault recovery. The UE performs beam fault recovery without waiting for the beam fault indication counter to expire. The UE performs beam fault recovery without waiting for the beam fault detection timer to expire.

[0010] Opportunistic beam fault recovery offers one or more of the following advantages. These operations enable faster beam recovery for the UE compared to conventional beam recovery. The UE does not have to wait for the NR cell to be removed to restore the beam. The UE avoids data stagnation. Data stagnation can occur when the SSB's beam RSRP tilts down just after the network instructs the UE to move to an incorrect SSB. Beam fault recovery allows the UE to avoid switching to an incorrect SSB, thus avoiding data stagnation. In another example, the UE's data payload increases because the UE can maintain NR connectivity more reliably. The UE avoids spending time and computational resources on unnecessary and incorrect SSB handovers and can use those resources to maximize data throughput. This improves the overall data experience, and users are less likely to experience dropped 5G NR connections.

[0011] Details of one or more embodiments of these systems and methods are set forth in the following figures and description. Other features, objects, and advantages of these systems and methods will be apparent from the specification, figures, and claims. Attached Figure Description

[0012] Figures 1A-1B This includes flowcharts illustrating, according to some implementation schemes, the process for recovering from a servo device failure.

[0013] Figure 2 It shows the relationship with Figures 1A-1B The flowchart of the state machine used together with the process.

[0014] Figure 3 A flowchart illustrating the process for recovering from a servo device that has experienced a transmit beam failure is shown.

[0015] Figure 4 Examples of wireless networks based on some implementation schemes are shown.

[0016] Figure 5 Examples of user equipment (UE) according to some implementation schemes are shown.

[0017] Figure 6 Examples of access nodes based on some implementation schemes are shown. Detailed Implementation

[0018] This specification describes a system and procedure for device recovery from beam failures in 5G NR networks. The UE performs beam failure recovery without waiting for the beam failure indicator counter to expire. When the UE detects a beam failure immediately, it begins the beam recovery procedure immediately (e.g., with minimal delay). In a conventional procedure, the UE sets the BeamFailureIndication parameter to true and increments the counter. The UE starts running the BeamfailureDetection timer. When the BeamfailureDetection counter reaches a threshold and the BeamFailureDetection timer expires, the UE enters beam failure recovery mode. The UE uses the Random Access Channel (RACH) procedure to send messages to connect to the NR network.

[0019] The process described in this paper enables the UE to perform beam fault recovery without waiting for the beam fault detection timer to expire or the counter to reach a threshold. This process allows the UE to bypass timer and counter requirements and recover the beam more quickly.

[0020] Figures 1A-1B An exemplary process 100 for beam fault recovery is shown. Figure 1A The process connects at points B and C. Figure 1B The process 100. The UE may include subsequent information regarding... Figures 5-6 The UE 600 is described. For procedure 100, opportunistic beam failure recovery is performed without the UE waiting for the BeamFailureIndication counter to run out or the BeamFailureDetection timer to expire. The UE avoids moving from the NR beam, which is eventually removed when the SSB is affected by UCI damage, UL BLER, or bad RF.

[0021] The UE uses RRC reconfiguration to establish a connection (102). The UE operates using NR beamforming and transmits and receives data using data streams (103). The UE can detect one of two scenarios. In some specific implementations, the UE detects (104) that the SSB is affected by uplink (UL) BLER. The SSB can be affected by uplink BLER because, due to UL BLER, the SSB index encoded in the CSI is affected by the base station (e.g., Figure 5 The access node (500) is incorrectly decoded. The base station may incorrectly decode the SSB index when the UL uplink control information (UCI) is lost, and the UE remains on a relatively weak beam compared to the ideal or strongest beam.

[0022] In the second scenario, the UE detects (106) a beam failure. In this scenario, the UE executes state machine (108) to determine whether to execute a high-priority recovery procedure or a low-priority recovery procedure. Each of these procedures is subsequently described and illustrated as follows. Figures 1A-1B Part of it.

[0023] Go to Figure 2 The state machine 200 executed at step 108 is now described. State machine 200 determines whether the UE is in a high-priority mode or a low-priority mode. State machine 200 receives (202) input data, which includes beam metrics such as frequency, RSRP value, SNR value, confidence scenario data, mobility mode, BWP, and high / low throughput indicators. If the UE is operating in FR1, the UE proceeds to decision point 214. If the UE is operating in FR2, the UE proceeds to decision point 204.

[0024] For FR2, the UE determines (204) whether the FR2 RSRP is worse than the RSRP threshold. If the FR2 RSRP remains below the threshold, a beam failure is likely occurring. In some implementations, the threshold used for testing is approximately -103 dBm. However, the UE may be configured with an external RSRP value based on heuristic data or other calibration procedures. The UE also checks the uplink SNR value to determine if the SNR value meets the SNR threshold. When the beam's SNR is below the threshold, the network switches the UL path from NR to LTE. In some implementations, the SNR threshold is approximately 15 dB. However, the UE may be configured with an external RSRP value based on heuristic data or other calibration procedures. If the FR2 RSRP exceeds the RSRP threshold and the UL SNR is less than the SNR threshold, the UE proceeds to step 206. Otherwise, when the RSRP is less than the threshold or the SNR exceeds the SNR threshold, the state machine outputs (222) a low-priority mode output.

[0025] If the low-priority scenario is not selected, the UE proceeds to determine if the (206) mmWave operating frequency is greater than a threshold frequency. For example, the threshold is typically 29 GHz. Most cellular communication is typically below 29 GHz. Such frequencies cover distances up to 200-250 meters. When the operating frequency is greater than approximately 29 GHz, communication is unaffected or minimally affected by high atmospheric pressure and path loss. In this case, the UE should directly enter the beam fault recovery algorithm. Typically, operating frequencies above 29 GHz cover distances up to approximately 100-150 meters. If the threshold frequency is met, the UE proceeds to check the confidence and throughput associated with the current beam. Otherwise, the state machine outputs (222) the low-priority mode output.

[0026] When the mmWave frequency is greater than 29 GHz, the UE proceeds to determine (208) whether the UE is operating in both high-throughput mode and high-confidence mode. For example, the UE checks the nature of data activity and determines whether it is a high-throughput, high-confidence state. To detect a high-confidence state, the UE detects data over a period of time. Specifically, the UE checks the data threshold within a threshold time period. In a particular example, when the data exceeds approximately 16 Mbps for approximately 4 seconds, the UE determines that a high-confidence, high-throughput scenario exists.

[0027] When the beam is in both high throughput mode and high confidence mode, the UE proceeds to check mobility mode. Otherwise, if low throughput or low confidence mode is used with the current beam, the state machine outputs (222) low priority mode output.

[0028] When the high-confidence, high-throughput mode of the current beam is confirmed, the UE proceeds to determine (210) whether the motion mode indicates that motion is occurring. Specifically, the UE checks the input used for motion detection. The UE checks for stationary or pedestrian movement. A slowly moving UE is likely to have a beam fault within a challenging RF. If the detected motion is a moving vehicle or high speed, the UE is likely to be out of the faulty RF, and the UE may delay beam recovery for a certain period of time.

[0029] The UE checks each of the stationary and pedestrian movement modes. If the motion input is true for both modes, the state machine outputs (212) a high-priority output. Otherwise, if either of the movement modes indicates that no movement has occurred, the state machine outputs (222) a low-priority mode.

[0030] For FR1, the UE determines (214) whether the FR1 RSRP is worse than an RSRP threshold, which is typically different from the FR2 RSRP threshold. If the RSRP remains below the threshold, a beam failure is likely occurring. In some implementations, the threshold used for testing is approximately -112 dBm. However, the UE may be configured with an external RSRP value based on heuristic data or other calibration procedures. The UE also checks the uplink SNR value to determine if the SNR value meets the SNR threshold. When the beam's SNR is below the threshold, the network switches the UL path from NR to LTE. In some implementations, the SNR threshold is approximately 4 dB. However, the UE may be configured with an external RSRP value based on heuristic data or other calibration procedures. If the FR1 RSRP exceeds the RSRP threshold and the UL SNR is less than the SNR threshold, the UE outputs a high-priority output (212). Otherwise, when the RSRP is less than the threshold or the SNR exceeds the SNR threshold, the UE proceeds to step 216.

[0031] If the low-priority scenario is not selected, the UE proceeds to determine (216) whether the mmWave operating frequency is greater than a threshold frequency. For example, the threshold is typically 29 GHz. Most cellular communication is typically below 29 GHz. Such frequencies cover distances up to 200-250 meters. When the operating frequency is greater than approximately 29 GHz, communication is immune or nearly immune to high atmospheric pressure and path loss. In this case, the UE should directly enter the beam fault recovery algorithm. Typically, operating frequencies above 29 GHz cover distances up to approximately 100-150 meters. If the threshold frequency is met, the state machine outputs (212) high-priority mode. Otherwise, the UE proceeds to check the confidence and throughput associated with the current beam and proceeds to step 218.

[0032] When the mmWave frequency is less than a threshold, the UE proceeds to determine (218) whether the UE is operating in both high-throughput mode and high-confidence mode. For example, the UE checks the nature of data activity and determines whether it is a high-throughput, high-confidence state. To detect a high-confidence state, the UE checks the data over a period of time. Specifically, the UE checks the data threshold within a threshold time period. In a particular example, when the data is greater than approximately 16 Mbps for approximately 4 seconds, the UE determines that a high-confidence, high-throughput scenario exists. When the beam is in both high-throughput mode and high-confidence mode, the state machine outputs (212) high-priority mode. Otherwise, if a low-throughput or low-confidence mode is used with the current beam, the UE proceeds to check the mobility mode.

[0033] When a low-confidence or low-throughput mode of the current beam is confirmed, the UE proceeds to determine (220) whether the motion mode indicates that motion is occurring. Specifically, the UE checks the input used for motion detection. The UE checks for stationary or pedestrian movement. A slowly moving UE is likely to have a beam fault within a challenging RF. If the detected motion is a moving vehicle or high speed, the UE is likely to be out of the problematic RF, and the UE may delay beam recovery for a certain period of time.

[0034] The UE checks each of the stationary and pedestrian movement modes. If the motion input is true for both modes, the state machine outputs (212) a high-priority output. Otherwise, if either movement mode indicates that motion has not occurred, the state machine outputs (222) a low-priority mode. Therefore, the state machine's result is either a high-priority output or a low-priority output.

[0035] return Figures 1A-1B At step 108, execute Figure 2The UE refreshes (112) the beam fault recovery timer T1 to reset the state machine register value. Then, the UE determines (114) whether a beam fault recovery configuration is configured for the active uplink bandwidth portion (BWP). If such a configuration exists, the UE determines (116) whether the beam fault recovery timer T1 has run. If the beam fault recovery timer T1 has run, the UE returns to step 103 where the data flow occurs.

[0036] If the beam fault recovery timer has not yet run, then for beam fault recovery timers from Figure 2 Upon receiving the high-priority output of the state machine's state, the UE changes the BeamFailureRecovery timer (118) to t+x1. In some implementations, x1 can be any value in milliseconds. Adding an offset x1 to the timer shortens the timer and enables beam recovery more quickly. The UE then starts (120) running the beam failure recovery timer and proceeds to initiate (146) the random access procedure (RACH) on the SpCell. In this way, the UE initiates beam failure recovery much faster than the timing of a conventional beam failure recovery procedure.

[0037] For scenarios where the UE encounters problems decoding the SSB due to uplink BER, the UE performs a procedure similar to that previously described for when the UE detects a beam fault. The UE detects (104) that the SSB is affected by the UL BLER. Then, the UE determines (122) whether the beam fault recovery timer configuration is configured for the active uplink bandwidth portion. This step is similar to step 114 previously described.

[0038] If the UE determines that beam fault recovery is configured for active uplink BWP, the UE determines (138) whether beam fault recovery has been run. This check is similar to step 116 described previously. If the beam fault recovery timer has been run, the UE returns to data flow step 103. If the beam fault recovery timer has not been run, the UE determines (140) whether high-speed motion mode has been triggered. If high-speed mode has been triggered, the UE changes the beam recovery timer to t+x2 to make the timer active for high-speed motion. In some specific implementations, x2 can be any value in milliseconds. This scenario can occur when the UE is in high-speed motion, such as being on a train or other vehicle. Adding offset x2 to the timer shortens the timer and helps to start beam fault recovery faster. The UE then starts (144) the beam fault recovery timer. If high-speed motion mode has not been triggered, offset x2 is not added, and the UE proceeds directly to step 144 where the beam recovery timer is started. The UE then prepares to start (146) the RACH procedure.

[0039] In each of steps 114 and 122, the UE determines whether the beam fault recovery configuration is configured for the active uplink BWP. Recall that for step 114, this is performed when a beam fault is detected, and for step 122, this occurs when SSB decoding is affected by uplink BLER. When the beam fault recovery configuration is not configured for the active uplink bandwidth portion, the UE initiates a (124) RACH procedure on the SpCell. In this context, the UE initiates a RACH procedure to initiate sub-procedure 101, in which the UE executes the RACH procedure when the beam fault recovery configuration is not configured for the active uplink bandwidth portion.

[0040] In sub-procedure 101, the UE determines (126) whether the RACH procedure was successful on the SpCell. If the RACH procedure is successful, the UE has reconnected to the base station and beam fault recovery has been successfully completed (128). If the RACH procedure is unsuccessful, the UE increments (130) the RACH procedure counter. If the count is below a threshold, the UE repeats sub-procedure 101 until the RACH procedure is successful or until the counter actually exceeds the threshold number of attempts. When the counter value exceeds the threshold, the UE resets (134) the counter and declares (136) an SCG fault.

[0041] Returning to step 146, the UE executes the RACH procedure on the SpCell in a context where the beam fault recovery configuration is configured for the uplink bandwidth portion. In this context, the beam fault recovery timer is just started with an appropriate offset x1 and / or x2 in milliseconds, depending on whether high-speed movement has occurred, whether a beam fault has been detected, and / or whether the UE decoding of the SSB is affected by uplink BLER. When the UE starts the (146) RACH procedure in this context, the UE executes... Figure 1B The remainder of process 100 shown.

[0042] The UE determines (152) whether the RACH is successful on the SpCell. When the UE RACH is successful, the UE stops (154) the beam recovery timer and declares (156) beam recovery complete. If the RACH is unsuccessful, the UE performs the following procedure, which ensures the selection of the best beam and the best antenna module for the UE to attempt the best solution for RACH.

[0043] The UE is configured to determine whether the (158) beam fault timer has expired. If the timer has expired, the UE declares a (160) SCG fault.

[0044] If the beam failure timer has not expired, the UE locks (162) to a different beam of the same antenna module as the current beam. During the first RACH attempt, the UE has selected the best possible beam and module. If the RACH fails, the UE can use a similar beam type and module, but with a different beam to increase the probability of a successful RACH in subsequent attempts. The UE increments (164) the RACH procedure counter. If the counter does not exceed a first threshold, the UE repeats the RACH procedure from steps 146, 152, 158, and 162.

[0045] If the UE exceeds the first threshold in step 166, the UE resets the counter value in step 168. The UE may switch or lock (170) to a different antenna module to increase the probability of RACH success. The UE increments (172) the PRACH procedure counter. If the counter does not exceed the second threshold, the UE repeats the RACH procedure from steps 146, 152, 158, and 162 using a different antenna panel until the threshold number of attempts is reached.

[0046] After multiple RACH iterations, the UE checks (174) a second threshold UE value to determine whether to check different antenna modules (modules). The UE resets the RACH counter and checks the thermal ambient temperature of each module before determining whether to switch to another antenna module. For example, the UE switches antenna modules to attempt the RACH process. The UE checks the thermal ambient temperature and temperature of each antenna module (m1, m2, m3, etc.). The UE determines (178) whether the ambient temperature is less than the threshold temperature of the first antenna module. If the temperature is less than the threshold (e.g., 28 degrees Celsius (°C)), the UE selects (188) the first module for RACH. If the temperature exceeds the temperature threshold, the UE proceeds to the next antenna module.

[0047] The UE determines (180) whether the ambient temperature of the second RACH module is lower than a threshold temperature. If the second temperature is lower than the second threshold temperature (e.g., 28 degrees (°C)), the UE selects (186) the second module for RACH. Otherwise, the UE proceeds to the next (third) temperature module.

[0048] The UE determines (182) whether the ambient temperature of the third antenna module is lower than a threshold temperature. If the third temperature is lower than the second threshold temperature (e.g., 28 degrees (°C)), the UE selects (184) the third module for RACH. Otherwise, if a next temperature module exists, the UE proceeds to the next temperature module. If no antenna module has a temperature below the threshold temperature and RACH still fails, the UE declares (160) an SCG failure. In some specific implementations, each of the first, second, third, etc., modules can be any antenna module of the UE. If a module is selected, the UE returns to the start (146) RACH procedure as previously described.

[0049] Figure 3 A flowchart illustrating a process 300 for recovering from a servo device failure in a transmit beam is shown. Process 300 can be described by... Figure 4 , Figure 5 and Figure 6 as well as Figure 1A-Figure 2 The described UE 402 or 500 performs the following procedure: Procedure 300 includes measuring (302) multiple reference signal received power (RSRP) values ​​of multiple reference signals associated with multiple beams from a base station. The procedure includes determining (304) that the maximum RSRP value is less than or equal to a predetermined threshold. Procedure 300 includes detecting (306) a beam fault based on the measured multiple RSRP values. Procedure 300 includes classifying (308) beam recovery as high priority based on the detected beam fault. In some implementations, classifying a beam fault as high priority includes testing a millimeter-wave frequency greater than or less than 29 GHz. In some implementations, classifying a beam fault as high priority includes comparing the beam throughput to a threshold. In some implementations, classifying a beam fault as high priority includes determining whether the UE is moving or stationary. In some implementations, classifying beam recovery as high priority causes the RACH recovery procedure to start immediately without waiting for the beam recovery timer to expire.

[0050] Process 300 includes performing a (310) random access channel (RACH) recovery process based on classifying beam recovery as high priority.

[0051] In some implementations, the RACH recovery process includes determining the number of RACH attempts using the first beam that satisfy a threshold number of RACH attempts. In some implementations, the RACH recovery process includes locking onto a second beam in the same antenna module as the first beam. In some implementations, the RACH recovery process includes performing RACH using the second beam.

[0052] In some implementations, the RACH recovery process includes determining the number of RACH attempts on the first antenna module that satisfy a threshold number of RACH attempts. In some implementations, the RACH recovery process includes measuring a first temperature associated with the first antenna module. In some implementations, the RACH recovery process includes selecting the first antenna module based on the first temperature being below a threshold temperature. In some implementations, the RACH recovery process includes performing RACH using a beam from the first antenna module.

[0053] In some implementations, the RACH recovery process includes measuring a second temperature associated with the second antenna module. In some implementations, the RACH recovery process includes selecting the second antenna module based on the second temperature being below a threshold temperature. In some implementations, the RACH recovery process includes performing RACH using a beam from the second antenna module.

[0054] In some implementations, the UE is operating in Evolved Universal Terrestrial Radio Access - New Radio (EN-DC). In some implementations, the base station is either a gNodeB (gNB) or an eNB.

[0055] Figure 4 A wireless network 400 according to some embodiments is illustrated. The wireless network 400 includes a UE 402 and a base station 404 connected across an air interface 408 via one or more channels 406a, 406b. The UE 402 and the base station 404 communicate using a system that supports control for managing the UE 402's access to the network via the base station 404.

[0056] For convenience and not limitation, Radio Network 400 is described in the context of Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards as defined by the 3rd Generation Partnership Project (3GPP) technical specifications. More specifically, Radio Network 400 is described in the context of non-standalone (NSA) networks that combine both LTE and NR, such as E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity (EN-DC) networks and NE-DC networks. However, Radio Network 400 can also be a standalone (SA) network that combines only NR. In addition, other types of communication standards are possible, including future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.11 technologies (e.g., IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; or other currently or future IEEE 802.11 technologies), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), etc. While this document may use terms commonly associated with 5G NR to describe aspects, aspects of this disclosure can be applied to other systems such as 3G, 4G, or systems beyond 5G (e.g., 6G).

[0057] In wireless network 400, UE 402 and any other UE in the system can be, for example, a laptop computer, smartphone, tablet computer, machine-type device such as a smart meter or dedicated device for healthcare monitoring, remote security monitoring, intelligent transportation system, or any other wireless device with or without a user interface. In network 400, base station 404 provides network connectivity for UE 402 to a wider network (not shown). This UE 402 connection is provided via air interface 408 within the base station service area provided by base station 404. In some embodiments, such a wider network can be a wide area network operated by a cellular network provider, or it can be the Internet. Each base station service area associated with base station 404 is supported by an antenna integrated with base station 404. The service area is divided into multiple sectors associated with certain antennas. Such sectors can be physically associated with fixed antennas, or can be assigned to physical areas with tunable antennas or antenna configurations that can be adjusted during beamforming to direct signals to a particular sector.

[0058] UE 402 includes control circuitry 410 coupled to transmitting circuitry 412 and receiving circuitry 414. Transmitting circuitry 412 and receiving circuitry 414 may each be coupled to one or more antennas. Control circuitry 410 may be adapted to perform operations associated with selecting a codec for communication and to debug the codec for wireless communication as part of system congestion control. Control circuitry 410 may include various combinations of dedicated circuitry and baseband circuitry. Transmitting circuitry 412 and receiving circuitry 414 may be adapted to transmit and receive data respectively and may include radio frequency (RF) circuitry or front-end module (FEM) circuitry, including communication using codecs as described herein.

[0059] In various implementations, aspects of the transmitting circuit 412, receiving circuit 414, and control circuit 410 can be integrated in various ways to implement the circuitry described herein. The control circuit 410 may be adapted or configured to perform various operations, such as the UE-related operations described elsewhere in this disclosure. The transmitting circuit 412 may transmit multiple multiplexed uplink physical channels. These multiple uplink physical channels may be multiplexed according to time division multiplexing (TDM) or frequency division multiplexing (FDM) and carrier aggregation. The transmitting circuit 412 may be configured to receive block data from the control circuit 410 for transmission across air interface 408. Similarly, the receiving circuit 414 may receive multiple multiplexed downlink physical channels from air interface 408 and relay these physical channels to the control circuit 410. These multiple downlink physical channels may be multiplexed according to TDM or FDM and carrier aggregation. The transmitting circuit 412 and the receiving circuit 414 may transmit and receive both control data and content data (e.g., messages, images, video, etc.) structured within data blocks carried by the physical channels.

[0060] Figure 4 Base station 404 is also shown. In embodiments, base station 404 may be an NG radio access network (RAN) or 5G RAN, E-UTRAN, non-terrestrial cell, or a traditional RAN such as UTRAN or GERAN. As used herein, the term "NG RAN" etc. may refer to base station 404 operating in an NR or 5G wireless network 400, and the term "E-UTRAN" etc. may refer to base station 404 operating in an LTE or 4G wireless network 400. UE 402 utilizes connections (or channels) 406a, 406b, each connection including a physical communication interface or layer.

[0061] The base station 404 circuit may include control circuitry 416 coupled to transmitting circuitry 418 and receiving circuitry 420. Transmitting circuitry 418 and receiving circuitry 420 may each be coupled to one or more antennas, which may be used to enable communication via air interface 408.

[0062] Control circuitry 416 is adapted to perform operations for: analyzing and selecting codecs; managing congestion control and bandwidth limiting communications from the base station; determining whether the base station is aware of the codecs; and communicating with the codec-aware base station to manage codec selection for the various communication operations described herein. Transmitting circuitry 418 and receiving circuitry 420 are adapted to transmit and receive data, respectively, to any UE connected to base station 404 using data generated by the various codecs described herein. Transmitting circuitry 418 can transmit downlink physical channels comprising multiple downlink subframes. Receiving circuitry 420 can receive multiple uplink physical channels from various UEs, including UE 402.

[0063] In this example, one or more channels 406a, 406b are shown as air interfaces for communication coupling and may be consistent with cellular communication protocols such as GSM, CDMA network protocols, PTT, POC, UMTS, 3GPP LTE, LTE-A (LTE-Advanced Long Term Evolution), LTE-U (LTE-U), 5G, NR, NR-U (NR-U), and / or any other communication protocols discussed herein. In an implementation, UE 402 may directly exchange communication data via the ProSe interface. The ProSe interface may also be referred to as the SL interface and may include one or more logical channels, including but not limited to PSCCH, PSSCH, PSDCH, and PSBCH.

[0064] Figure 5 An access node 500 (e.g., a base station or gNB) according to some embodiments is shown. Access node 500 may be similar to and substantially interchangeable with base station 404. Access node 500 may include processor 502, RF interface circuitry 504, core network (CN) interface circuitry 506, memory / storage device circuitry 508, and antenna structure 510.

[0065] Components of access node 500 can be coupled to various other components via one or more interconnects 512. Processor 502, RF interface circuitry 504, memory / storage device circuitry 508 (including communication protocol stack 514), antenna structure 510, and interconnects 512 can be similar to those described in reference [reference needed]. Figure 6 Similar named components are shown and described. For example, processor 502 may include processor circuitry such as baseband processor circuitry (BB) 516a, central processing unit circuitry (CPU) 516b, and graphics processing unit circuitry (GPU) 516c.

[0066] CN interface circuitry 506 can provide connectivity to a core network (e.g., a 5GC using a 5G core network (5GC) compatible network interface protocol (such as Carrier Ethernet) or some other suitable protocol). Network connectivity can be provided to / from access node 500 via fiber optic or wireless backhaul. CN interface circuitry 506 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, CN interface circuitry 506 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0067] As used herein, the terms "access node," "access point," etc., can describe equipment that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes can be referred to as BS, gNB, RAN node, eNB, NodeB, RSU, TRxP, or TRP, etc., and can include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN node," etc., can refer to an access node 500 (e.g., a gNB) operating in an NR or 5G system, and the terms "E-UTRAN node," etc., can refer to an access node 500 (e.g., an eNB) operating in an LTE or 4G system. According to various embodiments, the access node 500 can be implemented as one or more of dedicated physical equipment such as a macro cell base station and / or a low-power (LP) base station for providing a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macro cell.

[0068] In some implementations, all or part of the access node 500 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as CRAN and / or Virtual Baseband Unit Pool (vBBUP). In these implementations, the CRAN or vBBUP may implement RAN function partitioning, such as: PDCP partitioning, where the RRC and PDCP layers are operated by the CRAN / vBBUP and other L2 protocol entities are operated by the access node 500; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP and the PHY layer is operated by the access node 500; or "lower PHY" partitioning, where the upper portion of the RRC, PDCP, RLC, MAC, and PHY layers is operated by the CRAN / vBBUP and the lower portion of the PHY layer is operated by the access node 500.

[0069] In a V2X scenario, the access node 500 can be an RSU or act as an RSU. The term "roadside unit" or "RSU" can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, wherein an RSU implemented in or by a UE can be referred to as a "UE-type RSU", an RSU implemented in or by an eNB can be referred to as an "eNB-type RSU", an RSU implemented in or by a gNB can be referred to as a "gNB-type RSU", and so on.

[0070] Figure 6 A UE 600 according to some implementation schemes is shown. UE 600 may be similar to Figure 4 The UE 402 is essentially interchangeable with it. The UE 600 can be any mobile or non-mobile computing device, such as a mobile phone, computer, tablet, industrial wireless sensor (e.g., microphone, carbon dioxide sensor, pressure sensor, humidity sensor, thermometer, motion sensor, accelerometer, laser scanner, fluid level sensor, stock sensor, voltmeter / ammeter, actuator, etc.), video surveillance / monitoring device (e.g., camera, camcorder, etc.), wearable device (e.g., smartwatch), loosely coupled IoT device.

[0071] UE 600 may include a processor 602, RF interface circuitry 604, memory / storage device 606, user interface 608, sensor 610, drive circuitry 612, power management integrated circuit (PMIC) 614, antenna structure 616, and battery 618. The components of UE 600 may be implemented as integrated circuits (ICs), portions of integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 6 The block diagram is intended to show a high-level view of some of the components of the UE 600. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other specific implementations.

[0072] The components of UE 600 can be coupled to various other components via one or more interconnects 620, which can represent any type of interface, input / output, bus (local, system, or extension), transmission line, trace, optical connector, etc., allowing various circuit components (on common or different chips or chipsets) to interact with each other.

[0073] Processor 602 may include processor circuitry, such as baseband processor circuitry (BB) 622a, central processing unit circuitry (CPU) 622b, and graphics processing unit circuitry (GPU) 622c. Processor 602 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional processes from memory / storage device 606) to cause UE 600 to perform the operations described herein.

[0074] In some implementations, the baseband processor circuit 622a can access the communication protocol stack 624 in the memory / storage device 606 to communicate over a 3GPP-compliant network. Generally, the baseband processor circuit 622a can access the communication protocol stack to perform user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers; and control plane functions at the PHY, MAC, RLC, PDCP, RRC, and non-access layers. In some implementations, PHY layer operations may be additionally / optionally performed by components of the RF interface circuit 604. The baseband processor circuit 622a can generate or process baseband signals or waveforms carrying information from a 3GPP-compliant network. In some implementations, the waveforms used for NR may be based on Cyclic Prefix OFDM (“CP-OFDM”) in the uplink or downlink, and Discrete Fourier Transform Extended OFDM (“DFT-S-OFDM”) in the uplink.

[0075] Memory / storage device 606 may include one or more non-transitory computer-readable media, including instructions (e.g., communication protocol stack 624) that can be executed by one or more processors in processor 602 to cause UE 600 to perform the various operations described herein. Memory / storage device 606 includes any type of volatile or non-volatile memory that may be distributed throughout UE 600. In some embodiments, some memory / storage devices 606 may be located on processor 602 itself (e.g., L1 cache and L2 cache), while other memory / storage devices 606 may be located external to processor 602 but accessible via a memory interface. Memory / storage device 606 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0076] RF interface circuitry 604 may include transceiver circuitry and a radio frequency front-end module (RFEM), which allows UE 600 to communicate with other devices via a radio access network. RF interface circuitry 604 may include various components arranged in the transmit or receive path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0077] In the receiving path, the RFEM can receive the radiated signal from the air interface via antenna structure 616 and continue to filter and amplify the signal (using a low-noise amplifier). This signal can be provided to the receiver of the transceiver, which downconverts the RF signal into a baseband signal for the baseband processor of processor 602.

[0078] In the transmission path, the transceiver's transmitter upconverts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM amplifies the RF signal using a power amplifier before it is radiated across the air interface via antenna structure 616.

[0079] In various implementations, the RF interface circuit 604 can be configured to transmit / receive signals in a manner compatible with NR access technology.

[0080] Antenna structure 616 may include antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves back into electrical signals. These antenna elements may be arranged as one or more antenna modules. Antenna structure 616 may have omnidirectional, directional, or combinations thereof antenna modules to enable beamforming and multiple-input multiple-output communication. Antenna structure 616 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. Antenna structure 616 may have one or more modules designed for a specific frequency band included in FRI or FR2.

[0081] User interface 608 includes various input / output (I / O) devices designed to enable users to interact with UE 600. User interface 608 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual means for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). Output device circuitry may include any number or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary status indicators, such as light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs, such as display devices or touchscreens (e.g., liquid crystal displays, LED displays, quantum dot displays, projectors, etc.), wherein the output of characters, graphics, multimedia objects, etc., is generated or produced by the operation of UE 600.

[0082] Sensor 610 may include devices, modules, or subsystems designed to detect events or changes in their environment and transmit information about the detected events (sensor data) to other devices, modules, subsystems, etc. Examples of such sensors include, in particular: inertial measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including triaxial accelerometers, triaxial gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture sensors); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors, etc.); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other similar audio capture devices; etc.

[0083] The driving circuitry 612 may include software and hardware elements for operating specific devices embedded in, attached to, or otherwise communicatively coupled to the UE 600. The driving circuitry 612 may include individual drivers that allow other components to interact with or control various input / output (I / O) devices that may exist within or be connected to the UE 600. For example, the driving circuitry 612 may include: a display driver for controlling and allowing access to a display device; a touchscreen driver for controlling and allowing access to a touchscreen interface; a sensor driver for acquiring sensor readings of a sensor 610 and controlling and allowing access to the sensor 610; a driver for acquiring actuator positions of electromechanical components or controlling and allowing access to electromechanical components; a camera driver for controlling and allowing access to an embedded image capture device; and an audio driver for controlling and allowing access to one or more audio devices.

[0084] The PMIC 614 manages the power supplied to various components of the UE 600. Specifically, relative to the processor 602, the PMIC 614 controls power selection, voltage scaling, battery charging, or DC-DC conversion.

[0085] In some implementations, the PMIC 614 may control or otherwise become part of various power-saving mechanisms of the UE 600, including DRX, as discussed herein. The battery 618 may power the UE 600, but in some examples, the UE 600 may be mounted or deployed in a fixed location and may have a power source coupled to the grid. The battery 618 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, the battery 618 may be a typical lead-acid automotive battery.

[0086] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods as described in the Examples section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples below. Similarly, circuitry associated with the UE, base station, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples shown in the Examples section below.

[0087] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0088] Example

[0089] Example 1 may include a method for reporting reference signal measurements by a user equipment (UE) in a wireless communication system, the method involving: measuring multiple reference signal received power (RSRP) values ​​of multiple reference signals associated with multiple beams from a base station; determining that a maximum RSRP value is less than or equal to a predetermined threshold; detecting a beam fault in response to measuring the multiple RSRP values; classifying beam recovery as high priority in response to detecting a beam fault; and performing a random access channel (RACH) in response to classifying beam recovery as high priority.

[0090] Example 2 may include the method described according to Example 1 and / or some other embodiments herein, wherein classifying beam faults as high priority includes: testing millimeter wave frequencies greater than or less than 29 GHz.

[0091] Example 3 may include the method described according to Examples 1-2 and / or some other embodiments herein, wherein classifying beam faults as high priority includes: comparing the throughput of the beam with a threshold.

[0092] Example 4 may include the method described according to Examples 1-3 and / or some other embodiments herein, wherein classifying beam faults as high priority includes: determining whether the UE is moving or stationary.

[0093] Example 5 may include the method described according to Examples 1-4 and / or some other embodiments herein, wherein classifying beam recovery as high priority causes the RACH recovery process to start immediately without waiting for the beam recovery timer to expire.

[0094] Example 6 may include the method described according to Examples 1-5 and / or some other embodiments herein, wherein the UE operates in Evolved Universal Terrestrial Radio Access - New Radio (EN-DC).

[0095] Example 7 may include the method described according to Examples 1-5 and / or some other embodiments herein, wherein the base station is one of a gNodeB (gNB) or an eNB.

[0096] Example 8 may include an apparatus comprising one or more elements for performing a method or process described or associated with any of Examples 1-7 or any other method or process described herein.

[0097] Embodiment 9 may include one or more non-transitory computer-readable media, the one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the method or any other method or process described herein according to any one of Embodiments 1-7.

[0098] Example 10 may include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of the method described or associated with any of Examples 1-7 or any other method or process described herein.

[0099] Example 11 may include a method, technique, or process, or a part or component thereof, described or associated with any of Examples 1-7.

[0100] Example 12 may include an apparatus comprising one or more processors and one or more computer-readable media, the one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or a portion thereof, as described or associated with any of Examples 1-7.

[0101] Example 13 may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process, or a portion thereof, as described or associated with any of Examples 1-7.

[0102] Example 14 may include a system for providing wireless communication as shown and described herein.

[0103] Example 15 may include a device for providing wireless communication as shown and described herein.

[0104] Unless otherwise expressly stated, any of the examples above may be combined with any other example (or combination of examples). The foregoing description of one or more specific embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. In view of the teachings above, modifications and variations are possible, or modifications and variations may be derived from practice of various embodiments.

Claims

1. A method for wireless communication, the method comprising: Measure multiple reference signal metrics associated with multiple reference signals from multiple beams from a base station; Determine that the maximum reference signal metric value is less than or equal to a predetermined threshold; Based on the determination, a beam fault is detected; Based on the detection of beam faults, beam recovery is classified as a high priority. Based on classifying beam recovery as high priority, the random access channel RACH recovery process is performed.

2. The method according to claim 1, wherein the RACH recovery process comprises: Determine the number of RACH attempts using the first beam that satisfy the threshold number of RACH attempts; Locking onto the second beam in the same antenna module as the first beam; as well as RACH is performed using the second beam.

3. The method according to claim 1, wherein the RACH recovery process comprises: Determine the number of RACH attempts on the first module that satisfy the threshold number of RACH attempts; Measure the first temperature associated with the first antenna module; The first antenna module is selected based on the first temperature being lower than the threshold temperature. as well as RACH is performed using the beam from the first antenna module.

4. The method of claim 3, wherein the RACH recovery process comprises: Measure the second temperature associated with the second antenna module; The second antenna module is selected based on the second temperature being lower than the threshold temperature; as well as RACH is performed using the beam from the second antenna module.

5. The method of claim 1, wherein classifying the beam recovery as high priority comprises: The test millimeter wave frequency is greater than or less than 29 GHz.

6. The method of claim 1, wherein classifying the beam recovery as high priority comprises: The data throughput of at least one of the plurality of beams is compared with a threshold.

7. The method of claim 1, wherein classifying the beam recovery as high priority comprises: Determine whether the user equipment is moving or stationary.

8. The method of claim 1, wherein classifying the beam recovery as high priority causes the RACH recovery process to start immediately without waiting for the beam recovery timer to expire.

9. The method of claim 1, wherein the user equipment performing wireless communication operates in Evolved Universal Terrestrial Radio Access - New Radio (EN-DC).

10. The method of claim 1, wherein the base station is one of a gNodeB (gNB) or an eNB.

11. One or more processors, said one or more processors being configured to perform operations including: Measure multiple reference signal metrics associated with multiple reference signals from multiple beams from a base station; Determine that the maximum reference signal metric value is less than or equal to a predetermined threshold; Based on the determination, a beam fault is detected; Based on the detection of beam faults, beam recovery is classified as a high priority. Based on classifying beam recovery as high priority, the random access channel RACH recovery process is performed.

12. The processor of claim 11, wherein the RACH recovery process comprises: Determine the number of RACH attempts using the first beam that satisfy the threshold number of RACH attempts; Locking onto the second beam in the same antenna module as the first beam; as well as RACH is performed using the second beam.

13. The processor of claim 11, wherein the RACH recovery process comprises: Determine the number of RACH attempts on the first module that satisfy the threshold number of RACH attempts; Measure the first temperature associated with the first antenna module; The first antenna module is selected based on the first temperature being lower than the threshold temperature. as well as RACH is performed using the beam from the first antenna module.

14. The processor of claim 13, wherein the RACH recovery process comprises: Measure the second temperature associated with the second antenna module; The second antenna module is selected based on the second temperature being lower than the threshold temperature; as well as RACH is performed using the beam from the second antenna module.

15. The one or more processors of claim 11, wherein classifying the beam recovery as high priority comprises: The test millimeter wave frequency is greater than or less than 29 GHz.

16. The processor of claim 11, wherein classifying the beam recovery as high priority comprises: The data throughput of at least one of the plurality of beams is compared with a threshold.

17. The processor of claim 11, wherein classifying the beam recovery as high priority comprises: Determine whether the user equipment is moving or stationary.

18. One or more processors according to claim 11, wherein classifying the beam recovery as high priority causes the RACH recovery process to start immediately without waiting for the beam recovery timer to expire.

19. One or more processors as claimed in claim 11, wherein the user equipment of the one or more processors operates in Evolved Universal Terrestrial Radio Access - New Radio (EN-DC).

20. The processor of claim 11, wherein the base station is a gNodeB (gNB) or an eNB.

Images