CN110351756B

CN110351756B - Beam failure recovery method, terminal, network device and computer storage medium

Info

Publication number: CN110351756B
Application number: CN201810301253.0A
Authority: CN
Inventors: 施源; 杨宇; 孙鹏
Original assignee: Vivo Mobile Communication Co Ltd
Current assignee: Vivo Mobile Communication Co Ltd
Priority date: 2018-04-04
Filing date: 2018-04-04
Publication date: 2021-03-19
Anticipated expiration: 2038-04-04
Also published as: CN110351756A; WO2019192473A1

Abstract

The invention discloses a beam failure recovery method, a terminal and network equipment, wherein the method comprises the following steps: under the condition that beam failure occurs, sending a beam failure recovery request to network equipment; detecting response information fed back by the network equipment according to the beam failure recovery request on a target control resource set CORESET; wherein, the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 having an identification value of 0. The terminal in the embodiment of the invention can avoid the problem of beam failure recovery failure caused by monitoring wrong resources in the beam failure recovery triggering process, thereby improving the success rate of beam failure recovery.

Description

Beam failure recovery method, terminal, network device and computer storage medium

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a beam failure recovery method, a terminal, and a network device.

Background

In a high-band communication system, since the wavelength of a radio signal is short, it is easy to cause a situation where signal propagation is blocked or the like, and signal propagation is interrupted. If the wireless link reconstruction in the prior art is adopted, the time consumption is long, so a Beam Failure Recovery (BFR) mechanism is introduced, after a Beam Failure occurs, the terminal sends a Beam Failure Recovery Request (Beam Failure Recovery Request, BERQ) to the network equipment side, and after receiving the Beam Failure Recovery Request, the network equipment sends response (response) information of the corresponding Beam Failure Recovery Request. The network device supports configuration of the response information on the CORESET (CORESET-BFR) for the BFR or on the CORESET0, but the terminal cannot determine on which CORESET the network device specifically transmits the response information, and if the terminal monitors the wrong CORESET, the terminal cannot receive the response information, which results in failure of beam failure recovery.

Disclosure of Invention

The embodiment of the invention provides a beam failure recovery method, a terminal and network equipment, which aim to solve the problem of beam failure recovery failure caused by the fact that the terminal cannot determine which CORESET is monitored.

In a first aspect, an embodiment of the present invention provides a method for recovering a beam failure, which is applied to a terminal side, and includes:

under the condition that beam failure occurs, sending a beam failure recovery request to network equipment;

detecting response information fed back by the network equipment according to the beam failure recovery request on a target control resource set CORESET; wherein, the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 having an identification value of 0.

In a second aspect, an embodiment of the present invention further provides a terminal, including:

a sending module, configured to send a beam failure recovery request to a network device when a beam failure occurs;

the detection module is used for detecting response information fed back by the network equipment according to the beam failure recovery request on the target control resource set CORESET; wherein, the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 having an identification value of 0.

In a third aspect, an embodiment of the present invention provides a terminal, where the terminal includes a processor, a memory, and a computer program stored in the memory and being executable on the processor, and the computer program, when executed by the processor, implements the steps of the beam failure recovery method described above.

In a fourth aspect, an embodiment of the present invention provides a beam failure recovery method, applied to a network device side, including:

receiving a beam failure recovery request from a terminal side;

after receiving the beam failure recovery request, feeding back response information on a target control resource set (CORESET); wherein, the target CORESET comprises: a control resource set CORESET-BFR for beam failure recovery or at least one of CORESET0 identifying a value of 0.

In a fifth aspect, an embodiment of the present invention provides a network device, including:

a receiving module, configured to receive a beam failure recovery request from a terminal side;

the feedback module is used for feeding back response information on the target control resource set CORESET after receiving the beam failure recovery request; wherein, the target CORESET comprises: a control resource set CORESET-BFR for beam failure recovery or at least one of CORESET0 identifying a value of 0.

In a sixth aspect, an embodiment of the present invention further provides a network device, where the network device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the steps of the beam failure recovery method described above are implemented.

In a seventh aspect, an embodiment of the present invention provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the beam failure recovery method are implemented.

Therefore, when the terminal of the embodiment of the invention generates the beam failure, the beam failure recovery process is triggered, and the beam failure recovery method provided by the embodiment can avoid the problem of beam failure recovery failure caused by monitoring wrong resources, thereby improving the success rate of beam failure recovery.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor.

Fig. 1 is a schematic flow chart illustrating a method for recovering a terminal-side beam failure according to an embodiment of the present invention;

fig. 2 is a schematic block diagram of a terminal according to an embodiment of the present invention;

FIG. 3 shows a block diagram of a terminal of an embodiment of the invention;

fig. 4 is a flowchart illustrating a method for recovering a beam failure at a network device side according to an embodiment of the present invention;

FIG. 5 is a block diagram of a network device according to an embodiment of the present invention;

fig. 6 shows a block diagram of a network device of an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

The terms first, second and the like in the description and in the claims of the present application are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The beam failure recovery method of the embodiment of the invention is applied to a terminal side, and as shown in fig. 1, the method comprises the following steps:

step 11: in the event of a beam failure, a beam failure recovery request is sent to the network device.

In a high-band communication system, since the wavelength of a radio signal is short, it is easy to cause a situation where signal propagation is blocked or the like, and signal propagation is interrupted. If the traditional radio link reestablishment process is adopted, the time consumption is long, so a beam failure recovery mechanism is introduced, and the method comprises the following steps:

