WO2019039989A1

WO2019039989A1 - Prach preamble pooling for beam recovery

Info

Publication number: WO2019039989A1
Application number: PCT/SE2018/050837
Authority: WO
Inventors: Claes Tidestav; Icaro L. J. Da Silva
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-08-21
Filing date: 2018-08-20
Publication date: 2019-02-28

Abstract

According to some embodiments, a method for use in a wireless device of a wireless communication network comprises: detecting failure of a beam formed wireless signal; one physical random access channel (PRACH) resource from a pool of PRACH resources reserved for beam recovery; and transmitting a beam recovery message to a network node using the selected at least one PRACH resource. A PRACH resource comprises at least one of a time resource, a frequency resource, and a PRACH preamble. In particular embodiments, the PRACH resources in the pool of PRACH resources include different PRACH resources than the PRACH resources used by the wireless device for random access.

Description

PRACH PREAMBLE POOLING FOR BEAM RECOVERY

TECHNICAL FIELD

Particular embodiments are directed to wireless communications and, more particularly, to physical random access channel (PRACH) preamble pooling for beam recovery.

INTRODUCTION

Third Generation Partnership Project (3GPP) defines a fifth generation (5G) of wireless communication that includes new radio (NR). To improve coverage and increase data rate, NR makes wide use of beamforming. With beamforming, a network can transmit user specific data via a narrow beam, which can improve the signal-to-interference-plus-noise ratio (SINR). One issue with beam-based transmission is that beams provide narrow coverage, which means a user equipment (UE) may suddenly find itself out of the coverage area of the beam. When that occurs, the network is not able to efficiently schedule data to the UE. Furthermore, the UE is not monitoring the right beam (or beam link pair) used by the network to transmit a control channel (e.g., physical downlink control channel (PDCCH)), and the UE is not able to detect scheduled information. The problem is generally referred to as beam failure.

5G NR includes a procedure referred to as beam recovery. Beam recovery may be used upon detection of a beam failure for RRC CONNECTED UEs. In beam recovery, an RRC CONNECTED UE performs measurements associated to the quality of the serving link and, if the measured quality goes below a given threshold, the UE performs beam recovery. Beam recovery may be used when the transmit and/or receive beams of the gNodeB and the UE have become misaligned, but where additional beams exist that could be used to maintain the connection between the gNodeB and the UE.

The beam failure recovery procedure includes beam failure detection, new candidate beam identification, a beam failure recovery request, and a beam failure recovery response. Each aspect is described in more detail below.

For beam failure detection, a UE monitors a certain periodic reference signal (RS) to estimate the quality of the serving link. When the quality of the serving link falls below a certain threshold, the UE initiates beam recovery. The beam failure detection RS may include a periodic channel state information-reference signal (CSI-RS) for beam management. A synchronization signal block (SS-block or SSB) within the serving cell may also be used for beam failure detection if the SS-block is used for beam management. Other trigger conditions may also be used for declaring beam failure.

For new candidate beam identification, after the UE has detected beam failure, the UE tries to identify a new beam that will provide adequate quality. The UE searches for a specific RS, which is transmitted from the same network node, but in different candidate beams. During this search procedure, the UE may also change its receive beam. Beam identification RS may include periodic CSI-RS for beam management, if it is configured by the network, and periodic CSI-RS and SS-blocks within the serving cell if SS-block is used for beam management.

For the beam failure recovery request, after the UE finds a new candidate beam, the UE transmits an uplink signal using certain uplink resources. The gNodeB is prepared to receive the uplink signal in these uplink resources and can determine which candidate beam the UE selected based on the received uplink signal. Information carried by a beam failure recovery request may include explicit/implicit information about identifying the UE and new gNB transmit beam information, and/or explicit/implicit information about identifying the UE and whether or not a new candidate beam exists. The request may also include information about the UE beam failure, and/or information about the new beam quality.

Down-selection between the following options for a beam failure recovery request transmission may include physical random access channel (PRACH), physical uplink control channel (PUCCH), and PRACH-like (e.g., different parameter for preamble sequence from PRACH). A beam failure recovery request resource/signal may also be used for a scheduling request.

For a beam failure recovery response, after the gNodeB receives the beam failure recovery request, the gNodeB sends a downlink response to the UE using the knowledge of the new beam to indicate to the UE that the gNodeB received the request. The UE monitors for the gNB response to the beam failure recovery request. After the UE successfully receives the response, the beam recovery is complete.

The UE monitors a control channel search space to receive the gNodeB response. The control channel search space may be the same or different from the current control channel search space associated with serving beam pair links (BPLs). The UE may take further action if the gNB does not receive the beam failure recovery request transmission. 3GPP may also define support for the following features regarding beam failure and beam recovery. NR may support a UE trigger mechanism to recover from beam failure. The network may explicitly configure a UE with resources for uplink transmission of signals for beam recovery. The resources may include configurations where the base station (e.g., gNodeB) listens from all directions or partial directions (e.g., random access region).

NR may include transmission of a downlink signal that a UE monitors for identifying new potential beams. The transmission may include a beam swept control channel. The transmission mechanism may account for a tradeoff between performance and downlink signaling overhead.

A beam failure event occurs when the quality of a beam pair link or links of an associated control channel degrades below a certain point (e.g., comparison with a threshold, time-out of an associated timer, etc.). A mechanism to recover from beam failure is triggered when beam failure occurs. The beam pair link is used for convenience and may or may not be used in specification. The quality may include quality of beam pair link(s) associated with NR physical downlink shared channel (PDSCH). When multiple Y beam pair links are configured, and X (<=Y) out of Y beam pair links fall below the beam failure threshold, the UE may declare beam failure.

The search space may include either UE-specific or common search space of the associated NR-PDCCH. 3GPP may define signaling mechanisms for NR-PDCCH for the case where a UE is configured to monitor multiple beam pair links for NR-PDCCH. Other conditions for triggering beam recovery may also be defined.

The signals that a UE may use to detect beam failure and to identify new potential beams may include, for example, RS for beam management, RS for fine timing/frequency tracking, SS blocks, demodulation reference signal (DMRS) of PDCCH (including group common PDCCH and/or UE specific PDCCH), and/or DMRS for PDSCH. If a beam failure event occurs and no other potential beams exist to the serving cell, the UE may provide an indication to L3. For example, if necessary the UE may declare radio link failure (RLF) based on a predetermined criterion.

