Patent Description:
In modern communications systems, such as those that are Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) compliant, requests are sent by a first device to a second device to initiate a service or process. As an example, a user equipment (UE) may send a scheduling request to an access node to request that the access node allocate one or more network resources to the UE to allow the UE to make a transmission.

There are many different types of requests and in many implementations, each of the different requests is communicated over resources solely dedicated to the particular request. Thereby leading to the inefficient use of valuable network resources. Therefore, there is a need for systems and methods that improve the efficiency associated with the communicating of requests.

Document <NPL> briefly discusses the random access channel capacity and particularly considers the aspects of RACH preamble sequence capacity of long and short preamble formats; RACH use cases and impact on RACH sequence capacity; and methods for increasing RACH preamble sequence capacity.

Document <NPL> generally discusses the remaining issues and detail relating to beam recovery.

Example embodiments provide methods and apparatuses for request multiplexing. In particular, there is provided a computer implemented method for operating a UE, a computer implemented method for operating an access node, a UE and an access node, having the features of respective independent claims. The dependent claims relate to embodiments.

The making and using of the presently example embodiments are discussed in detail below. It should be appreciated, however, that the present disclosure provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific ways to make and use the embodiments, and do not limit the scope of the disclosure.

<FIG> illustrates an example wireless communications system <NUM>. Communications system <NUM> includes an access node <NUM> serving a user equipment (UE) <NUM>. In a first operating mode, communications to and from UE <NUM> pass through access node <NUM>. In a second operating mode, communications to and from UE <NUM> do not pass through access node <NUM>, however, access node <NUM> typically allocates resources used by UE <NUM> to communicate. Access nodes may also be commonly referred to as evolved NodeBs (eNBs), base stations, NodeBs, master eNBs (MeNBs), secondary eNBs (SeNBs), next generation (NG) NodeBs (gNBs), master gNBs (MgNBs), secondary gNBs (SgNBs), remote radio heads, access points, and the like, while UEs may also be commonly referred to as mobiles, mobile stations, terminals, subscribers, users, stations, and the like.

While it is understood that communications systems may employ multiple access nodes capable of communicating with a number of UEs, only one access node and one UE are illustrated for simplicity.

Pathloss in communications systems operating at high frequency (HF) (<NUM> gigahertz (GHz) and above, such as millimeter wavelength (mmWave)) operating frequencies is high, and beamforming may be used to overcome the high pathloss. As shown in <FIG>, both access node <NUM> and UE <NUM> communicate using beamformed transmissions and receptions. As an example access node <NUM> communicates using a plurality of communications beams, including beams <NUM> and <NUM>, while UE <NUM> communicates using a plurality of communications beams, including beams <NUM> and <NUM>.

A beam may be a pre-defined set of beamforming weights in the context of codebook-based precoding or a dynamically defined set of beamforming weights in the context of non-codebook based precoding (e.g., Eigen-based beamforming (EBB)). A beam may also be a pre-defined set of phase shift preprocessors combining signals from the antenna array in the radio frequency (RF) domain. It should be appreciated that a UE may rely on codebook-based precoding to transmit uplink signals and receive downlink signals, while a TRP may rely on non-codebook based precoding to form certain radiation patterns to transmit downlink signals or receive uplink signals.

The beams of HF communications systems are fragile due to the high pathloss present at HF. The beams are easily blocked by objects or entities located in or near the path between source and destination. The signal quality of beams that are experiencing blockage is typically significantly lower when compared to the signal quality prior to the occurrence of the blockage (or even beams that are not blocked). When the signal quality drops below a specified threshold, the associated beam(s) may be deemed as having failed. In other words, a beam is deemed as a failed beam when the signal quality associated with the beam drops below the specified threshold. Alternatively, a beam may be deemed as having failed if the decoding of received packets of a particular channel fails for a specified number of packets or for a specified amount of time.

When a beam failure between an access node and a UE is detected, the UE may select one or more replacement beams from a set of candidate beams of the access node detectable by the UE to replace the failed beam. The replacement of the failed beam with the one or more replacement beam occurs during a beam failure recovery procedure performed by the UE and the access node. The beam failure recovery procedure may be initiated by the UE, or alternatively, the access node may initiate the beam failure recovery procedure. A detailed discussion of an example UE initiated beam failure recovery procedure is as follows:.

The NIB of the one or more candidate beams may be signaled implicitly by the UE. As an illustrative example, the location of the preamble in the time, frequency, or sequence domain conveys information about the NIB. An example implicit signaling approach takes place over two steps: Step <NUM> includes the transmission of the preamble by the UE at a location that conveys information about the NIB; and Step <NUM> includes the access node transmitting a response to the UE. In an embodiment, the response includes a PDCCH or a physical downlink shared channel (PDSCH) message from the access node to the UE. Upon detecting the PDCCH or PDSCH message, UE is able to receive a response and may conclude that the beam failure recovery procedure has completed successfully or unsuccessfully. In another embodiment, the response includes a request from the access node for further signaling. One example of such a request is that the access node may request, within this response message, the UE to further report beam quality information associated with the previous new identified beam index. Another example of such a request is that the access node may request, within this response message, the UE to participate in a downlink or uplink beam management, beam refinement, or beam tracking procedure, while the request itself may include configurations of such a beam management, beam refinement, or beam tracking procedure. Together with this request, the access node may also send a uplink grant to the UE assigning a certain uplink resources to the UE so that UE may use uplink resources to send the requested beam quality report, or to participate in the beam management, beam refinement, or beam tracking procedure (e.g., sending uplink sounding reference signals, sending downlink reference signal measurement results, and so on).