and (3) beam failure detection: the terminal measures a Beam Failure Detection Reference Signal (BFD RS) in a physical layer, and determines whether a Beam Failure event occurs according to a measurement result. The condition that the terminal judges that the beam failure event occurs includes: if it is detected that the metric (metric) of all serving Control beams (serving Control beams) meets a preset condition, for example, the Block Error rate (BLER) of a Physical Downlink Control Channel (PDCCH) exceeds a preset threshold, it is determined as a beam failure instance (beam failure instance), and the Physical layer of the terminal reports an indication to a higher layer, for example, a Media Access Control (MAC) layer, and the reporting process is periodic. Accordingly, if the terminal physical layer determines that no beam failure example has occurred, no indication is sent to higher layers. The high-level of the terminal uses a counter to count the instructions reported by the physical layer, and when the maximum number of network configurations is reached, the terminal determines that a beam failure event (beam failure event) occurs.

New candidate beam (candidate beam) identification: the terminal physical layer measures the candidate beam reference signal (candidate beam RS) and finds a new candidate beam. This step is not mandatory to be performed after the occurrence of the beam failure event, but may be performed before the occurrence of the beam failure event. When the terminal physical layer receives a request, an indication or a notification from the terminal high layer, reporting the measurement result meeting the preset conditions to the terminal high layer, for example: the measurement quality of candidate beam RS exceeds the preset threshold of Level 1-Reference Signal Received Power (L1-RSRP), the reported content can be { beam Reference Signal index (beam RS index), L1-RSRP }, and the terminal high layer selects the candidate beam based on the report of the physical layer. It should be noted that, the new candidate beam is referred to as a new candidate beam, which is a candidate beam with better beam quality detected by the terminal, and if the candidate beam is not the current serving beam or the beam with the beam failure, the candidate beam can be regarded as the new candidate beam. The step of identifying the new candidate beam may be performed before the beam failure detection step, or after the beam failure detection step, but before step 11.

After the beam failure detection step and the new candidate beam identification step, step 11 is performed, i.e. the transmission of the beam failure recovery request BERQ: the terminal higher layer determines the PRACH resource or sequence (resource/sequence) according to the selected candidate beam. And if the terminal judges that the triggering condition of the beam failure recovery request is met, the terminal sends the beam failure recovery request to the network equipment on the PRACH based on non-competition. Wherein, the terminal needs to send the beam failure recovery request according to the sending times and/or a timer (timer) configured by the network device. The non-contention PRACH resource and other PRACH resources (e.g., PRACH resource for initial access) may be frequency division multiplexing FDM or code division multiplexing CDM, in which the preambles of the PRACH with CDM have the same sequence design.

Step 12: and detecting response information fed back by the network equipment according to the beam failure recovery request on the target control resource set CORESET.

Specifically, another step of the beam failure recovery mechanism is:

the terminal monitors the response information (UE monitor gsb response for beam failure recovery request) of the network device based on the beam failure recovery request: after receiving the beam failure recovery request sent by the terminal, the Network device feeds back response information, where the response information may carry a Cell-Radio Network Temporary Identity (C-RNTI), and switches to a new candidate beam, restarts beam search, or other indication information. If the beam failure recovery is unsuccessful, the terminal physical layer sends an indication to the terminal upper layer, and the higher layer determines the subsequent radio link failure process. And when the terminal receives the response information, the beam failure recovery is considered to be successful. And when the terminal does not receive the response information, the terminal reselects the random access resource corresponding to the new candidate beam to send the beam failure recovery request. Wherein, the new candidate beam determined by the terminal may be the same as or different from the candidate beam selected last time. If the terminal receives the response information before the maximum sending times and/or the timeout of the timer configured by the network equipment, the beam failure recovery is considered to be successful; and if the terminal does not receive the response information after the maximum transmission times and/or the timeout of the timer are reached, the beam failure recovery is considered to be failed.

Since the system allows the network device to send the response information in a dedicated (truncated) PDCCH on the CORESET-BFR, it may also be allowed to send the response information on CORESET0 with an identification value of 0. In order to avoid monitoring the response information on the wrong resource, the target CORESET monitored by the terminal comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 having an identification value of 0.

The following embodiment will further describe the step of detecting the response information by the terminal through the target CORESET in combination with a specific application scenario.

Scene one,

After the network device receives the BERQ sent by the terminal, no Response information of Beam Failure Recovery is configured on the CORESET-BFR, that is, Beam Failure Recovery Random Access Response (BFR RAR) information, then corresponding BFR RAR information is configured on CORESET0, where the CORESET-BFR uses a Beam reported by the terminal, and the CORESET0 uses a Beam of a Synchronization Signal Block (Synchronization Signal and PBCH Block, SSB) corresponding to the CORESET. It is noted that the correspondence between CORESET0 and SSB is preconfigured.

In this scenario, the terminal may be instructed to listen only on the CORESET0 by means of signaling indication, where the step of signaling indication is independent of the beam failure recovery procedure. For example, in a certain period of time, the network device and the terminal have a predetermined agreement about which CORESET the network device uses to send the BFR RAR information, and in this period, the terminal only needs to monitor the response information at the agreed CORESET.