NR supports configuring resources for sending request for recovery purposes in symbols containing RACH, a scheduling request, and/or in other indicated symbols. The following channels may support beam failure recovery request transmission.

A beam failure recovery request may use a non-contention based channel based on PRACH, which uses a resource orthogonal to resources of other PRACH transmissions, at least for the frequency division multiplexing (FDM) case. Other methods may also achieve orthogonality (e.g., CDM/TDM with other PRACH resources). The PRACH transmission used for a beam failure recovery request may have a different sequence and/or format than those of PRACH used for other purposes. Retransmission behavior on the PRACH resource may be similar to regular RACH procedure.

A beam failure recovery request may use PUCCH for transmission. PUCCH may or may not be used with beam sweeping, which may or may not impact PUCCH design.

A beam failure recovery request may use contention-based PRACH resources as supplement to contention-free beam failure recovery resources. The resources may come from a traditional RACH resource pool. A 4-step RACH procedure may be used. Contention-based PRACH resources may be used, for example, if a new candidate beam does not have resources for contention-free PRACH-like transmission. A UE may be semi- statically configured to use one or both. If both, the UE may be configured whether to support dynamic selection of one of the channel(s) by the UE.

To receive the gNB response to the beam failure recovery request, the UE monitors

NR PDCCH with the assumption that the corresponding PDCCH DM-RS is spatial quasi co- located with the RS of the UE-identified candidate beam(s). The candidate beam(s) may or may not be identified from a preconfigured set. Detection of a gNB's response to the beam failure recovery request may be limited to a particular time window. The time window, a number of monitoring occasions within the time window, and a size and location of the time windows may be configured or pre-determined.

If the UE does not detect a response within the window, the UE may perform retransmit of the request. If the UE does not detect a response after a certain number of transmission(s), the UE notifies higher layer entities. The number of transmission(s) and/or timer may be configured or pre-determined. The certain number of beam failure recovery request transmissions may be network configurable by using parameters such as, number of transmissions, timer, or a combination of both.

The beam failure recovery procedure may be influenced by the RLF event. In case of unsuccessful recovery from beam failure, the UE may send an indication to higher layers, and may refrain from further beam failure recovery. An RLF may have a relationship with an unsuccessful beam failure recovery indication (e.g., whether beam failure recovery procedure influences or is influenced by the RLF event). When the beam recovery request transmission is based on RACH, the following procedure may be contention-free or contention-based. Contention-free means that the PRACH preamble uniquely identifies the UE. Thus, there is no contention, and contention resolution is unnecessary. Contention-based means that the PRACH preambles are selected from the traditional RACH resource pool. Contention resolution is required when receiving the PRACH preamble, because the network does not know which UE transmitted it, nor does the network know that it is a beam recovery request.

A problem with existing solutions is that when a contention-free beam recovery request is used, it may be necessary to allocate a large number of dedicated PRACH resources because every UE in connected mode will need a dedicated PRACH resource (e.g., time slot, frequency resource, preamble sequence, or a combination of any of these). Contention-free schemes are used in current systems during handovers where the target node can allocate these resources to the UE in a handover command to be used during handover execution. When the target allocates dedicated resources, the target is certain when the dedicated resources are going to be used, and such a blocking does not last long— the time the UE receives the command until the time it accesses (i.e., a few milliseconds). Applying the same technique for beam recovery, however, may be inefficient because the network is uncertain whether the UE will ever require the resources that would be blocked for an uncertain time period (i.e., a waste of uplink capacity that may only be used in a rare failure case).

On the other hand, with contention-based beam recovery relying on the same random access mechanism (i.e., at least beam recovery indication based on a PRACH preamble, uplink transmissions on the same RACH channel used for handover, state transition, initial access, etc., and network detection based on RACH receiver), the network is not able to distinguish beam recovery request transmissions from initial access requests, which causes a contention resolution step that is unnecessary in most cases. A distinction between beam recovery request transmissions and initial access requests is necessary because for beam recovery the UE is already in RRC CON ECTED (i.e., the network shall identify the UE as soon as possible to find the UE context and either apply the UE configurations or re- configure the UE). Such an identification may also allow the network to perform different follow up steps in random access compared to beam recovery. SUMMARY

The embodiments described herein include a pool of physical random access channel (PRACH) resources (such as time slots, frequency resources, PRACH preambles or any combination of these) reserved for beam recovery. Because the network can identify that a certain received PRACH transmission is a beam recovery request instead of a random access request from an incoming user equipment (UE) from handover or transitions from IDLE or INACTIVE, the network can adapt its actions to that.

One example is that during random access the UE should obtain a cell radio network temporary identifier (C-RNTI) (or any other UE identifier while in RRC C ONNECTED), while in the case of beam recovery the UE already has such an identifier. Any contention only needs to be resolved within the small group of UEs.

According to some embodiments, a method for use in a wireless device of a wireless communication network comprises: detecting failure of a beamformed wireless signal; selecting at least one PRACH resource from a pool of PRACH resources reserved for beam recovery; and transmitting a beam recovery message to a network node using the selected at least one PRACH resource. A PRACH resource comprises at least one of a time resource, a frequency resource, and a PRACH preamble.

In particular embodiments, selecting the at least one PRACH resource comprises selecting the at least one PRACH resource randomly from the pool of PRACH resources reserved for beam recovery. In some embodiments, selecting the at least one PRACH resource comprises selecting the at least one PRACH resource from the pool of PRACH resources reserved for beam recovery based on an identity of the wireless device. The identity of the wireless device may comprise a radio network temporary identifier. The identity of the wireless device may comprise one identifier among a range of identifiers and selecting the at least one PRACH resource may be based on the range of identifiers.

In particular embodiments, the beam recovery message comprises a random access message. The PRACH resources in the pool of PRACH resources may include a PRACH resource different from PRACH resources used by the wireless device for random access.

In particular embodiments, the method further comprises receiving a configuration of PRACH resources reserved for beam recovery. The method may further comprise receiving a beam recovery response message from the network node. The recovery response message may comprise a random access response message.