Alternatively, the NIB of the one or more candidate beams may be signaled explicitly by the UE. An example explicit signaling approach takes place over four steps: Step <NUM> includes the transmission of the preamble by the UE; Step <NUM> includes the access node assigning an uplink grant to the UE; Step <NUM> includes the UE explicitly sending the NIB (e.g., a CRI) to the access node in network resources of the uplink grant; and Step <NUM> includes the access node transmitting a response to the UE. It is noted that a combination of both implicit and explicit signaling of the NIB may be used.

<FIG> illustrates a wireless communications system <NUM> highlighting beam failure and beam failure recovery. Communications system <NUM> includes an access node <NUM> serving a UE <NUM>. As shown in <FIG>, both access node <NUM> and UE <NUM> communicate using beamformed transmissions and receptions. As an example access node <NUM> communicates using a plurality of communications beams, including beams <NUM> and <NUM>, while UE <NUM> communicates using a plurality of communications beams, including beams <NUM> and <NUM>.

Initially, access node <NUM> and UE <NUM> are communicating through beam pair link (BPL) <NUM>, which comprises beams <NUM> and <NUM> as the beam pair. However, due to blockage or UE mobility, BPL <NUM> fails. As an example, a blockage occurs between access node <NUM> and UE <NUM>, causing BPL <NUM> to fail. UE <NUM> detects a candidate beam <NUM> from access node <NUM> to replace failed beam <NUM>, for example. UE <NUM> initiates beam failure recovery by sending a BFRQ to access node <NUM>. Upon completion of the beam failure recovery, BPL <NUM> is established (comprising beams <NUM> and <NUM> as the beam pair).

The BRACH preamble sent by the UE in the BFRQ is sent in a BRACH resource. BRACH resources may be separated in the time domain, frequency domain, sequence domain, or a combination thereof. Each BRACH resource that can be used to convey a BRACH preamble of a particular UE may be referred to as a possible BRACH resource (PBR) of the UE. As an example, a UE may send a BRACH preamble in PBR time resources <NUM>, <NUM>, and so on. As another example, a UE may send a BRACH preamble in PBR frequency resource <NUM>, <NUM>, and so forth. As yet another example, a UE may send a BRACH preamble in PBR sequence resource <NUM>, <NUM>, etc. As yet another example, a UE may send a BRACH preamble in PBR resource with cyclic shift <NUM>, <NUM>, and so on. In general, a UE has N PBRs with which to send a BRACH preamble. By selecting one out of the N PBRs to actually transmit the BRACH preamble, the UE is able to implicitly convey Log<NUM>(N) bits of information to the access node. The access node is able to detect which BRACH resource that the UE used to transmit the BRACH preamble and is able to infer the Log<NUM>(N) bits of information from the UE. The Log<NUM>(N) bits of information may be used to convey information about the NIB (e.g., the CRI, SSI, or some other beam index).

For discussion purposes, consider a situation where there are N BFRSs (such as SSs, CSI-RSs, etc.) configured as possible new beam indices, together with M PBRs, where N is less than or equal to M. Then, each of the N BFRSs may be associated with one or more PBRs. In general, a reference signal (RS) is associated with a resource if the RS is assigned to be transmitted in the resource. Similarly, a beam is associated with a RS if the RS is assigned to be transmitted on the beam. Conversely, a RS is unassociated or not associated with a resource if the RS is not assigned to be transmitted in the resource, and a beam is unassociated or not associated with the RS if the RS is not assigned to be transmitted on the beam. As an illustrative example, if an access node receives a BRACH preamble in a BRACH resource associated with a first set of PBRs, PBR1 (associated with a first BFRS, BFRS1), the access node may interpret the BFRS1 as the NIB. Similarly, if the access node receives the BRACH preamble in a BRACH resource associated with a second set of PBRs, PBR2 (associated with a second BFRS, BFRS2), the access node may interpret the BFRS2 as the NIB, and so forth.

Furthermore, to simplify discussion, consider a situation where there are N BFRS and M PBRs, where N is equal to M. Then, if a first UE sends a first BRACH preamble on PBR1, then an access node should treat the first BRACH preamble as a BFRQ from the first UE, and at the same time, because the first BRACH preamble is received in PBR1 (instead of PBR2, PBR3, and so on), the access node may interpret that BFRS1 is the NIB, instead of BFRS2, BFRS3, and so forth. Similarly, if the first UE sends the first BRACH preamble on PBR2, then the access node should treat the first BRACH preamble as a BFRQ from the first UE, and at the same time, because the first BRACH preamble is received in PBR2 (instead of PBR1, PBR3, and so forth), the access node may interpret that BFRS2 is the NIB, instead of BFRS1, BFRS3, and so forth.

It is noted that if a beam associated with a particular BFRS is the serving beam of a UE prior to a beam failure occurring on the beam, the access node should not be expecting to receive a BRACH preamble conveying information about the beam in a BFRQ from the UE. This is because it is not logical for the UE to be able to detect the beam as a candidate beam while experiencing a beam failure with the same beam. Therefore, the serving beam of the UE is an invalid candidate beam. As an example, if BFRS3 is the serving beam of the UE, the access node should not expect to receive a BFRQ in PBR3 (which conveys information about BFRS3 as the NIB) from the UE. In the illustrative example, BFRS3 is an invalid BFRS. Conversely, the other beams of the access node may all potentially be valid candidate beams. These other beams may be referred to as valid beams, and their BFRSs are valid BFRSs.

Similarly, there are valid and invalid PBRs. PBRs that are interpreted by an access node as conveying information about valid beams are referred to as valid PBRs, while PBRs that are interpreted by the access node as conveying information about invalid beams are referred to as invalid PBRs. Valid and invalid PBRs may be considered to be mutually exclusive and are part of a plurality of PBRs available to a UE or access node to send or receive requests or beams.