Or, the terminal and the network device do not agree in advance on which kind of core set the response message is sent, so as to avoid the problem that the detection of the response message fails due to listening to wrong resources, step 12 may include: and in a preset time window, sequentially detecting response information fed back by the network equipment according to the beam failure recovery request on a CORESET-BFR and a CORESET0 according to a preset switching period. That is to say, within a preset time window, the terminal detects BFR RAR information on the CORESET-BFR and CORESET0, and if the terminal monitors the BFR RAR information on the CORESET0, the terminal monitors subsequent information on the reported candidate beam after receiving the BFR RAR information. And if the terminal does not receive the BFR RAR information in the CORESET-BFR and the CORESET0 within a preset time window, judging that the beam failure recovery fails.

Scene two,

After receiving the BERQ sent by the terminal, the network device directly configures response information of beam failure recovery, namely BFR RAR information, on the CORESET-BFR.

In this scenario, the terminal may indicate, in a signaling indication manner, that the terminal only monitors in CORESET BFR, similar to the scenario, where the step of signaling indication is independent of the beam failure recovery procedure. For example, in a certain period of time, the network device and the terminal have a predetermined agreement about which CORESET the network device uses to send the BFR RAR information, and in this period, the terminal only needs to monitor the response information at the agreed CORESET.

Or the terminal and the network device do not agree on which kind of CORESET the response information is sent in advance, but the terminal monitors CORESET-BFR and CORESET0 in a preset time window, and if the terminal does not receive BFR RAR information in the preset time window of the CORESET-BFR and the CORESET0, the beam failure recovery failure is judged. And in a preset time window, if the terminal monitors BFR RAR information on CORESET-BFR, the terminal monitors subsequent information on the reported candidate wave beam after receiving the BFR RAR information.

Scene three,

The network device only supports sending the response information through the CORESET BFR, and then after the network device receives the BERQ sent by the terminal, the response information of the beam failure recovery, namely the BFR RAR information, can be configured on the CORESET-BFR.

In this scenario, the terminal only needs to detect CORESET BFR, and step 12 may include: and in a preset time window, detecting response information fed back by the network equipment according to the beam failure recovery request on the CORESET-BFR. That is, in this scenario, the terminal is not allowed to detect CORESET0, and the network device does not configure the BFR RAR information in CORESET 0. And if the terminal does not receive the BFR RAR information within a certain time window period on the CORESET BFR, judging that the beam failure recovery fails. And in a preset time window, if the terminal monitors BFR RAR information on CORESET-BFR, the terminal monitors subsequent information on the reported candidate wave beam after receiving the BFR RAR information.

After step 12, the method further comprises: if the response information is detected, determining that the beam failure recovery is successful; and if the response information is not detected, determining that the beam failure recovery fails. When the terminal receives the response information by detecting the target CORESET, the beam failure recovery is considered to be successful. And when the terminal does not receive the response information, the terminal reselects the random access resource corresponding to the new candidate beam to send the beam failure recovery request. Wherein, the new candidate beam determined by the terminal may be the same as or different from the candidate beam selected last time. If the terminal receives the response information before the maximum sending times and/or the timeout of the timer configured by the network equipment, the beam failure recovery is considered to be successful; and if the terminal does not receive the response information after the maximum transmission times and/or the timeout of the timer are reached, the beam failure recovery is considered to be failed.

Preferably, for the BFR procedure, when the SSB is used as a reference signal for a new candidate beam, all types of quasi co-located (QCL) information need to be provided to the terminal. Wherein the quasi co-location type is used to indicate that at least one of doppler frequency shift, doppler spread, average delay, delay spread, and spatial reception parameters is quasi co-located. When the quasi co-location type is type A, the Doppler frequency shift, the Doppler extension, the average time delay and the time delay extension are quasi co-location; when the quasi co-location type is type B, the Doppler frequency shift and the Doppler expansion are quasi co-location; when the quasi co-location type is type C, the Doppler frequency offset and the average time delay are quasi co-location; and when the quasi co-location type is type D, the space receiving parameter is quasi co-location. After the new candidate beam identification step, step 12 is preceded by: the transmission configuration indication TCI information of the new candidate beam is acquired. Wherein, the TCI information may indicate QCL information of different QCL types (e.g., type a, type B, type C, or type D).

The step of obtaining the TCI information of the transmission configuration indication of the new candidate beam includes the following steps:

in the first mode, when the synchronization signal block SSB is a reference signal of a new candidate beam, the TCI information of the new candidate beam is obtained through the SSB. That is, only when the SSB is used as a reference signal for a new candidate beam, the SSB signal may provide all QCL information except for type D in addition to QCL information for type D.

And secondly, receiving the TCI information of the new candidate beam through the CORESET-BFR. The TCI information is used for indicating a target quasi-co-location type, and the target quasi-co-location type is different from the quasi-co-location type indicated by the SSB. That is, in addition to the SSB information providing QCL information of type D, TCI information is allowed to be configured in the CORESET-BFR, and is restricted to providing only QCL information other than type D.

And thirdly, receiving the TCI information of the new candidate beam through other CORESETs before the beam fails. Wherein, the TCI information is used for indicating a target standard co-location type, and the target quasi co-location type is different from the quasi co-location type indicated by the SSB. That is, the CORESET-BFR does not configure TCI information except for QCL information of type D provided by SSB information, and the terminal determines TCI information corresponding to other CORESET before a beam failure as TCI information of a new candidate beam. For example, QCL information other than type D provided by Tracking Reference Signal (TRS) in the Bandwidth Part (BWP) of CORESET-BFR or other Reference signals.