According to some embodiments, a wireless device comprises processing circuitry operable to: detect failure of a beamformed wireless signal; select at least one PRACH resource from a pool of PRACH resources reserved for beam recovery; and transmit a beam recovery message to a network node using the selected at least one PRACH resource.

In particular embodiments, the processing circuitry is operable to select the at least one PRACH resource by selecting the at least one PRACH resource randomly from the pool of PRACH resources reserved for beam recovery. In some embodiments, the processing circuitry is operable to select the at least one PRACH resource by selecting the at least one PRACH resource from the pool of PRACH resources reserved for beam recovery based on an identity of the wireless device. The identity of the wireless device may comprise a radio network temporary identifier. The identity of the wireless device may comprise one identifier among a range of identifiers and selecting the at least one PRACH resource is based on the range of identifiers.

In particular embodiments, the beam recovery message comprises a random access message. The PRACH resources in the pool of PRACH resources include a PRACH resource different from PRACH resources used by the wireless device for random access.

In particular embodiments, the processing circuitry is further operable to receive a configuration of PRACH resources reserved for beam recovery. The processing circuitry may be further operable to receive a beam recovery response message from the network node. The recovery response message may comprise a random access response message.

According to some embodiments, a method for use in a network node of a wireless communication network comprises: receiving a beam recovery message from a wireless device; determining that the beam recovery message is received in a PRACH resource reserved for beam recovery; and sending a beam recovery response to one or more wireless devices configured to use the PRACH resources reserved for beam recovery.

In particular embodiments, the beam recovery message comprises a random access message and the beam recovery response message comprises a random access response message.

In particular embodiments, the method further comprises sending a configuration of PRACH resources reserved for beam recovery to the wireless device. The method may comprise sending the wireless device an indication to randomly select PRACH resources from a pool of PRACH resources reserved for beam recovery, or an indication to select PRACH resources from a pool of PRACH resources reserved for beam recovery based on an identity of the wireless device. The identity of the wireless device may comprise a radio network temporary identifier.

In particular embodiments, the PRACH resource used for beam recovery includes a PRACH resource different from PRACH resources used by the wireless device for random access.

In particular embodiments, sending the beam recovery response to one or more wireless devices comprises sending the beam recovery response to all wireless devices configured to use the PRACH resources reserved for beam recovery. In some embodiments, sending the beam recovery response to one or more wireless devices comprises sending the beam recovery response to one wireless devices configured to use the PRACH resources reserved for beam recovery.

According to some embodiments, a network node comprises processing circuitry operable to: receive a beam recovery message from a wireless device; determine that the beam recovery message is received in a PRACH resource reserved for beam recovery; and send a beam recovery response to one or more wireless devices configured to use the PRACH resources reserved for beam recovery.

In particular embodiments, the processing circuitry is further operable to send a configuration of PRACH resources reserved for beam recovery to the wireless device. The processing circuitry may be further operable to send the wireless device an indication to randomly select PRACH resources from a pool of PRACH resources reserved for beam recovery, or to select PRACH resources from a pool of PRACH resources reserved for beam recovery based on an identity of the wireless device. The identity of the wireless device may comprise a radio network temporary identifier.

In particular embodiments, the processing circuitry is operable to send the beam recovery response to one or more wireless devices by sending the beam recovery response to all wireless devices configured to use the PRACH resources reserved for beam recovery. In some embodiments, the processing circuitry is operable to send the beam recovery response to one or more wireless devices by sending the beam recovery response to one wireless devices configured to use the PRACH resources reserved for beam recovery.

According to some embodiments, a wireless device comprises a detecting module, a selecting module, and a transmitting module. The detecting module is operable to detect failure of a beamformed wireless signal. The selecting module is operable to select at least one PRACH resource from a pool of PRACH resources reserved for beam recovery. The transmitting module is operable to transmit a beam recovery message to a network node using the selected at least one PRACH resource.

According to some embodiments, a network node comprises a receiving module, a determining module, and a transmitting module. The receiving module is operable to receive a beam recovery message from a wireless device. The determining module is operable to determine that the beam recovery message is received in a PRACH resource reserved for beam recovery. The transmitting module is operable to send a beam recovery response to one or more wireless devices configured to use the PRACH resources reserved for beam recovery.

Also disclosed is a computer program product. The computer program product comprises instructions stored on non-transient computer-readable media which, when executed by a processor, perform the steps of: detecting failure of a beamformed wireless signal; selecting at least one PRACH resource from a pool of PRACH resources reserved for beam recovery; and transmitting a beam recovery message to a network node using the selected at least one PRACH resource.

Another computer program product comprises instructions stored on non-transient computer-readable media which, when executed by a processor, perform the steps of: receiving a beam recovery message from a wireless device; determining that the beam recovery message is received in a PRACH resource reserved for beam recovery; and sending a beam recovery response to one or more wireless devices configured to use the PRACH resources reserved for beam recovery.

Particular embodiments may include some, all, or none of the following advantages. For example, allocating a pool of PRACH resources reduces the overhead compared to the contention-free case. Also, particular embodiments avoid full contention resolution associated with contention-based beam recovery. In addition, the network can adapt its actions for beam recovery differently than for a random access request. Some embodiments may include additional or other advantages. BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIGURE 1 is a block diagram illustrating an example wireless network, according to a particular embodiment;

FIGURE 2 is a flow diagram illustrating an example method in a wireless device, according to particular embodiments;

FIGURE 3 is a flow diagram illustrating an example method in a network node, according to particular embodiments;

FIGURE 4A is a block diagram illustrating an example embodiment of a wireless device;

FIGURE 4B is a block diagram illustrating example components of a wireless device; FIGURE 5A is a block diagram illustrating an example embodiment of a network node; and

FIGURE 5B is a block diagram illustrating example components of a network node.

DETAILED DESCRIPTION

Third Generation Partnership Project (3GPP) defines a fifth generation (5G) of wireless communication that includes new radio (NR). To improve coverage and increase data rate, NR makes wide use of beamforming. With beamforming, a network can transmit user specific data via a narrow beam, which can improve the signal-to-interference-plus-noise ratio (SINR). The problem is generally referred to as beam failure.