According to an example embodiment, BFRQs and any other type of request (ATRQ) are multiplexed using valid and invalid PBRs (or conveying information about valid and invalid BFRSs). ATRQs may include scheduling requests (SRQs), handover requests (HRQs), beam refinement requests (BRRQs), beam management requests (BMRQs), power control or adjustment requests (PARQs), and so on. As an illustrative example, a UE multiplexes a BFRQ with an ATRQ so that one preamble is used by the UE to convey information about a BFRQ or an ATRQ in different resources. The access node may then perform preamble analysis to identify the UE, as well as identify if the request is a BFRQ or an ATRQ and take appropriate response.

As an illustrative example, let BFRSn be the BFRS associated with the serving beam of a UE, then BFRSn is associated with an invalid beam, while other possible BFRSs are associated with valid beams. Therefore, PBRn is an invalid PBR and other possible PBRs are valid PBRs. The UE can use any of the valid PBRs to transmit a BFRQ, and while to multiplex requests, e.g., transmit an ATRQ, the UE uses the invalid PBR.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a UE multiplexing requests. Operations <NUM> may be indicative of operations occurring in a UE as the UE multiplexes requests.

Operations <NUM> begin with the UE generating a request (block <NUM>). The UE selects a PBR in accordance with a request type of the request (block <NUM>). As an example, the UE performs a check to determine if the request type is a BFRQ (block <NUM>). If the request is a BFRQ, the UE transmits the request in a PBR from a first subset of PBRs (e.g., a valid PBR) (block <NUM>). If the request is not a BFRQ, the UE transmits the request in a PBR from a second subset of PBRs (e.g., an invalid PBR) (block <NUM>). Alternatively, if UE is to convey information about a beam associated with a reference signal, the UE checks in block <NUM> to determine if the beam associated the reference signal is valid or invalid. If the beam is valid, then the UE conveys information about the beam on the valid PBR (block <NUM>) or else the UE convey information about the beam on the invalid PBR (block <NUM>).

<FIG> illustrates a flow diagram of example operations <NUM> occurring in an access node receiving multiplexed requests. Operations <NUM> may be indicative of operations occurring in an access node as the access node receives multiplexed requests from a UE.

Operations <NUM> begin with the access node receiving a request (block <NUM>). The access node determines a request type of the request (block <NUM>). As an example, the access node performs a check to determine if the request is received in a valid PBR (block <NUM>). According to an example embodiment, the access node determines the validity of a PBR by identifying the identity of the UE that sent the request and determining valid and invalid PBRs in accordance with the identity of the UE. If the PBR is valid, then the request is a BFRQ (block <NUM>). If the PBR is invalid, then the request is an ATRQ (block <NUM>). The access node sends a response responsive to the request (block <NUM>). As an example, if the request is an ATRQ, the access node sends a response that is responsive to the ATRQ, while if the request is a BFRQ, the access node sends a BFRR to address the BFRQ. Responses responsive to the ATRQ may include a scheduling request response, a handover request response, and so on.

A handover refers to a process wherein a first connection between a UE and a first access node is transferred to a second connection between the UE and a second access node. Handovers typically occur due to UE mobility or changing channel condition. A handover may be initiated by the UE, the first access node, or both the UE and the first access node.

<FIG> illustrates a communications system <NUM> highlighting a handover. Communications system <NUM> includes a first access node (AN_1) <NUM> with a coverage area <NUM>, and a second access node (AN_2) <NUM> with a coverage area <NUM>. Communications system <NUM> also includes a UE <NUM>. Initially, UE <NUM> is served by first access node <NUM>. However, due to UE mobility or changing channel condition, the signal quality of a channel between first access node <NUM> and UE <NUM> is decreasing while the signal quality of a channel between second access node <NUM> and UE <NUM> is increasing. A handover may be performed by first access node <NUM>, second access node <NUM>, and UE <NUM> to transfer service for UE <NUM> from first access node <NUM> to second access node <NUM>.

<FIG> illustrates a diagram <NUM> processing occurring in and communications exchanged between devices participating in a handover. Diagram <NUM> displays processing occurring in and communications exchanged between a UE <NUM>, a serving or source access node <NUM>, and a target access node <NUM> as the devices participate in a handover. Serving or source access node <NUM> is shown in <FIG> as serving or source access node <NUM>.

Target access node <NUM> sends reference signals (such as BFRSs, SSs, CSI-RSs, and so on) (event <NUM>). Serving or source access node <NUM> sends reference signals (such as BFRSs, SSs, CSI-RSs, and so on) (event <NUM>). UE <NUM> makes measurements of reference signals transmitted by target access node <NUM> and serving or source access node <NUM> (block <NUM>). The measurements made by UE <NUM> may include SINR, SNR, RSRP or RSRQ of one or more first reference signals (e.g., SSs) transmitted by target access node <NUM>, and SINR, SNR, RSRP or RSRQ of one or more second reference signals (e.g., CSI-RSs) transmitted by target access node <NUM>. In addition to measuring the reference signals sent by serving or source access node <NUM> and target access node <NUM>, UE <NUM> identifies the beams associated with the reference signals. It is noted that for each reference signal, UE <NUM> may identify one or more beams.

UE <NUM> sends channel reports to serving or source access node <NUM> (event <NUM>). As an example, UE <NUM> may send a channel report associated with target access node <NUM> to serving or source access node <NUM>. The channel report associated with target access node <NUM> may include one or more indices of beams associated with the one or more first reference signals received from target access node <NUM> along with measured SINR, SNR, RSRP or RSRQ. The channel report associated with target access node <NUM> may also include one or more indices of beams associated with the one or more second reference signals received from target access node <NUM> along with measured SINR, SNR, RSRP or RSRQ. As an example, UE <NUM> may send a channel report associated with serving or source access node <NUM> to serving or source access node <NUM>. The channel report associated with serving or source access node <NUM> may include one or more indices of beams associated with the one or more first reference signals received from serving or source access node <NUM> along with measured SINR, SNR, RSRP or RSRQ. The channel report associated with serving or source access node <NUM> may also include one or more indices of beams associated with the one or more second reference signals received from serving or source access node <NUM> along with measured SINR, SNR, RSRP or RSRQ.