In the beam failure recovery method of the embodiment of the invention, when the beam failure occurs, the terminal sends the beam failure recovery request to the network equipment to trigger the beam failure recovery process.

The foregoing embodiments describe the beam failure recovery method in different scenarios, and the following describes a terminal corresponding to the beam failure recovery method with reference to the accompanying drawings.

As shown in fig. 2, the terminal 200 according to the embodiment of the present invention can send a beam failure recovery request to the network device when a beam failure occurs in the foregoing embodiment; on the target control resource set CORESET, the details of a response information method fed back by the network equipment according to the beam failure recovery request are detected, and the same effect is achieved. Wherein, the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 with an identification value of 0, the terminal 200 specifically includes the following functional modules:

a first sending module 210, configured to send a beam failure recovery request to a network device in case of a beam failure;

the detection module 220 is configured to detect, on the target control resource set, a response message fed back by the network device according to the beam failure recovery request; wherein, the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 having an identification value of 0.

Wherein, the detecting module 220 includes:

and the first detection submodule is used for sequentially detecting response information fed back by the network equipment according to the beam failure recovery request on the CORESET-BFR and the CORESET0 in a preset time window according to a preset switching period.

Wherein, the detecting module 220 includes:

a second detection submodule for detecting when the target CORESET includes CORESET-BFR; and in a preset time window, detecting response information fed back by the network equipment according to the beam failure recovery request on the CORESET-BFR.

Wherein, the terminal 200 further includes:

and the determining module is used for determining that the beam failure recovery fails if the response information is not detected.

Wherein, the terminal 200 further includes:

a first obtaining module, configured to obtain the TCI information of the transmission configuration indication of the new candidate beam.

Wherein, first acquisition module includes:

the first obtaining sub-module is used for obtaining TCI information of the new candidate beam through the SSB when the synchronous signal block SSB is a reference signal of the new candidate beam;

alternatively, the first and second electrodes may be,

the second obtaining submodule is used for receiving TCI information of the new candidate beam through CORESET-BFR, wherein the TCI information is used for indicating a target standard co-location type, and the target quasi co-location type is different from the quasi co-location type indicated by SSB;

alternatively, the first and second electrodes may be,

and the third acquisition sub-module is used for receiving TCI information of the new candidate beam through other CORESETs before the beam fails, wherein the TCI information is used for indicating a target standard co-location type, and the target quasi-co-location type is different from the quasi-co-location type indicated by the SSB.

It is worth pointing out that, when a beam failure occurs, the terminal according to the embodiment of the present invention sends a beam failure recovery request to the network device, and triggers a beam failure recovery process.

To better achieve the above object, further, fig. 3 is a schematic diagram of a hardware structure of a terminal implementing various embodiments of the present invention, where the terminal 30 includes, but is not limited to: radio frequency unit 31, network module 32, audio output unit 33, input unit 34, sensor 35, display unit 36, user input unit 37, interface unit 38, memory 39, processor 310, and power supply 311. Those skilled in the art will appreciate that the terminal structure shown in fig. 3 is not intended to be limiting and that the terminal may include more or fewer components than shown, or some components may be combined, or a different arrangement of components. In the embodiment of the present invention, the terminal includes, but is not limited to, a mobile phone, a tablet computer, a notebook computer, a palm computer, a vehicle-mounted terminal, a wearable device, a pedometer, and the like.

The radio frequency unit 31 is configured to send a beam failure recovery request to the network device when a beam failure occurs;

the processor 310 is configured to detect, on the target control resource set CORESET, response information fed back by the network device according to the beam failure recovery request; wherein, the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 with an identification value of 0;

the terminal of the embodiment of the invention sends the beam failure recovery request to the network equipment when the beam failure occurs, and triggers the beam failure recovery process.

It should be understood that, in the embodiment of the present invention, the radio frequency unit 31 may be used for receiving and sending signals during a message sending and receiving process or a call process, and specifically, receives downlink data from a base station and then processes the received downlink data to the processor 310; in addition, the uplink data is transmitted to the base station. Typically, the radio frequency unit 31 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like. In addition, the radio frequency unit 31 can also communicate with a network and other devices through a wireless communication system.

The terminal provides wireless broadband internet access to the user via the network module 32, such as assisting the user in sending and receiving e-mails, browsing web pages, and accessing streaming media.

The audio output unit 33 may convert audio data received by the radio frequency unit 31 or the network module 32 or stored in the memory 39 into an audio signal and output as sound. Also, the audio output unit 33 may also provide audio output related to a specific function performed by the terminal 30 (e.g., a call signal reception sound, a message reception sound, etc.). The audio output unit 33 includes a speaker, a buzzer, a receiver, and the like.

The input unit 34 is for receiving an audio or video signal. The input Unit 34 may include a Graphics Processing Unit (GPU) 341 and a microphone 342, and the Graphics processor 341 processes image data of a still picture or video obtained by an image capturing device (such as a camera) in a video capturing mode or an image capturing mode. The processed image frames may be displayed on the display unit 36. The image frames processed by the graphic processor 341 may be stored in the memory 39 (or other storage medium) or transmitted via the radio frequency unit 31 or the network module 32. The microphone 342 may receive sound and may be capable of processing such sound into audio data. The processed audio data may be converted into a format output transmittable to a mobile communication base station via the radio frequency unit 31 in case of the phone call mode.