5G NR includes a procedure referred to as beam recovery. Beam recovery may be used upon detection of a beam failure. In beam recovery, a user equipment (UE) performs measurements associated to the quality of the serving link and, if the measured quality goes below a given threshold, the UE performs beam recovery. Beam recovery may be used when the transmit and/or receive beams of the gNodeB and the UE have become misaligned, but where additional beams exist that could be used to maintain the connection between the gNodeB and the UE.

The beam failure recovery procedure includes beam failure detection, new candidate beam identification, beam failure recovery request, and beam failure recovery response. A UE monitors a certain periodic reference signal (RS) to estimate the quality of the serving link. When the quality of the serving link falls below a certain threshold, the UE initiates beam recovery. After the UE has detected beam failure, the UE tries to identify a new beam that would provide adequate quality. The UE searches for a specific RS, which is transmitted from the same network node, but in different candidate beams. After the UE finds a new candidate beam, the UE transmits an uplink signal using certain uplink resources. The gNodeB is prepared to receive the uplink signal in these uplink resources and can determine which candidate beam the UE selected based on the received uplink signal. After the gNodeB receives the beam failure recovery request, the gNodeB sends a downlink response to the UE using the knowledge of the new beam to indicate to the UE that the gNodeB received the request. The UE monitors for the gNB response to the beam failure recovery request. After the UE successfully receives the response, the beam recovery is complete.

A problem with existing solutions is that when contention-free beam recovery request is used, it may be necessary to allocate a large number of dedicated physical random access channel (PRACH) resources because every UE in connected mode will need a dedicated PRACH resource. This allocation overhead is required even if beam recovery may be quite rare. On the other hand, with contention-based beam recovery, the network is not able to distinguish beam recovery request transmissions from initial access requests, which causes a contention resolution step that is unnecessary in most cases.

The embodiments described herein obviate the problems described above and include a pool of PRACH resources reserved for beam recovery. Because the network can identify that a certain received PRACH transmission is a beam recovery request, the network can adapt its actions to that. Any contention only needs to be resolved within the small group of UEs. Thus, allocating a pool of PRACH resources reduces the overhead compared to the contention-free case. Also, particular embodiments avoid full contention resolution associated with contention-based beam recovery. In addition, the network can adapt its actions for beam recovery differently than for a random access request.

Particular embodiments may be implemented by the UE. Some embodiments include a method for transmitting a beam recovery request signal in a UE, where the beam recovery request signal is chosen from a pool of resources dedicated for beam recovery. In particular embodiments, the UE choses the recovery request signal randomly from the pool or the UE chooses the recovery request signal from the pool based on a UE identity.

Particular embodiments may be implemented by the network node. Some embodiments include a method in a network node to respond to a beam recovery request signal from a UE, where the response includes a message that a beam recovery request signal was received. Some embodiments include a method for configuring a UE with a pool of signals dedicated for beam recovery. The UE may be configured with a method to select the beam recovery signal within the pool. The method may be that the UE selects a beam recovery signal randomly within the pool, or that the UE selects a beam recovery signal based on a UE identity.

The following description sets forth numerous specific details. It is understood, however, that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.

Particular embodiments are described with reference to FIGURES 1-5B of the drawings, like numerals being used for like and corresponding parts of the various drawings. LTE and NR are used throughout this disclosure as an example cellular system, but the ideas presented herein may apply to other wireless communication systems as well.

FIGURE 1 is a block diagram illustrating an example wireless network, according to a particular embodiment. Wireless network 100 includes one or more wireless devices 1 10 (such as mobile phones, smart phones, laptop computers, tablet computers, MTC devices, or any other devices that can provide wireless communication) and a plurality of network nodes 120 (such as base stations or eNodeBs). Wireless device 110 may also be referred to as a UE. Network node 120 serves coverage area 1 15 (also referred to as cell 1 15).

In general, wireless devices 1 10 that are within coverage of network node 120 (e.g., within cell 115 served by network node 120) communicate with network node 120 by transmitting and receiving wireless signals 130. For example, wireless devices 110 and network node 120 may communicate wireless signals 130 containing voice traffic, data traffic, and/or control signals. A network node 120 communicating voice traffic, data traffic, and/or control signals to wireless device 110 may be referred to as a serving network node 120 for the wireless device 110. Communication between wireless device 110 and network node 120 may be referred to as cellular communication. Wireless signals 130 may include both downlink transmissions (from network node 120 to wireless devices 110) and uplink transmissions (from wireless devices 110 to network node 120).

Each network node 120 may have a single transmitter or multiple transmitters for transmitting signals 130 to wireless devices 110. In some embodiments, network node 120 may comprise a multi-input multi-output (MIMO) system. Wireless signal 130 may comprise one or more beams. Particular beams may be beamformed in a particular direction. Each wireless device 110 may have a single receiver or multiple receivers for receiving signals 130 from network nodes 120 or other wireless devices 110. Wireless device 110 may receive one or more beams comprising wireless signal 130.

Wireless signals 130 may be transmitted on PRACH resources (e.g., time-frequency resources, PRACH preamble, etc.). The PRACH resources may be partitioned into radio frames, subframes, slots, and/or mini-slots. Network node 120 may dynamically schedule subframes/slots/mini-slots as uplink, downlink, or a combination uplink and downlink. Different wireless signals 130 may comprise different transmission processing times.

Network node 120 may operate in a licensed frequency spectrum, such as an LTE spectrum. Network node 120 may also operate in an unlicensed frequency spectrum, such as a 5 GHz Wi-Fi spectrum. In an unlicensed frequency spectrum, network node 120 may coexist with other devices such as IEEE 802.11 access points and terminals. To share the unlicensed spectrum, network node 120 may perform LBT protocols before transmitting or receiving wireless signals 130. Wireless device 110 may also operate in one or both of licensed or unlicensed spectrum and in some embodiments may also perform LBT protocols before transmitting wireless signals 130. Both network node 120 and wireless device 110 may also operate in licensed shared spectrum.