Serving or source access node <NUM> makes a handover decision (block <NUM>). The handover decision may be made in accordance with the channel reports received from UE <NUM>, for example. For discussion purposes, it is considered that serving or source access node <NUM> made the decision to handover UE <NUM> to target access node <NUM>. Serving or source access node <NUM> sends a handover request to target access node <NUM> (event <NUM>). The handover request may include one or more indices of beams associated with the one or more first reference signals transmitted by target access node <NUM> and received by UE <NUM> along with measured SINR, SNR, RSRP or RSRQ. The number of indices of the one or more first reference signals included in the handover request may be different from the number one or more indices of beams associated with the one or more first reference signals reported by UE <NUM> in event <NUM>. The handover request may also include one or more indices of beams associated with the one or more second reference signals transmitted by target access node <NUM> and received by UE <NUM> along with measured SINR, SNR, RSRP or RSRQ if the second reference signal is configured for interference or mobility measurement purposes. If included, the number of indices of the one or more second reference signals included in the handover request may be different from the number one or more indices of beams associated with the one or more second reference signals reported by UE <NUM> in event <NUM>. The handover request conveys information about a handover request to target access node <NUM>.

Target access node <NUM> sends a handover response to serving or source access node <NUM> (event <NUM>). The handover response may include an assigned non-contention-based preamble for UE <NUM>. The handover response may also include a BRACH resource in time, frequency, or sequence domain assigned to UE <NUM>, where UE <NUM> is to use the BRACH resource to transmit the preamble for handover purposes. It is noted that in order for UE <NUM> to send a handover request later, UE <NUM> needs to send the assigned non-contention-based preamble only at the specified BRACH resource. If the assigned non-contention-based preamble is sent by the UE but not at the specified BRACH resource, then the handover request will be ignored. Serving or source access node <NUM> may forward the handover response to UE <NUM> or alternatively, serving or source access node <NUM> sends the information in the handover response to UE <NUM> (event <NUM>). UE <NUM> starts the handover (event <NUM>). UE <NUM> may start the handover by transmitting the preamble in the BRACH resource (event <NUM>) as specified earlier in the handover response, originally specified by target access node <NUM>, delivered to UE <NUM> via serving or source access node <NUM>.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a target access node receiving and processing a multiplexed request. Operations <NUM> may be indicative of operations occurring in a target access node as the target access node receives and processes a multiplexed request.

Operations <NUM> begin with the target access node receiving a preamble at or about time T (block <NUM>). The target access node performs a check to determine if it is participating in a handover involving the preamble (block <NUM>). As an example, the target access node may be participating in a handover involving the preamble if the target access node has recently received a handover request from a serving or source access node regarding a UE for a possible handover with a first time window around the time T. As an example, the target access node may also be participating in a handover involving the preamble if the target access node has allocated the preamble to the UE within a second time window around the time T. As an example, the target access node may also be participating in a handover involving the preamble if the target access node has not yet successfully completed such a handover request. If the target access node is participating in a handover involving the preamble, the target access node treats the preamble is a handover request (block <NUM>). If the target access node is not participating in a handover involving the preamble, the target access node treats the preamble as other types of requests, i.e., an ATRQ (block <NUM>).

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a UE participating in a handover. Operations <NUM> may be indicative of operations occurring in a UE as the UE participates in a handover.

Operations <NUM> begin with the UE receiving a preamble and BRACH resource assignment (block <NUM>). The preamble and the BRACH resource assignment may be made by a target access node and forwarded by a serving or source access node. The UE performs a check to determine if it is to start a handover (block <NUM>). If the UE is to start a handover, the UE sends the assigned preamble in the assigned BRACH resource (block <NUM>). If the UE is not to start a handover, operations <NUM> end.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a serving or source access node participating in a handover. Operations <NUM> may be indicative of operations occurring in a serving or source access node as the serving or source access node participates in a handover.

Operations <NUM> begin with the serving or source access node receiving channel reports from a UE (block <NUM>). The serving or source access node sends a handover request to a target access node (block <NUM>). The handover request may include a subset of information included in the channel reports. The serving or source access node receives a handover response (block <NUM>). The handover response may include a preamble and a BRACH resource assigned to the UE for handover purposes. The serving or source access node forwards the preamble and BRACH resource assignment to the UE (block <NUM>).

<FIG> illustrates an example communication system <NUM>. In general, the system <NUM> enables multiple wireless or wired users to transmit and receive data and other content. The system <NUM> may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), or non-orthogonal multiple access (NOMA).

In this example, the communication system <NUM> includes electronic devices (ED) 710a-710c, radio access networks (RANs) 720a-720b, a core network <NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>. While certain numbers of these components or elements are shown in <FIG>, any number of these components or elements may be included in the system <NUM>.

The EDs 710a-710c are configured to operate or communicate in the system <NUM>. For example, the EDs 710a-710c are configured to transmit or receive via wireless or wired communication channels. Each ED 710a-710c represents any suitable end user device and may include such devices (or may be referred to) as a user equipment or device (UE), wireless transmit or receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular telephone, personal digital assistant (PDA), smartphone, laptop, computer, touchpad, wireless sensor, or consumer electronics device.