The terminal 30 also includes at least one sensor 35, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor that adjusts the brightness of the display panel 361 according to the brightness of ambient light, and a proximity sensor that turns off the display panel 361 and/or the backlight when the terminal 30 moves to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), detect the magnitude and direction of gravity when stationary, and can be used to identify the terminal posture (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration identification related functions (such as pedometer, tapping), and the like; the sensors 35 may also include a fingerprint sensor, a pressure sensor, an iris sensor, a molecular sensor, a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, etc., which are not described in detail herein.

The display unit 36 is used to display information input by the user or information provided to the user. The Display unit 36 may include a Display panel 361, and the Display panel 361 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like.

The user input unit 37 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the terminal. Specifically, the user input unit 37 includes a touch panel 371 and other input devices 372. Touch panel 371, also referred to as a touch screen, may collect touch operations by a user on or near touch panel 371 (e.g., operations by a user on or near touch panel 371 using a finger, a stylus, or any suitable object or attachment). The touch panel 371 may include two parts of a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 310, and receives and executes commands sent by the processor 310. In addition, the touch panel 371 may be implemented in various types, such as resistive, capacitive, infrared, and surface acoustic wave. The user input unit 37 may include other input devices 372 in addition to the touch panel 371. In particular, the other input devices 372 may include, but are not limited to, a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which are not described herein again.

Further, the touch panel 371 may be overlaid on the display panel 361, and when the touch panel 371 detects a touch operation thereon or nearby, the touch panel 371 is transmitted to the processor 310 to determine the type of the touch event, and then the processor 310 provides a corresponding visual output on the display panel 361 according to the type of the touch event. Although the touch panel 371 and the display panel 361 are shown in fig. 3 as two separate components to implement the input and output functions of the terminal, in some embodiments, the touch panel 371 and the display panel 361 may be integrated to implement the input and output functions of the terminal, and is not limited herein.

The interface unit 38 is an interface for connecting an external device to the terminal 30. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device having an identification module, an audio input/output (I/O) port, a video I/O port, an earphone port, and the like. The interface unit 38 may be used to receive input (e.g., data information, power, etc.) from an external device and transmit the received input to one or more elements within the terminal 30 or may be used to transmit data between the terminal 30 and an external device.

The memory 39 may be used to store software programs as well as various data. The memory 39 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required for at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, and the like. Further, the memory 39 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The processor 310 is a control center of the terminal, connects various parts of the entire terminal using various interfaces and lines, performs various functions of the terminal and processes data by operating or executing software programs and/or modules stored in the memory 39 and calling data stored in the memory 39, thereby performing overall monitoring of the terminal. Processor 310 may include one or more processing units; preferably, the processor 310 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 310.

The terminal 30 may further include a power supply 311 (such as a battery) for supplying power to various components, and preferably, the power supply 311 may be logically connected to the processor 310 through a power management system, so as to implement functions of managing charging, discharging, and power consumption through the power management system.

In addition, the terminal 30 includes some functional modules that are not shown, and are not described in detail herein.

Preferably, an embodiment of the present invention further provides a terminal, which includes a processor 310, a memory 39, and a computer program stored in the memory 39 and capable of running on the processor 310, where the computer program is executed by the processor 310 to implement each process of the foregoing beam failure recovery method embodiment, and can achieve the same technical effect, and in order to avoid repetition, details are not described here again. A terminal may be a wireless terminal or a wired terminal, and a wireless terminal may be a device providing voice and/or other service data connectivity to a user, a handheld device having a wireless connection function, or other processing devices connected to a wireless modem. A wireless terminal, which may be a mobile terminal such as a mobile telephone (or "cellular" telephone) and a computer having a mobile terminal, e.g., a portable, pocket, hand-held, computer-included, or vehicle-mounted mobile device, may communicate with one or more core networks via a Radio Access Network (RAN), and may exchange language and/or data with the RAN. For example, devices such as Personal Communication Service (PCS) phones, cordless phones, Session Initiation Protocol (SIP) phones, Wireless Local Loop (WLL) stations, and Personal Digital Assistants (PDAs) are used. A wireless Terminal may also be referred to as a system, a Subscriber Unit (Subscriber Unit), a Subscriber Station (Subscriber Station), a Mobile Station (Mobile), a Remote Station (Remote Station), a Remote Terminal (Remote Terminal), an Access Terminal (Access Terminal), a User Terminal (User Terminal), a User Agent (User Agent), and a User Device or User Equipment (User Equipment), which are not limited herein.

An embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the computer program implements each process of the foregoing beam failure recovery method embodiment, and can achieve the same technical effect, and in order to avoid repetition, details are not repeated here. The computer-readable storage medium may be a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk.

The foregoing embodiment describes the beam failure recovery method of the present invention from the terminal side, and the following embodiment further describes the beam failure recovery method of the network device side with reference to the drawings.

As shown in fig. 4, the method for recovering beam failure according to the embodiment of the present invention is applied to a network device side, and may include the following steps:

step 41: a beam failure recovery request is received from the terminal side.

In a high-band communication system, signal propagation interruption is liable to occur. If the traditional radio link reestablishment process is adopted, the time consumption is long, so a beam failure recovery mechanism is introduced, and the method comprises the following steps: the method comprises the steps of beam failure detection, new candidate beam identification, transmission of a beam failure recovery request BERQ, response information of the terminal monitoring network equipment based on the beam failure recovery request and the like. Wherein, the terminal sends the BERQ after detecting the beam failure.

Step 42: and after receiving the beam failure recovery request, feeding back response information on the target control resource set CORESET.

The network device allows the response information to be sent in a dedicated (truncated) PDCCH on the CORESET-BFR, and possibly also on CORESET0 with an identification value of 0. The target CORESET for the network device to send the response message includes: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 having an identification value of 0. It should be noted that the network device may negotiate the target CORESET for feeding back the response information in advance with the terminal, or may autonomously select the target CORESET according to network performance and the like. Accordingly, the terminal may perform the monitoring by using, but not limited to, the monitoring manner described in the above terminal-side embodiment.

Preferably, for the BFR procedure, when the SSB is used as a reference signal for a new candidate beam, all types of quasi co-located (QCL) information need to be provided to the terminal. Accordingly, step 42 may be preceded by: acquiring a new candidate beam from a terminal side; and transmitting the Transmission Configuration Indication (TCI) information of the new candidate beam to the terminal. Wherein the quasi co-location type is used to indicate that at least one of doppler frequency shift, doppler spread, average delay, delay spread, and spatial reception parameters is quasi co-located.

Wherein the step of sending the transmission configuration indication TCI information of the new candidate beam to the terminal may include:

when the synchronous signal block SSB is a reference signal of a new candidate beam, TCI information of the new candidate beam is sent to the terminal through the SSB; corresponding to the first embodiment of the terminal side, the description is omitted here.

Or, transmitting TCI information of the new candidate beam to the terminal through CORESET-BFR, wherein the TCI information is used for indicating a target quasi-co-location type, and the target quasi-co-location type is different from the quasi-co-location type indicated by SSB; corresponding to the second embodiment of the terminal side, the description is omitted here.

Or, transmitting TCI information of the new candidate beam to the terminal through other CORESET before the beam failure, wherein the TCI information is used for indicating a target standard co-location type, and the target quasi-co-location type is different from the quasi-co-location type indicated by the SSB; corresponding to the third embodiment of the terminal side, the description is omitted here.

The foregoing embodiments respectively describe in detail the beam failure recovery methods in different scenarios, and the following embodiments further describe the network devices corresponding to the foregoing embodiments with reference to the accompanying drawings.

As shown in fig. 5, the network device 500 according to the embodiment of the present invention can implement receiving a beam failure recovery request from the terminal side in the foregoing embodiment; after receiving the beam failure recovery request, feeding back the details of the method for responding information on the target control resource set CORESET, and achieving the same effect. Wherein, the target CORESET comprises: a control resource set CORESET-BFR for beam failure recovery or at least one of CORESET0 identifying a value of 0. The network device 500 specifically includes the following functional modules:

a receiving module 510, configured to receive a beam failure recovery request from a terminal side;

a feedback module 520, configured to feed back response information on the target control resource set CORESET after receiving the beam failure recovery request; wherein, the target CORESET comprises: a control resource set CORESET-BFR for beam failure recovery or at least one of CORESET0 identifying a value of 0.

Wherein, the network device 500 further includes:

a second obtaining module, configured to obtain a new candidate beam from a terminal side;

and a second sending module, configured to send the TCI information indicating the transmission configuration of the new candidate beam to the terminal.

Wherein, the second sending module includes:

the first sending submodule is used for sending TCI information of the new candidate beam to the terminal through the SSB when the synchronous signal block SSB is a reference signal of the new candidate beam;

alternatively, the first and second electrodes may be,

the second sending submodule is used for sending TCI information of the new candidate beam to the terminal through CORESET-BFR, wherein the TCI information is used for indicating a target standard co-location type, and the target standard co-location type is different from the standard co-location type indicated by SSB;

alternatively, the first and second electrodes may be,

and the third sending submodule is used for sending TCI information of the new candidate beam to the terminal through other CORESETs before the beam fails, wherein the TCI information is used for indicating a target standard co-location type, and the target quasi-co-location type is different from the quasi-co-location type indicated by the SSB.

It should be noted that the division of the modules of the network device and the terminal is only a logical division, and the actual implementation may be wholly or partially integrated into one physical entity, or may be physically separated. And these modules can be realized in the form of software called by processing element; or may be implemented entirely in hardware; and part of the modules can be realized in the form of calling software by the processing element, and part of the modules can be realized in the form of hardware. For example, the determining module may be a processing element separately set up, or may be implemented by being integrated in a chip of the apparatus, or may be stored in a memory of the apparatus in the form of program code, and the function of the determining module is called and executed by a processing element of the apparatus. Other modules are implemented similarly. In addition, all or part of the modules can be integrated together or can be independently realized. The processing element described herein may be an integrated circuit having signal processing capabilities. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in the form of software.

For example, the above modules may be one or more integrated circuits configured to implement the above methods, such as: one or more Application Specific Integrated Circuits (ASICs), or one or more microprocessors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs), among others. For another example, when one of the above modules is implemented in the form of a Processing element scheduler code, the Processing element may be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. For another example, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