For example, network node 120a may operate in a licensed spectrum and network node 120b may operate in an unlicensed spectrum. Wireless device 110 may operate in both licensed and unlicensed spectrum. In particular embodiments, network nodes 120a and 120b may be configurable to operate in a licensed spectrum, an unlicensed spectrum, a licensed shared spectrum, or any combination. Although the coverage area of cell 115b is illustrated as included in the coverage area of cell 115a, in particular embodiments the coverage areas of cells 115a and 115b may overlap partially, or may not overlap at all.

In particular embodiments, wireless device 110 and network nodes 120 may perform carrier aggregation. For example, network node 120a may serve wireless device 110 as a PCell and network node 120b may serve wireless device 110 as a SCell. Network nodes 120 may perform self-scheduling or cross-scheduling. If network node 120a is operating in licensed spectrum and network node 120b is operating in unlicensed spectrum, network node 120a may provide license assisted access to the unlicensed spectrum (i.e., network node 120a is a LAA PCell and network node 120b is a LAA SCell).

In particular embodiments, wireless signals 130 may be beamformed in a particular direction. When wireless device 110 loses beamformed wireless signal 130 (i.e., reception drops below a threshold), wireless device 110 may identify a new candidate wireless signal 130 (i.e., measured signal is above a threshold) and transmit a beam recovery request to network node 120. The beam recovery request may use PRACH resources. The UE may select the PRACH resources randomly or based on a UE identifier. In some embodiments, network node 120 may configure wireless device 110 to use a particular set of PRACH resources for the beam recovery request. The beam recovery request is described in more detail below with respect to FIGURES 2 and 3.

In wireless network 100, each network node 120 may use any suitable radio access technology, such as long term evolution (LTE), LTE-Advanced, UMTS, HSPA, GSM, cdma2000, NR, WiMax, WiFi, and/or other suitable radio access technology. Wireless network 100 may include any suitable combination of one or more radio access technologies. For purposes of example, various embodiments may be described within the context of certain radio access technologies. However, the scope of the disclosure is not limited to the examples and other embodiments could use different radio access technologies.

As described above, embodiments of a wireless network may include one or more wireless devices and one or more different types of radio network nodes capable of communicating with the wireless devices. The network may also include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device (such as a landline telephone). A wireless device may include any suitable combination of hardware and/or software. For example, in particular embodiments, a wireless device, such as wireless device 110, may include the components described with respect to FIGURE 4A below. Similarly, a network node may include any suitable combination of hardware and/or software. For example, in particular embodiments, a network node, such as network node 120, may include the components described with respect to FIGURE 5A below.

Particular embodiments include a pool of PRACH resources reserved for the purpose of beam recovery. When transmitting a beam recovery request, a UE is configured to select a PRACH resource from the pool. In general, a PRACH resource is defined by a time- frequency resource and a preamble.

In some embodiments, the UE selects the PRACH resource randomly within the pool allocated for beam recovery. There can also be multiple resources associated to beam recovery to be used by the same UE (e.g., a UE may transmit requests associated to multiple downlink beams).

In some embodiments, the UE selects the PRACH resource associated to the selected beam based on its identity. One such identity may be the C-RNTI, or any other suitable identifier. One way to perform the selection is based on C-RNTI ranges. For example, if the UE's C-RNTI belongs to a given range, then the UE selects a resource from a particular group. That enables the network to determine from the recovery request which UE sent the request, even in the contention-based scheme, and possibly optimize MSG.2 to the particular UE.

When the network node receives a PRACH transmission with PRACH resources from the pool, the network node knows that the PRACH was transmitted from a UE which is served by that particular network node. Thus, the number of UEs that may have transmitted the beam recovery request is limited to a small number, which enables the network node to send an optimized response to the request.

In some embodiments, the network node sends a response to any of the UEs that may use the PRACH resource. The response resembles a normal random access response (RAR), except that the response does not contain a temporary identity. Instead, any UE that receives the beam recovery request response will use its current identity during the subsequent transmission.

In some embodiments, the network node sends a response to only one of the UEs that may use the PRACH resource. Other embodiments include how the network configures the UE with the method for performing beam reselection.

FIGURE 2 is a flow diagram illustrating an example method in a wireless device, according to particular embodiments. In particular embodiments, one or more steps of FIGURE 2 may be performed by wireless device 110 of network 100 described with respect to FIGURE 1.

The method begins at step 212, where the wireless device may receive a configuration of PRACH resources reserved for beam recovery. For example, wireless device 110 may receive, from network node 120, a particular pool of PRACH resources (e.g., a time resource, a frequency resource, a PRACH preamble, or any combination) to use for beam recovery. The PRACH resources may also be associated with particular PRACH preambles (e.g., the time-frequency resources in the pool of time-frequency resources may include a PRACH preamble different from PRACH preambles used by the wireless device for random access). In other embodiments, the wireless device may be preconfigured with the pool, and step 212 may be optional.

At step 214, the wireless device detects a failure of a beamformed wireless signal. For example, wireless device 110 may detect that the strength of a received wireless signal is below a threshold. Wireless device 110 may monitor a particular periodic reference signal (e.g., CSI-RS, SS-block, etc.) to estimate the quality of the serving link.

At step 216, the wireless device selects at least one PRACH resource from a pool of PRACH resources reserved for beam recovery. For example, wireless device 110 may select a PRACH resource from the reserved pool of resources. In some embodiments, the wireless device may select the resource randomly (or pseudo-randomly), or the wireless device may select the resource based on a UE identity (e.g., C-RNTI).

At step 218, the wireless device transmits a beam recovery message to a network node using the selected at least one PRACH resource. For example, wireless device 110 may transmit the beam recovery message to network node 120.

At step 220, the wireless device may receive beam recovery response message from the network node. For example, wireless device 110 may receive a random access response message from network node 120.

Modifications, additions, or omissions may be made to method 200 of FIGURE 2. Additionally, one or more steps in the method of FIGURE 2 may be performed in parallel or in any suitable order. The steps may be repeated over time as necessary.