The RANs 720a-720b here include base stations 770a-770b, respectively. Each base station 770a-770b is configured to wirelessly interface with one or more of the EDs 710a-710c to enable access to the core network <NUM>, the PSTN <NUM>, the Internet <NUM>, or the other networks <NUM>. For example, the base stations 770a-770b may include (or be) one or more of several well-known devices, such as a base transceiver station (BTS), a Node-B (NodeB), an evolved NodeB (eNodeB), a Home NodeB, a Home eNodeB, a site controller, an access point (AP), or a wireless router. The EDs 710a-710c are configured to interface and communicate with the Internet <NUM> and may access the core network <NUM>, the PSTN <NUM>, or the other networks <NUM>.

In the embodiment shown in <FIG>, the base station 770a forms part of the RAN 720a, which may include other base stations, elements, or devices. Also, the base station 770b forms part of the RAN 720b, which may include other base stations, elements, or devices. Each base station 770a-770b operates to transmit or receive wireless signals within a particular geographic region or area, sometimes referred to as a "cell. " In some embodiments, multipleinput multiple-output (MIMO) technology may be employed having multiple transceivers for each cell.

The base stations 770a-770b communicate with one or more of the EDs 710a-710c over one or more air interfaces <NUM> using wireless communication links. The air interfaces <NUM> may utilize any suitable radio access technology.

It is contemplated that the system <NUM> may use multiple channel access functionality, including such schemes as described above. In particular embodiments, the base stations and EDs implement LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and wireless protocols may be utilized.

The RANs 720a-720b are in communication with the core network <NUM> to provide the EDs 710a-710c with voice, data, application, Voice over Internet Protocol (VoIP), or other services. Understandably, the RANs 720a-720b or the core network <NUM> may be in direct or indirect communication with one or more other RANs (not shown). The core network <NUM> may also serve as a gateway access for other networks (such as the PSTN <NUM>, the Internet <NUM>, and the other networks <NUM>). In addition, some or all of the EDs 710a-710c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies or protocols. Instead of wireless communication (or in addition thereto), the EDs may communicate via wired communication channels to a service provider or switch (not shown), and to the Internet <NUM>.

For example, the processing unit <NUM> could perform signal coding, data processing, power control, input or output processing, or any other functionality enabling the ED <NUM> to operate in the system <NUM>.

The ED <NUM> also includes at least one transceiver <NUM>. The transceiver <NUM> is configured to modulate data or other content for transmission by at least one antenna or NIC (Network Interface Controller) <NUM>. The transceiver <NUM> is also configured to demodulate data or other content received by the at least one antenna <NUM>. Each transceiver <NUM> includes any suitable structure for generating signals for wireless or wired transmission or processing signals received wirelessly or by wire. Each antenna <NUM> includes any suitable structure for transmitting or receiving wireless or wired signals. One or multiple transceivers <NUM> could be used in the ED <NUM>, and one or multiple antennas <NUM> could be used in the ED <NUM>. Although shown as a single functional unit, a transceiver <NUM> could also be implemented using at least one transmitter and at least one separate receiver.

The ED <NUM> further includes one or more input or output devices <NUM> or interfaces (such as a wired interface to the Internet <NUM>). The input or output devices <NUM> facilitate interaction with a user or other devices (network communications) in the network. Each input or output device <NUM> includes any suitable structure for providing information to or receiving or providing information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.

In addition, the ED <NUM> includes at least one memory <NUM>. The memory <NUM> stores instructions and data used, generated, or collected by the ED <NUM>. For example, the memory <NUM> could store software or firmware instructions executed by the processing unit(s) <NUM> and data used to reduce or eliminate interference in incoming signals. Each memory <NUM> includes any suitable volatile or non-volatile storage and retrieval device(s). Any suitable type of memory may be used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, and the like.

As shown in <FIG>, the base station <NUM> includes at least one processing unit <NUM>, at least one transceiver <NUM>, which includes functionality for a transmitter and a receiver, one or more antennas <NUM>, at least one memory <NUM>, and one or more input or output devices or interfaces <NUM>. The processing unit <NUM> implements various processing operations of the base station <NUM>, such as signal coding, data processing, power control, input or output processing, or any other functionality.

Each transceiver <NUM> includes any suitable structure for generating signals for wireless or wired transmission to one or more EDs or other devices. Each transceiver <NUM> further includes any suitable structure for processing signals received wirelessly or by wire from one or more EDs or other devices. Although shown combined as a transceiver <NUM>, a transmitter and a receiver could be separate components. Each antenna <NUM> includes any suitable structure for transmitting or receiving wireless or wired signals. While a common antenna <NUM> is shown here as being coupled to the transceiver <NUM>, one or more antennas <NUM> could be coupled to the transceiver(s) <NUM>, allowing separate antennas <NUM> to be coupled to the transmitter and the receiver if equipped as separate components. Each memory <NUM> includes any suitable volatile or non-volatile storage and retrieval device(s). Each input or output device <NUM> facilitates interaction with a user or other devices (network communications) in the network. Each input or output device <NUM> includes any suitable structure for providing information to or receiving or providing information from a user, including network interface communications.

<FIG> is a block diagram of a computing system <NUM> that may be used for implementing the devices and methods disclosed herein. For example, the computing system can be any entity of UE, access network (AN), mobility management (MM), session management (SM), user plane gateway (UPGW), or access stratum (AS). Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system <NUM> includes a processing unit <NUM>. The processing unit includes a central processing unit (CPU) <NUM>, memory <NUM>, and may further include a mass storage device <NUM>, a video adapter <NUM>, and an I/O interface <NUM> connected to a bus <NUM>.