It is worth pointing out that, after the terminal sends the beam failure recovery request in a beam failure, the network device according to the embodiment of the present invention can avoid the problem of beam failure recovery failure caused by monitoring wrong resources through the beam failure recovery method provided by the above-mentioned embodiment, thereby also improving the success rate of beam failure recovery.

To better achieve the above object, an embodiment of the present invention further provides a network device, which includes a processor, a memory, and a computer program stored in the memory and executable on the processor, and the processor implements the steps in the beam failure recovery method as described above when executing the computer program. Embodiments of the present invention also provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the beam failure recovery method as described above.

Specifically, the embodiment of the invention also provides a network device. As shown in fig. 6, the network device 600 includes: antenna 61, radio frequency device 62, baseband device 63. The antenna 61 is connected to a radio frequency device 62. In the uplink direction, the rf device 62 receives information via the antenna 61 and sends the received information to the baseband device 63 for processing. In the downlink direction, the baseband device 63 processes information to be transmitted and transmits the information to the radio frequency device 62, and the radio frequency device 62 processes the received information and transmits the processed information through the antenna 61.

The above-mentioned band processing means may be located in the baseband means 63, and the method performed by the network device in the above embodiment may be implemented in the baseband means 63, where the baseband means 63 includes a processor 64 and a memory 65.