FIGURE 3 is a flow diagram illustrating an example method in a network node, according to particular embodiments. In particular embodiments, one or more steps of FIGURE 3 may be performed by network node 120 of network 100 described with respect to FIGURE 1. The method begins at step 312, where the network node sends a configuration of PRACH resources reserved for beam recovery to a wireless device. For example, network node 120 may an indication of a particular pool of PRACH time-frequency resources to use for beam recovery to wireless device 110. The time-frequency resources may also be associated with particular PRACH preambles. In other embodiments, the wireless device may be preconfigured with the pool, and step 312 may be optional.

In some embodiments, the network node may send other configuration information to the wireless device. For example, the network node may configure the wireless device to select a resource from the pool randomly or based on an identifier of the wireless device.

At step 314, the network node receives a beam recovery message from the wireless device. For example, network node 120 may receive a beam recovery message from wireless device 110. The beam recovery message may comprise a random access message

At step 316, the network node determines that the beam recovery message is received in a PRACH resource reserved for beam recovery. The network node knows that the beam recovery message was transmitted from a wireless device which is served by the network node. Thus, the number of wireless devices that may have transmitted the beam recovery request is limited to a small number, which enables the network node to send an optimized response to the request. For example, network node 120 may determine that the beam recovery message received from wireless device 110 is in a PRACH resource reserved for beam recovery (e.g., based on a PRACH preamble reserved for beam recovery).

At step 318, the network node sends a beam recovery response to one or more wireless devices configured to use the PRACH resources reserved for beam recovery. In some embodiments, the network node may send the beam recovery response to one wireless device configured to use the PRACH resources reserved for beam recovery. For example, network node 120 may send the beam recovery response to wireless device 110, because network node 120 may be able to determine the beam recovery request originated from wireless device 110 based on the PRACH resource.

In some embodiments, the network node may send the beam recovery response to all wireless device configured to use the PRACH resources reserved for beam recovery. For example, network node 120 may transmit the beam recovery message to all wireless devices 110 configured to use the same pool of PRACH resources for beam recovery. The determination may be based on a range of identifiers associated with the pool. The beam recovery response message may comprise a random access response message. Modifications, additions, or omissions may be made to method 300 of FIGURE 3. Additionally, one or more steps in the method of FIGURE 3 may be performed in parallel or in any suitable order. The steps may be repeated over time as necessary.

FIGURE 4A is a block diagram illustrating an example embodiment of a wireless device. The wireless device is an example of the wireless devices 110 illustrated in FIGURE 1. In particular embodiments, the wireless device is capable of detecting beam failure, selecting a PRACH resource from a pool of PRACH resources reserved for beam recovery, and transmitting a beam recovery message to a network node using the PRACH resource.

Particular examples of a wireless device include a mobile phone, a smart phone, a

PDA (Personal Digital Assistant), a portable computer (e.g., laptop, tablet), a sensor, a modem, a machine type (MTC) device / machine to machine (M2M) device, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles, a device-to- device capable device, a vehicle-to-vehicle device, or any other device that can provide wireless communication. The wireless device includes transceiver 1310, processing circuitry 1320, memory 1330, and power source 1340. In some embodiments, transceiver 1310 facilitates transmitting wireless signals to and receiving wireless signals from wireless network node 120 (e.g., via an antenna), processing circuitry 1320 executes instructions to provide some or all of the functionality described herein as provided by the wireless device, and memory 1330 stores the instructions executed by processing circuitry 1320. Power source 1340 supplies electrical power to one or more of the components of wireless device 110, such as transceiver 1310, processing circuitry 1320, and/or memory 1330.

Processing circuitry 1320 includes any suitable combination of hardware and software implemented in one or more integrated circuits or modules to execute instructions and manipulate data to perform some or all of the described functions of the wireless device. In some embodiments, processing circuitry 1320 may include, for example, one or more computers, one more programmable logic devices, one or more central processing units (CPUs), one or more microprocessors, one or more applications, and/or other logic, and/or any suitable combination of the preceding. Processing circuitry 1320 may include analog and/or digital circuitry configured to perform some or all of the described functions of wireless device 110. For example, processing circuitry 1320 may include resistors, capacitors, inductors, transistors, diodes, and/or any other suitable circuit components. Memory 1330 is generally operable to store computer executable code and data. Examples of memory 1330 include computer memory (e.g., Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

Power source 1340 is generally operable to supply electrical power to the components of wireless device 110. Power source 1340 may include any suitable type of battery, such as lithium-ion, lithium-air, lithium polymer, nickel cadmium, nickel metal hydride, or any other suitable type of battery for supplying power to a wireless device.

Other embodiments of the wireless device may include additional components (beyond those shown in FIGURE 4A) responsible for providing certain aspects of the wireless device's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above).

FIGURE 4B is a block diagram illustrating example components of a wireless device 110. The components may include receiving module 1350, detecting module 1352, selecting module 1354, and transmitting module 1356.

Receiving module 1350 may perform the receiving functions of wireless device 110. For example, receiving module 1350 may receive an indication of a particular pool of PRACH resources to use for beam recovery, and/or receive configuration information for how to select a PRACH resource from the pool of PRACH resources. Receiving module 1350 may receive a beam recovery response message from network node 120. Receiving module 1350 may perform the receiving functions according to any of the examples and embodiments described above. In certain embodiments, receiving module 1350 may include or be included in processing circuitry 1320. In particular embodiments, receiving module 1350 may communicate with detecting module 1352, selecting module 1354, and transmitting module 1356.

Detecting module 1352 may perform the detecting functions of wireless device 110. For example, detecting module 1352 may detect beam failure according to any of the examples and embodiments described above. In certain embodiments, detecting module 1352 may include or be included in processing circuitry 1320. In particular embodiments, detecting module 1352 may communicate with receiving module 1350, selecting module 1354, and transmitting module 1356.

Selecting module 1354 may perform the selecting functions of wireless device 1 10. For example, selecting module 1354 may select PRACH resources from a pool of PRACH resources according to any of the examples and embodiments described above. In certain embodiments, selecting module 1354 may include or be included in processing circuitry 1320. In particular embodiments, selecting module 1354 may communicate with receiving module 1350, detecting module 1352, and transmitting module 1356.

Transmitting module 1356 may perform the transmitting functions of wireless device 110. For example, transmitting module 1356 may transmit a beam recovery request to a network node using particular PRACH resources. In certain embodiments, transmitting module 1356 may include or be included in processing circuitry 1320. In particular embodiments, transmitting module 1356 may communicate with receiving module 1350, determining module 1352, and selecting module 1354.

FIGURE 5 A is a block diagram illustrating an example embodiment of a network node. The network node is an example of the network node 120 illustrated in FIGURE 1. In particular embodiments, the network node is capable of receiving a beam recovery message from a wireless device, determining that the beam recovery message is received in a PRACH resource reserved for beam recovery, and sending a beam recovery response to one or more wireless devices configured to use the PRACH resources reserved for beam recovery.

Network node 120 can be an eNodeB, a nodeB, a base station, a wireless access point (e.g., a Wi-Fi access point), a low power node, a base transceiver station (BTS), a transmission point or node, a remote RF unit (RRU), a remote radio head (RRH), or other radio access node. The network node includes at least one transceiver 1410, at least one processing circuitry 1420, at least one memory 1430, and at least one network interface 1440. Transceiver 1410 facilitates transmitting wireless signals to and receiving wireless signals from a wireless device, such as wireless devices 110 (e.g., via an antenna); processing circuitry 1420 executes instructions to provide some or all of the functionality described above as being provided by a network node 120; memory 1430 stores the instructions executed by processing circuitry 1420; and network interface 1440 communicates signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), controller, and/or other network nodes 120. Processing circuitry 1420 and memory 1430 can be of the same types as described with respect to processing circuitry 1320 and memory 1330 of FIGURE 4A above.