The video adapter <NUM> and the I/O interface <NUM> provide interfaces to couple external input and output devices to the processing unit <NUM>. As illustrated, examples of input and output devices include a display <NUM> coupled to the video adapter <NUM> and a mouse, keyboard, or printer <NUM> coupled to the I/O interface <NUM>. Other devices may be coupled to the processing unit <NUM>, and additional or fewer interface cards may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device.

The processing unit <NUM> also includes one or more network interfaces <NUM>, which may comprise wired links, such as an Ethernet cable, or wireless links to access nodes or different networks. The network interfaces <NUM> allow the processing unit <NUM> to communicate with remote units via the networks. For example, the network interfaces <NUM> may provide wireless communication via one or more transmitters or transmit antennas and one or more receivers or receive antennas. In an embodiment, the processing unit <NUM> is coupled to a localarea network <NUM> or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, or remote storage facilities.

In the 3GPP TSG RAN WG1 meeting #<NUM>, it has been agreed that
"The following options can be configured for new candidate beam identification.

In a situation where a SS block only is configured for new candidate beam identification, and specifically, CSI-RS is not configured for new candidate beam identification, the following are noted. <FIG> illustrates a graph <NUM> of an example of four BRACH opportunities in the time domain, corresponding to four different SS indexes respectively as illustrated in a bottom row of graph <NUM>. Specifically, if a UE detects SS index <NUM> as the new identified beam, it should transmit a BRACH preamble on BRACH resource index <NUM>, and so on and so forth. It is noted that a BRACH resource can be either FDMed (using different frequencies, for example) or CDMed (using different cyclic shifts, for example) with existing BRACH resources.

At the receiving side of a BRACH transmission, an access node monitors all BRACH resources for potential BFRQs. In detecting a valid UE-specific preamble, the access node is able to identify the UE identity. On the other hand, in detecting where the UE-specific preamble is received, the access node is able to identify the desired SS index from this particular UE. For example, if a UE-specific preamble is received during BRACH <NUM>, the access node should interpret SS index <NUM> as the desired SS index from this particular UE.

As such, a two-step RACH procedure can be used. In the first step, a UE identifies a proper SS index, and selects a proper BRACH resource index accordingly in transmitting the UE-specific preamble. At the other side, an access node detects the BRACH preamble and infers the UE identity, and then detects the desired SS index by analyzing the location where the UE-specific preamble is received. In the second step, the access node sends out a BFRP to the UE. UE monitors a search space and can receive the BFRP successfully in general.

It is noted that such a two-step RACH procedure allows UE reporting of the beam failure event as well as new beam identification per SS. In some cases, e.g., if a beam quality such as RSRP or RSRQ is desired or if a beam refinement or management operation is desired, the access node can include an uplink transmission grant in the BFRP together with a beam quality report request, or kickoff a beam refinement procedure. Upon receiving the BFRP and the included uplink grant, the UE may send the requested beam quality as allowed by the uplink grant. If no further beam quality report or beam refinement is signaled in the BFRP, the UE may declare a successful beam failure recovery and refrain from further request for this beam failure event.

It is proposed that for beam failure recovery with SS-block-only as the new beam identification reference signal, a two-step RACH procedure is used to enable the UE to signal the UE identity and desired SS index, while the access node can include in the beam failure recovery response an indication (or information) to initiate a further beam quality report or kickoff a beam refinement.

In 3GPP RAN1 meeting #<NUM>, the following has been agreed to as a working assumption:
For beam failure recovery request transmission on BRACH, support using the resource that is CDM with other BRACH resources.

In the scenario where beam failure recovery request transmission is CDMed with other BRACH resources, there may be a need to consider the transmit power of BFRQ. Because the BFRQ transmission shares the same physical resource with BRACH, a natural way is to reuse the power control mechanism of regular random access transmission (e.g., based on power ramping-up). However, because beam failure recovery is an exception handling procedure and needs to be done as quickly as possible, multiple retransmissions with small power ramping-up step sizes may result in unnecessary radio link failure in certain cases. For this reason, even though the same power control mechanism is adopted, it is necessary to use different parameter values for BFRQ transmission.

It is proposed that the same power control mechanism for beam failure recovery request as for regular random access transmission is used, but with different power control parameters.

Similar power control mechanisms may be used when SS-block-only or CSI-RS-only are used for new beam identification reference signal.

In a situation where CSI-RS only is configured for new candidate beam identification, and specifically, SS is not configured for new candidate beam identification, the following are noted. <FIG> illustrates a graph <NUM> of an example of multiple BRACH opportunities, consisting of <NUM> BRACH resources (such as BRACH resources <NUM>, <NUM>, <NUM>, and <NUM>) across four BRACH time opportunities, such as BRACH time opportunity <NUM>. Herein each BRACH time opportunity is the smallest opportunity in the time domain for a UE to send beam failure recovery request preamble, where each BRACH resource is a smallest unit in the time, frequency and sequence domain that can be used by a UE to send a preamble sequence to trigger beam failure recovery. One BRACH resource may differentiate from another BRACH resource in the choice of either BRACH time opportunity, frequency index, cyclic shift or a combination of them. In the above example, a first <NUM> BRACH resources spanning four different frequency indexes and four different cyclic shifts fall into the first BRACH time opportunity, which holds a beam correspondence relationship with SS index <NUM>; a second <NUM> BRACH resources spanning four different frequency indexes and four different cyclic shifts fall into the BRACH time opportunity as BRACH index <NUM>, which holds a beam correspondence relationship with SS index <NUM>; and so on and so forth. UE measures multiple CSI-RSs, identifies a proper CRI for new candidate beam, and is ready to trigger beam failure recovery and reports a new beam index for beam failure recovery.