The baseband device 63 may include at least one baseband board, for example, and a plurality of chips are disposed on the baseband board, as shown in fig. 6, wherein one chip, for example, the processor 64, is connected to the memory 65 to call up the program in the memory 65 to perform the network device operation shown in the above method embodiment.

The baseband device 63 may further include a network interface 66 for exchanging information with the radio frequency device 62, such as a Common Public Radio Interface (CPRI).

The processor may be a single processor or a combination of multiple processing elements, for example, the processor may be a CPU, an ASIC, or one or more integrated circuits configured to implement the methods performed by the network devices, for example: one or more microprocessors DSP, or one or more field programmable gate arrays FPGA, or the like. The storage element may be a memory or a combination of a plurality of storage elements.

The memory 65 may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. The volatile Memory may be a Random Access Memory (RAM) which serves as an external cache. By way of example and not limitation, many forms of RAM are available, such as Static random access memory (Static RAM, SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (ddr Data Rate SDRAM), Enhanced SDRAM (ESDRAM), synchlronous DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 65 described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

Specifically, the network device of the embodiment of the present invention further includes: a computer program stored in the memory 65 and executable on the processor 64, the processor 64 calling the computer program in the memory 65 to execute the method performed by each module shown in fig. 5.

In particular, the computer program when invoked by the processor 64 is operable to perform: receiving a beam failure recovery request from a terminal side; after receiving the beam failure recovery request, feeding back response information on a target control resource set (CORESET);

wherein, the target CORESET comprises: a control resource set CORESET-BFR for beam failure recovery or at least one of CORESET0 identifying a value of 0.

In particular, the computer program when invoked by the processor 64 is operable to perform: acquiring a new candidate beam from a terminal side; transmitting Transmission Configuration Indication (TCI) information of the new candidate beam to the terminal.

In particular, the computer program when invoked by the processor 64 is operable to perform: when the synchronous signal block SSB is a reference signal of a new candidate beam, TCI information of the new candidate beam is sent to the terminal through the SSB;

alternatively, the first and second electrodes may be,

the TCI information of the new candidate beam is sent to the terminal through CORESET-BFR, wherein the TCI information is used for indicating a target standard co-location type, and the target standard co-location type is different from the standard co-location type indicated by SSB;

alternatively, the first and second electrodes may be,

and transmitting TCI information of the new candidate beam to the terminal through other CORESET before the beam fails, wherein the TCI information is used for indicating a target standard co-location type, and the target quasi co-location type is different from the quasi co-location type indicated by the SSB.

The network device may be a Base Transceiver Station (BTS) in Global System for Mobile communications (GSM) or Code Division Multiple Access (CDMA), a Base Station (NodeB, NB) in Wideband Code Division Multiple Access (WCDMA), an evolved Node B (eNB, eNodeB) in LTE, a relay Station, an Access point, a Base Station in a future 5G network, or the like, which is not limited herein.

After the terminal sends the beam failure recovery request in the beam failure, the network equipment in the embodiment of the invention can avoid the problem of beam failure recovery failure caused by monitoring wrong resources through the beam failure recovery method provided by the embodiment, thereby improving the success rate of beam failure recovery.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: various media capable of storing program codes, such as a U disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

Furthermore, it is to be noted that in the device and method of the invention, it is obvious that the individual components or steps can be decomposed and/or recombined. These decompositions and/or recombinations are to be regarded as equivalents of the present invention. Also, the steps of performing the series of processes described above may naturally be performed chronologically in the order described, but need not necessarily be performed chronologically, and some steps may be performed in parallel or independently of each other. It will be understood by those skilled in the art that all or any of the steps or elements of the method and apparatus of the present invention may be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or any combination thereof, which can be implemented by those skilled in the art using their basic programming skills after reading the description of the present invention.

Thus, the objects of the invention may also be achieved by running a program or a set of programs on any computing device. The computing device may be a general purpose device as is well known. The object of the invention is thus also achieved solely by providing a program product comprising program code for implementing the method or the apparatus. That is, such a program product also constitutes the present invention, and a storage medium storing such a program product also constitutes the present invention. It is to be understood that the storage medium may be any known storage medium or any storage medium developed in the future. It is further noted that in the apparatus and method of the present invention, it is apparent that each component or step can be decomposed and/or recombined. These decompositions and/or recombinations are to be regarded as equivalents of the present invention. Also, the steps of executing the series of processes described above may naturally be executed chronologically in the order described, but need not necessarily be executed chronologically. Some steps may be performed in parallel or independently of each other.

While the preferred embodiments of the present invention have been described, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention as defined in the following claims.

Claims

1. A method for recovering beam failure is applied to a terminal side, and is characterized by comprising the following steps:

detecting response information fed back by the network equipment according to the beam failure recovery request on a target control resource set (CORESET); wherein the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 with an identification value of 0;

on a target control resource set CORESET, detecting response information fed back by network equipment according to the beam failure recovery request, wherein the step comprises the following steps:

in a preset time window, sequentially detecting response information fed back by the network equipment according to the beam failure recovery request on a CORESET-BFR and a CORESET0 according to a preset switching period;

before the step of detecting, on the target control resource set CORESET, response information fed back by the network device according to the beam failure recovery request, the method further includes:

acquiring Transmission Configuration Indication (TCI) information of a new candidate beam;

the step of obtaining the TCI information of the transmission configuration indication of the new candidate beam includes:

when a synchronous signal block SSB is a reference signal of a new candidate beam, acquiring TCI information of the new candidate beam through the SSB;

alternatively, the first and second electrodes may be,

receiving TCI information of the new candidate beam through the CORESET-BFR, wherein the TCI information is used for indicating a target quasi co-location type, and the target standard co-location type is different from the quasi co-location type indicated by the SSB;

alternatively, the first and second electrodes may be,

receiving TCI information of the new candidate beam through other CORESETs before the beam fails, wherein the TCI information is used for indicating a target quasi-co-location type, and the target standard co-location type is different from the quasi-co-location type indicated by the SSB.

2. The beam failure recovery method of claim 1 wherein when the target CORESET comprises a CORESET-BFR; on a target control resource set CORESET, detecting response information fed back by network equipment according to the beam failure recovery request, wherein the step comprises the following steps:

and detecting response information fed back by the network equipment according to the beam failure recovery request on the CORESET-BFR within a preset time window.

3. The beam failure recovery method according to any one of claims 1 to 2, wherein after the step of detecting, on a target control resource set, CORESET, response information fed back by a network device according to the beam failure recovery request, the method further includes:

and if the response information is not detected, determining that the beam failure recovery fails.

4. A terminal, comprising:

a first sending module, configured to send a beam failure recovery request to a network device when a beam failure occurs;

the detection module is used for detecting response information fed back by the network equipment according to the beam failure recovery request on a target control resource set CORESET; wherein the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery and a CORESET0 with an identification value of 0;

the detection module comprises:

the first detection submodule is used for sequentially detecting response information fed back by the network equipment according to the beam failure recovery request on a CORESET-BFR and a CORESET0 in a preset time window according to a preset switching period;

a first obtaining module, configured to obtain TCI information of a transmission configuration indication of a new candidate beam;

wherein, first acquisition module includes:

alternatively, the first and second electrodes may be,

5. A terminal, characterized in that the terminal comprises a processor, a memory and a computer program stored on the memory and executable on the processor, which computer program, when executed by the processor, performs the steps of the beam failure recovery method according to any of claims 1 to 3.

6. A method for recovering beam failure is applied to a network device side, and is characterized by comprising the following steps:

receiving a beam failure recovery request from a terminal side;

after receiving the beam failure recovery request, feeding back response information on a target control resource set (CORESET); wherein the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery or CORESET0 with an identification value of 0;

the terminal side detects response information fed back by the network equipment on a target control resource set CORESET in turn on a CORESET-BFR and a CORESET0 in a preset time window according to a preset switching period;

before the step of feeding back the response information on the target control resource set CORESET, the method further includes:

acquiring a new candidate beam from a terminal side;

transmitting Transmission Configuration Indication (TCI) information of the new candidate beam to the terminal;

a step of transmitting transmission configuration indication TCI information of the new candidate beam to the terminal, including:

when a Synchronization Signal Block (SSB) is a reference signal of a new candidate beam, transmitting TCI information of the new candidate beam to the terminal through the SSB;

alternatively, the first and second electrodes may be,

transmitting TCI information of the new candidate beam to the terminal through the CORESET-BFR, wherein the TCI information is used for indicating a target quasi co-location type, and the target standard co-location type is different from the quasi co-location type indicated by the SSB;

alternatively, the first and second electrodes may be,

and transmitting TCI information of the new candidate beam to the terminal through other CORESETs before the beam fails, wherein the TCI information is used for indicating a target quasi-co-location type, and the target quasi-co-location type is different from the quasi-co-location type indicated by the SSB.

7. A network device, comprising:

the feedback module is used for feeding back response information on a target control resource set (CORESET) after receiving the beam failure recovery request; wherein the target CORESET comprises: at least one of a control resource set CORESET-BFR for beam failure recovery or CORESET0 with an identification value of 0;

a second sending module, configured to send the TCI information of the transmission configuration indication of the new candidate beam to the terminal;

wherein, the second sending module includes:

alternatively, the first and second electrodes may be,

8. A network device comprising a processor, a memory, and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the beam failure recovery method of claim 6 when executing the computer program.

9. A computer-readable storage medium, having stored thereon a computer program which, when being executed by a processor, carries out the steps of the beam failure recovery method according to any one of claims 1 to 3, 6.