In some embodiments, network interface 1440 is communicatively coupled to processing circuitry 1420 and refers to any suitable device operable to receive input for network node 120, send output from network node 120, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. Network interface 1440 includes appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

FIGURE 5B is a block diagram illustrating example components of a network node

120. The components may include receiving module 1450, determining module 1452, and transmitting module 1454.

Receiving module 1450 may perform the receiving functions of network node 120. For example, receiving module 1450 may receive a beam recovery message from a wireless device according to any of the examples and embodiments described above. In certain embodiments, receiving module 1450 may include or be included in processing circuitry 1420. In particular embodiments, receiving module 1450 may communicate with determining module 1452 and transmitting module 1454.

Determining module 1452 may perform the determining functions of network node 120. For example, determining module 1450 may determine that a beam recovery message is received in a PRACH resource reserved for beam recovery according to any of the examples and embodiments described above. In certain embodiments, determining module 1452 may include or be included in processing circuitry 1420. In particular embodiments, determining module 1452 may communicate with receiving module 1450 and transmitting module 1454.

Transmitting module 1454 may perform the transmitting functions of network node

120. For example, transmitting module 1454 may transmit a beam recovery response to wireless device 110. Transmitting module 1454 may transmit configuration information, such an indication of a pool of PRACH resources and a method of selecting a PRACH resource from the pool, to wireless device 110. Transmitting module 1454 may perform the transmitting functions according to any of the examples and embodiments described above. In certain embodiments, transmitting module 1454 may include or be included in processing circuitry 1420. In particular embodiments, transmitting module 1454 may communicate with receiving module 1450 and determining module 1452. Modifications, additions, or omissions may be made to the systems and apparatuses disclosed herein without departing from the scope of the invention. The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. Additionally, operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, "each" refers to each member of a set or each member of a subset of a set.

Modifications, additions, or omissions may be made to the methods disclosed herein without departing from the scope of the invention. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

Although this disclosure has been described in terms of certain embodiments, alterations and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the spirit and scope of this disclosure, as defined by the claims below.

Abbreviations used in the preceding description include:

3 GPP Third Generation Partnership Project

BBU Baseband Unit

BPL Beam Pair Link

BTS Base Transceiver Station

CC Component Carrier

CQI Channel Quality Information

CSI Channel State Information

D2D Device to Device

DFT Discrete Fourier Transform

DMRS Demodulation Reference Signal

eNB eNodeB

FDD Frequency Division Duplex

FDM Frequency Division Multiplexing

FFT Fast Fourier Transform

gNB Next-generation NodeB

LAA Licensed-Assisted Access LBT Listen-before-talk

LTE Long Term Evolution

LTE-U LTE in Unlicensed Spectrum

M2M Machine to Machine

MIB Master Information Block

MIMO Multi-Input Multi-Output

MTC Machine Type Communication

NR New Radio

OFDM Orthogonal Frequency Division Multiplexing

PDCCH Physical Downlink Control Channel

PDSCH Physical Downlink Shared Channel

PRACH Physical Random Access Channel

PUCCH Physical Uplink Control Channel

PUSCH Physical Uplink Shared Channel

RACH Random Access Channel

RAN Radio Access Network

RAT Radio Access Technology

RBS Radio Base Station

RLF Radio Link Failure

RNC Radio Network Controller

RNTI Radio Network Temporary Identifier

RRC Radio Resource Control

RRH Remote Radio Head

RRU Remote Radio Unit

RS Reference Signal

SCell Secondary Cell

SI System Information

SIB System Information Block

SINR Signal to Interference plus Noise Ratio

SSB Synchronization Signal Block

TDD Time Division Duplex

TTI Transmission Time Interval

UE User Equipment UL Uplink

UTRAN Universal Terrestrial Radio Access Network WAN Wireless Access Network

Claims

1. A method for use in a wireless device of a wireless communication network, the method comprising:

detecting (214) failure of a beamformed wireless signal;

selecting (216) at least one physical random access channel (PRACH) resource from a pool of PRACH resources reserved for beam recovery; and

transmitting (218) a beam recovery message to a network node using the selected at least one PRACH resource;

wherein a PRACH resource comprises at least one of a time resource, a frequency resource, and a PRACH preamble.

2. The method of claim 1, wherein selecting the at least one PRACH resource comprises selecting the at least one PRACH resource randomly from the pool of PRACH resources reserved for beam recovery.

3. The method of claim 1, wherein selecting the at least one PRACH resource comprises selecting the at least one PRACH resource from the pool of PRACH resources reserved for beam recovery based on an identity of the wireless device.

4. The method of claim 3, wherein the identity of the wireless device comprises a radio network temporary identifier.