For beam failure recovery purpose, the following two-step RACH procedure and four-step RACH procedure from several different aspects are compared. As beam failure recovery is an exception handling procedure where fast response is critical, beam failure recovery time may be the most important aspect. In general, two-step RACH procedure requires shorter time compared to four-step RACH procedure, mainly because it has less number of message exchanges involved.

In terms of message robustness, the two-step RACH procedure generally enjoys lower error probability for several reasons. Firstly, as two-step RACH procedure has less number of message exchanges, the probability of detection or demodulation error occurrence is lower. Secondly, as BRACH reuses BRACH preamble whose sequence design is targeted for initial access, its receive performance is more robust than that of regular PUCCH or PUSCHs. Therefore, the chance of error occurring on message <NUM> transmission is higher than that on BRACH preamble transmission.

In terms of resource overhead, the two-step RACH procedure and the four-step RACH procedure have their own pros and cons. If the number of UEs in a cell is small and the number of BRACH resources needed may be supported in one BRACH region, the two-step RACH procedure gives the minimum overhead. However, as the number of UEs increases and the number of BRACH resources needed cannot be supported within one BRACH region, and thus, more than one BRACH region needs to be assigned, its overhead can be increased. However, for the four-step RACH procedure, because a message <NUM> or <NUM> exchange is needed, it requires additional resources as a baseline.

In terms of information delivery, the two-step RACH procedure can only deliver UE index and new beam index. Furthermore, to acquire additional information such as beam quality information (e.g., RSRP or RSRQ), an access node needs to initiate separate beam management or refinement procedure as a follow-up. However, because the four-step RACH procedure can have an additional message <NUM> or <NUM> exchange, it can deliver not only UE index and new beam index, but also additional information such as beam quality information (e.g., RSRP or RSRQ). But, a complete sweeping of TX beam or RX beam may not be available for beam failure recovery procedure, hence additional beam management or refinement procedure may also be needed after finishing the beam failure recovery procedure even for four-step RACH procedure.

Furthermore, it is may be preferable to have a unified design between SS-block-only scenario and CSI-RS-only scenario. As is discussed in the previous subsection, the two-step RACH procedure is sufficient for SS-block-only scenario. Thus, if a similar two-step RACH procedure is used for CSI-RS-only scenario, it will make the overall beam failure recovery procedure more harmonized and cleaner.

Therefore, it is proposed that for beam failure recovery with CSI-RS-only as the new beam identification reference signal, support to use a two-step RACH procedure to expedite the overall beam failure recovery is provided.

It is noted that similar to the discussion earlier for SS-block-only scenario, such a two-step RACH procedure may not supply the access node with beam quality info such as RSRP or RSRQ. In case this is desired or if a beam refinement or management follow-up is desired, the access node may include an uplink transmission grant in the BFRP together with a beam quality report request, or kickoff a beam refinement procedure. Upon receiving the BFRP and the included uplink grant, the UE may send the requested beam quality as allowed by the uplink grant. If no further beam quality report or beam refinement is signaled in the BFRP, the UE may declare a successful beam failure recovery and refrain from further request for this beam failure event.

Several questions may exist. A first question is what the UE should report upon detecting the CRI. Naturally, the new beam index may be a CRI as detected by the UE. On the other hand, if there is a quasi-co-located (QCLed) relationship in effect between SSs and CSI-RSs (e.g., one or more CSI-RS beams belong to a SS beam), the new beam index may be an SS index, which is QCLed with the detected CRI. A QCLed relationship is a relationship between two reference signals or data signals such that the two signals may be viewed as possessing similar characteristics. Example characteristics include carrier frequency, time offset, frequency offset, spatial precoding vectors, and so on. This is also fine because SS index can be used to rebuild downlink control channels, and has been done in the SS-block-only scenario.

A second question is how many BRACH resources, per BRACH time opportunity, may be assigned by the access node to a UE to transmit the beam failure recovery preamble. In some cases, one BRACH resource can be assigned to each UE for every BRACH time opportunity. This may be useful when the overall number of BRACH resources available is small and the overall number of users is large. Furthermore, it is possible that more than one BRACH resources can be assigned to each UE for every BRACH time opportunity. This may be useful when the overall number of BRACH resources available is large and the overall number of users is small.

Considering these questions, the following alternative solutions for beam failure recovery are possible:.

For Alternative <NUM>, when a UE experiences a beam failure and identifies a new CRI (by monitoring available CSI-RS signals, for example), the UE can find correct BRACH time opportunity corresponding to the identified CRI (by using an association table between CRIs and BRACH time opportunities, while this association may be obtained from an SS-CRI association and a SS-BRACH-time-opportunity association, for example), and send its designated BRACH preamble. However, as the access node can only identify UE ID and SS index based on received BRACH preamble at specific BRACH time opportunity, an additional message <NUM> and message <NUM> exchange is needed to find out specific new beam index after the access node sends back response to the BRACH preamble (four-step RACH procedure). More details are presented in co-assigned <CIT>, and <CIT>.

For Alternative <NUM>, when a UE experiences a beam failure and identifies a new CRI (by monitoring available CSI-RS signals, for example), the UE identifies a SS block that is QCL'ed with the identified CRI (by using an association table between CRIs and SSs, for example). Then, the UE sends its designated BRACH preamble at a BRACH time opportunity corresponding to the identified SS block (by using an association, possibly one-to-one, between SS and BRACH time opportunity, for example). In this case, when the access node needs only the SS index as the new beam index, and does not need CRIs as the new beam index, and sends back a response to the BRACH preamble, it finalizes the beam failure recovery procedure (a two-step RACH procedure). This can be viewed as a special case of alternative <NUM>, with messages <NUM> and <NUM> skipped. It is noted that, similar to the SS-block-only scenario, the above two step procedure can be optionally extended to a four-step procedure, based on access node preference and signaling in the response. In an embodiment, the response includes a PDCCH or a PDSCH message from the access node to the UE. Upon detecting the PDCCH or PDSCH message, UE is able to receive a response and may conclude that the beam failure recovery procedure has completed successfully or unsuccessfully. In another embodiment, the response includes a request from the access node for further signaling. One example of such a request is that the access node may request, within this response message, the UE to further report beam quality information associated with the previous new identified beam index. Another example of such a request is that the access node may request, within this response message, the UE to participate in a downlink or uplink beam management, beam refinement, or beam tracking procedure, while the request itself may include configurations of such a beam management, beam refinement, or beam tracking procedure. Together with this request, the access node may also send a uplink grant to the UE assigning a certain uplink resources to the UE so that UE may use uplink resources to send the requested beam quality report, or to participate in the beam management, beam refinement, or beam tracking procedure (e.g., sending uplink sounding reference signals, sending downlink reference signal measurement results, and so on).

For both Alternative <NUM> and Alternative <NUM>, one BRACH preamble is assigned to a UE, which implies that a BRACH preamble represents a UE ID. But, for Alternative <NUM>, because multiple BRACH preambles are assigned to a UE, the BRACH preamble can directly represent both UE ID and new CRI of the UE. When a UE experiences a beam failure and identifies a new CRI, the UE sends a BRACH preamble corresponding to the identified CRI on BRACH time opportunity corresponding to the identified CRI. Because the BRACH preamble directly represents the identified CRI, the beam failure recovery procedure is finished when the access node sends back a response to the BRACH preamble (a two-step RACH procedure).

For all three alternatives mentioned above, to have the UE decide when or where to transmit corresponding BRACH preamble, the access node may need to configure an association between each CRI and BRACH resource. Two different options can be considered for this purpose. In the first option, the access node directly configures association between each CRI and BRACH resource. In this way, a UE can figure out which BRACH resource to use for each identified CRI (direct association). In the second option, the access node configures QCL relation between CSI-RS and SS block (e.g., one or more CSI-RS beams belong to a SS beam), and assigns different BRACH resource for each CSI-RS within a SS block (indirect association).

It is proposed that for beam failure recovery with CSI-RS only as the new beam identification reference signal, the access node be allowed to assign more than one BRACH resources per BRACH time opportunity to expedite the overall beam failure recovery. It is proposed that for beam failure recovery with CSI-RS only as the new beam identification reference signal, the UE supports reporting the SS index only (which is spatial QCLed with the detected CRI) to expedite the overall beam failure recovery. Note that the access node would need to send a signaling message to UEs conveying information about the time, frequency, or sequence configurations of BRACH resources, which are used by the UEs to transmit random access preambles to convey information about beam failure recovery to the access node.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a UE participating in a random access procedure. Operations <NUM> may be indicative of operations occurring in a UE as the UE participates in a random access procedure.

Operations <NUM> begin with the UE sending a preamble (block <NUM>). The UE receives a response responsive to the preamble (block <NUM>). The response may include a further signaling indicator. The further signaling indicator may be data or information, for example. The further signaling indicator may convey information to the UE to report beam quality information associated with a beam index corresponding to the preamble. The further signaling indicator may convey information to the UE to participate in at least one of a downlink beam management procedure, an uplink beam management procedure, a beam refinement procedure, or a beam tracking procedure. The response may include an uplink resource grant. The UE may send the further signaling in accordance with the uplink resource grant. The UE sends the further signaling (block <NUM>).

<FIG> illustrates a flow diagram of example operations <NUM> occurring in an access node participating in a random access procedure. Operations <NUM> may be indicative of operations occurring at an access node as the access node participates in a random access procedure.

Operations <NUM> begin with the access node receiving a preamble (block <NUM>). The access node sends a response responsive to the preamble (block <NUM>). The response may include a further signaling indicator. The further signaling indicator may be data or information, for example. The further signaling indicator may convey information to the UE to report beam quality information associated with a beam index corresponding to the preamble. The further signaling indicator may convey information to the UE to participate in at least one of a downlink beam management procedure, an uplink beam management procedure, a beam refinement procedure, or a beam tracking procedure. The response may include an uplink resource grant. The access node may receive the further signaling in accordance with the uplink resource grant. The access node receives the further signaling (block <NUM>).

It is noted that beaming or beamforming is indispensable in <NUM> mmWave communications systems.

Claim 1:
A computer implemented method for operating a user equipment, UE (<NUM>), the method comprising:
detecting, by the UE (<NUM>), that a first request type of a first request is not a beam failure recovery request, BFRQ, wherein the first request is a handover request type, and based thereon:
selecting, by the UE (<NUM>), a first random access resource for transmitting the first request, wherein the first random access resource is selected from a first subset of one or more random access resources, and wherein the one or more random access resources in the first subset are associated with a communications beam serving the UE (<NUM>), and
transmitting, by the UE (<NUM>) to an access node (<NUM>), the first request in the first random access resource; and
detecting, by the UE (<NUM>), that a second request type of a second request is a BFRQ, and based thereon,
selecting, by the UE (<NUM>), a second random access resource for transmitting the second request, wherein the second random access resource is selected from a second subset of one or more random access resources, and wherein the one or more random access resources in the second subset are unassociated with the communications beam serving the UE (<NUM>), and
transmitting, by the UE (<NUM>) to the access node (<NUM>), the second request in the second random access resource,
wherein the BFRQ includes at least a beam recovery random access channel, BRACH, preamble; and a location of the preamble in the time, frequency, or sequence domain coveys information about an identity of a candidate beam that is detected by the UE (<NUM>) in accordance with measurements of reference signals transmitted by the access node (<NUM>) on different beams of the access node (<NUM>).