5. The method of any one of claims 3-4, wherein the identity of the wireless device comprises one identifier among a range of identifiers and selecting the at least one PRACH resource is based on the range of identifiers.

6. The method of any one of claims 1-5, wherein the beam recovery message comprises a random access message.

7. The method of any one of claims 1-6, wherein the PRACH resources in the pool of PRACH resources include different PRACH resources than the PRACH resources used by the wireless device for random access.

8. The method of any one of claims 1-7, further comprising receiving (212) a configuration of PRACH resources reserved for beam recovery.

9. The method of any one of claims 1-8, further comprising receiving (220) a beam recovery response message from the network node.

10. The method of claim 9, wherein the recovery response message comprises a random access response message.

11. A wireless device (110) comprising processing circuitry (1320) operable to: detect failure of a beamformed wireless signal;

select at least one PRACH resource from a pool of PRACH resources reserved for beam recovery; and

transmit a beam recovery message to a network node (120) using the selected at least one PRACH resource;

12. The wireless device of claim 11, wherein the processing circuitry is operable to select the at least one PRACH resource by selecting the at least one PRACH resource randomly from the pool of PRACH resources reserved for beam recovery.

13. The wireless device of claim 11, wherein the processing circuitry is operable to select the at least one PRACH resource by selecting the at least one PRACH resource from the pool of PRACH resources reserved for beam recovery based on an identity of the wireless device.

14. The wireless device of claim 13, wherein the identity of the wireless device comprises a radio network temporary identifier.

15. The wireless device of any one of claims 13-14, wherein the identity of the wireless device comprises one identifier among a range of identifiers and selecting the at least one PRACH resource is based on the range of identifiers.

16. The wireless device of any one of claims 11-15, wherein the beam recovery message comprises a random access message.

17. The wireless device of any one of claims 11-16, wherein the PRACH resources in the pool of PRACH resources include a PRACH preamble different from PRACH preambles used by the wireless device for random access.

18. The wireless device of any one of claims 11-17, the processing circuitry further operable to receive a configuration of PRACH resources reserved for beam recovery.

19. The wireless device of any one of claims 11-18, the processing circuitry further operable to receive a beam recovery response message from the network node.

20. The wireless device of claim 19, wherein the recovery response message comprises a random access response message.

21. A method for use in a network node of a wireless communication network, the method comprising:

receiving (314) a beam recovery message from a wireless device;

determining (316) that the beam recovery message is received in a physical random access channel (PRACH) resource reserved for beam recovery; and

sending (318) a beam recovery response to one or more wireless devices configured to use the PRACH resources reserved for beam recovery;

22. The method of claim 21, wherein the beam recovery message comprises a random access message and the beam recovery response message comprises a random access response message.

23. The method of any one of claims 21-22, further comprising sending (312) a configuration of PRACH resources reserved for beam recovery to the wireless device.

24. The method of any one of claims 21-23, further comprising sending (312) the wireless device an indication to randomly select PRACH resources from a pool of PRACH resources reserved for beam recovery.

25. The method of any one of claims 21-23, further comprising sending (312) the wireless device an indication to select PRACH resources from a pool of PRACH resources reserved for beam recovery based on an identity of the wireless device.

26. The method of claim 25, wherein the identity of the wireless device comprises a radio network temporary identifier.

27. The method of any one of claims 21-26, wherein the PRACH resource used for beam recovery includes a PRACH resource different from PRACH resources used by the wireless device for random access.

28. The method of any one of claims 21-27, wherein sending the beam recovery response to one or more wireless devices comprises sending the beam recovery response to all wireless devices configured to use the PRACH resources reserved for beam recovery.

29. The method of any of embodiments 21-28, wherein sending the beam recovery response to one or more wireless devices comprises sending the beam recovery response to one wireless devices configured to use the PRACH resources reserved for beam recovery.

30. A network node (120) comprising processing circuitry (1420) operable to: receive a beam recovery message from a wireless device (110);

determine that the beam recovery message is received in a physical random access channel (PRACH) resource reserved for beam recovery; and

send a beam recovery response to one or more wireless devices (110) configured to use the PRACH resources reserved for beam recovery;

31. The network node of claim 30, wherein the beam recovery message comprises a random access message and the beam recovery response message comprises a random access response message.

32. The network node of any one of claims 30-31, the processing circuitry further operable to send a configuration of PRACH resources reserved for beam recovery to the wireless device.

33. The network node of any one of claims 30-32, the processing circuitry further operable to send the wireless device an indication to randomly select PRACH resources from a pool of PRACH resources reserved for beam recovery.

34. The network node of any one of claims 30-32, the processing circuitry further operable to send the wireless device an indication to select PRACH resources from a pool of PRACH resources reserved for beam recovery based on an identity of the wireless device.

35. The network node of claim 34, wherein the identity of the wireless device comprises a radio network temporary identifier.

36. The network node of any one of claims 30-35, wherein the PRACH resource used for beam recovery includes a PRACH resource different from PRACH resources used by the wireless device for random access.

37 The network node of any one of claims 30-36, wherein the processing circuitry is operable to send the beam recovery response to one or more wireless devices by sending the beam recovery response to all wireless devices configured to use the PRACH resources reserved for beam recovery.

38. The network node of any of embodiments 30-36, wherein the processing circuitry is operable to send the beam recovery response to one or more wireless devices by sending the beam recovery response to one wireless devices configured to use the PRACH reserved for beam recovery.

39. A wireless device (110) comprising a detecting module (1352), a selecting module (1354), and a transmitting module (1356);

the detecting module operable to detect failure of a beamformed wireless signal; the selecting module operable to select at least one physical random access channel (PRACH) resource from a pool of PRACH resources reserved for beam recovery; and

the transmitting module operable to transmit a beam recovery message to a network node (120) using the selected at least one PRACH resource;

40. A network node (120) comprising a receiving module (1450), a determining module (1452), and a transmitting module (1454);

the receiving module operable to receive a beam recovery message from a wireless device (110);

the determining module operable to determine that the beam recovery message is received in a physical random access channel (PRACH) resource reserved for beam recovery; and

the transmitting module operable to send a beam recovery response to one or more wireless devices (110) configured to use the PRACH resources reserved for beam recovery.