Resource allocation for beam fault recovery procedures

Abstract

To facilitate the initiation of a beam failure recovery procedure.SOLUTION: In a mobile communication system, mobile terminal UE includes a transceiver that receives a configuration of physical random access channel (PRACH) resources for transmitting a beam failure recovery signal, and a processor that detects a downlink beam failure event and initiates a beam failure recovery procedure in response thereto. The beam failure recovery procedure causes the transceiver to transmit the beam failure recovery signal using the PRACH resources. The configuration includes a timer indicating a time period during which the PRACH resources are valid and an indicator indicating the number of PRACH resources in a subset of a plurality of PRACH resources. The transceiver restricts the PRACH resources used for transmission to the subset of the plurality of PRACH resources allocated to the communication device by a base station gNB based on the indicator, and when the timer expires, the PRACH resources become unavailable.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates to uplink resource allocation for a mobile terminal to transmit a beam failure recovery signal in response to detecting a downlink beam failure event while communicating with a base station in a mobile communication system.

Background Art

[0002] Currently, the 3rd Generation Partnership Project (3GPP (registered trademark)) is focusing on the next release (Release 15) of the technical specifications regarding the next-generation cellular technology, also known as the 5th Generation (5G).

[0003] At the 3GPP Technical Specification Group (TSG) Radio Access Network (RAN) meeting #71 (Joteborg, March 2016), the first 5G study item, "Study on New Radio Access Technology," including RAN1, RAN2, RAN3, and RAN4, was approved, which is expected to become a Release 15 work item (WI) defining the first 5G standard.

[0004] One of the objectives of 5G New Radio (NR) is to provide a single technical framework that addresses all usage scenarios, requirements, and deployment scenarios defined in Non-Patent Document 1 (available at www.3gpp.org and incorporated herein by reference in its entirety), including at least enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine type communication (mMTC).

[0005] For example, eMBB deployment scenarios may include indoor hotspots, densely populated cities, suburbs, urban areas, and high-speed areas. URLLC deployment scenarios may include industrial control systems, mobile healthcare (remote monitoring, diagnosis, and treatment), real-time vehicle control, and wide-area monitoring and control systems for smart grids. mMTC may include scenarios involving numerous devices using non-time-critical data transfer, such as smart wearables and sensor networks.

[0006] Another objective is forward compatibility, anticipating future use cases / deployment scenarios. Backward compatibility with Long Term Evolution (LTE) is not required, which facilitates entirely new system designs and / or the introduction of new features.

[0007] As summarized in one of the technical reports on NR considerations (Non-Patent Document 2), the basic physical layer signal waveform will be based on orthogonal frequency division multiplexing (OFDM). Cyclic prefix-based OFDM (CP-OFDM) waveforms will be supported for both downlink and uplink. For eMBB uplinks up to at least 40 GHz, discrete Fourier transform (DFT) spread OFDM (DFT-S-OFDM) based waveforms will also be supported as a supplement to the CP-OFDM waveforms.

[0008] As summarized in another technical report on NR considerations (Non-Patent Literature 3), the multi-antenna system relies on a set of beam management procedures. These procedures allow the transmit / receive point (TRP) and / or UE to acquire and maintain a set of beams available for DL ​​and UL transmit / receive, including beam determination, beam measurement, beam reporting, and beam sweeping.

[0009] One of the design targets in NR is to utilize basic physical layer signal waveforms in communications while increasing coverage by base stations that support single-user and multi-user MIMO on both downlink and uplink. To this end, at the 3GPP TSG RAN1 WG1 meeting #89 (Hangzhou, People's Republic of China, May 15-19, 2017), it was agreed to adopt a beam management procedure that includes a beam fault recovery mechanism in the event of a beam fault being detected. This mechanism is separate from the radio link fault procedure at higher layers.

[0010] The term "downlink" refers to communication from a higher-level node to a lower-level node (e.g., from a base station to a relay node or UE, from a relay node to a UE, etc.). The term "uplink" refers to communication from a lower-level node to a higher-level node (e.g., from a UE to a relay node or base station, from a relay node to a base station, etc.). The term "sidelink" refers to communication between nodes at the same level (e.g., between two EUs, or between two relay nodes, or between two base stations). [Prior art documents] [Non-patent literature]

[0011] [Non-Patent Document 1] 3GPP TSG RAN TR 38.913 v14.1.0, "Study on Scenarios and Requirements for Next Generation Access Technologies", Dec. 2016 [Non-Patent Document 2] 3GPP TSG TR 38.801 v2.0.0, "Study on New Radio Access Technology; Radio Access Architecture and Interfaces", March 2017 [Non-Patent Document 3] 3GPP TSG TR 38.802 V2.0.0, "Study on New Radio (NR) Access Technology; Physical Layer Aspects" [Overview of the Initiative] [Problems that the invention aims to solve]

[0012] One non-limiting, exemplary embodiment facilitates the initiation of a beam fault recovery procedure in a robust manner, i.e., by more efficiently (context-dependently) utilizing individual uplink radio resources. [Means for solving the problem]

[0013] In one general embodiment, the techniques disclosed herein feature a mobile terminal for communicating with a base station in a mobile communications system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each of which has different directivity and / or coverage. The mobile terminal comprises, in operation, a transceiver that receives an allocation of a separate uplink radio resource for transmitting a beam fault recovery signal for a beam fault recovery (BFR) procedure, and, in operation, a processor that detects a downlink beam fault event and initiates a beam fault recovery procedure in response thereto, the beam fault recovery procedure comprising the transceiver transmitting a beam fault recovery signal using the separate uplink radio resource from which it has been allocated. The separate uplink radio resource restricts transmission to a subset of a plurality of uplink beams that can be exclusively allocated to the mobile terminal by the base station.

[0014] It should be noted that general or specific embodiments may be implemented as systems, methods, integrated circuits, computer programs, storage media, or any selective combination thereof.

[0015] Additional benefits and advantages of the disclosed embodiments will be apparent from the specification and the drawings. These benefits and / or advantages may be obtained individually by various embodiments and features of the specification and the drawings, and not all embodiments and features need to be provided to obtain one or more of such benefits and / or advantages.

Brief Description of the Drawings

[0016] [Figure 1] It is a block diagram showing the structures of a mobile terminal and a base station. [Figure 2] It is a schematic diagram illustrating the start of a beam failure recovery procedure in the context of a 4-step beam failure recovery procedure in a general deployment scenario. [Figure 3] It is a schematic diagram illustrating the start of a beam failure recovery procedure in the context of a 4-step beam failure recovery procedure in a 3GPP NR deployment scenario. [Figure 4] It is a schematic diagram illustrating the start of a beam failure recovery procedure in the context of a 2-step beam failure recovery procedure in a 3GPP NR deployment scenario. [Figure 5] It is a diagram schematically illustrating individual uplink radio resources in a physical random access channel (PRACH) for the start of a beam failure recovery procedure. [Figure 6] It is a diagram schematically illustrating individual uplink radio resources in a physical uplink control channel (PUCCH) for the start of a beam failure recovery procedure. [Figure 7a] It is a schematic diagram illustrating the main causes of downlink beam failure in a 3GPP NR deployment scenario. [Figure 7b] It is a schematic diagram illustrating the main causes of downlink beam failure in a 3GPP NR deployment scenario.

Modes for Carrying Out the Invention

[0017] In another general embodiment, the technique disclosed herein features a separate mobile terminal for communicating with a base station in a mobile communications system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each of which has a different directivity. The mobile terminal comprises, in operation, a transceiver that receives an allocation of a separate uplink radio resource for transmitting a beam fault recovery signal for a beam fault recovery (BFR) procedure, and, in operation, a processor that detects a downlink beam fault event and initiates a beam fault recovery procedure in response thereto, the beam fault recovery procedure comprising the transceiver transmitting a beam fault recovery signal using the allocated separate uplink radio resource. The separate uplink radio resource restricts the transmission to a subset of a plurality of uplink beams that can be non-exclusively allocated to the mobile terminal by the base station.

[0018] In yet another common embodiment, the techniques disclosed herein feature a method for initiating a beam fault recovery procedure performed by a mobile terminal configured to communicate with a base station in a mobile communications system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each having different directivity and / or coverage. The method includes the steps of receiving an allocation of a separate uplink radio resource for transmitting a beam fault recovery signal for a beam fault recovery (BFR) procedure, and detecting a downlink beam fault event and initiating a beam fault recovery procedure in response thereto, the beam fault recovery procedure including transmitting a beam fault recovery signal using the separate uplink radio resource from the allocation. The separate uplink radio resource restricts the transmission to a subset of a plurality of uplink beams that can be exclusively allocated to the mobile terminal by the base station.

[0019] In yet another general aspect, the techniques disclosed herein feature another method for initiating a beam failure recovery procedure, which is implemented by a mobile terminal configured to communicate with a base station using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, wherein each of the uplink beam and the downlink beam has a different directivity. The method includes receiving an allocation of individual uplink radio resources for a beam failure recovery signal for a beam failure recovery (BFR) procedure, and detecting a downlink beam failure event and in response initiating the beam failure recovery procedure, the beam failure recovery procedure including transmitting a beam failure recovery signal using the allocated individual uplink radio resources. The individual uplink radio resources restrict transmission to a subset of a plurality of uplink beams that can be non-exclusively allocated to the mobile terminal by the base station.

[0020] As identified in TR38.913, the various use cases / deployment scenarios for NR have various requirements in terms of data rate, latency, and coverage. With these requirements in mind, NR should aim for even higher coverage compared to LTE.

[0021] In 3GPP RAN1#85, beam-based transmission was extensively discussed with respect to noise reduction (NR) as a critical technique for ensuring coverage. Regarding beam management, it was agreed that both in-TRP and inter-TRP beamforming procedures should be considered, with and without TRP beamforming / beam sweeping, and with and without UE beamforming / beam sweeping, according to the following potential use cases: UE movement, UE rotation, and beam blocking (beam change in TRP and the same beam in UE, the same beam in TRP and beam change in UE, or beam change in TRP and beam change in UE), but other cases are not excluded. Furthermore, it was agreed to consider beam (e.g., TRP beam and / or UE beam) management procedures (e.g., beam determination and modification procedures), with and without pre-acquired beam information, i.e., procedures for both data and control transmission / reception. The procedures may or may not be the same for data and control.

[0022] Subsequently, RAN1#88 reached the following agreement: A beam failure event occurs when the quality of the beam pair links of the associated control channel deteriorates sufficiently (e.g., comparison with a threshold, expiration of the associated timer). When a beam failure occurs, a mechanism for recovering from the beam failure is triggered. Note: Beam pair links are used for convenience and may or may not be used in the specification. The following matters remain under further study (FFS): whether the quality of beam pair links associated with NR-PDSCHs can be additionally included in quality; when multiple Y beam pair links are configured, a beam failure may be declared if X (≤Y) of the Y beam pair links meet the beam failure condition by falling below a certain threshold; the search space for the associated NR-PDCCH (UE specific vs. common); and what the signaling mechanism for NR-PDCCHs is when the UE is configured to monitor multiple beam pair links for NR-PDCCHs. Furthermore, the precise definition of such thresholds is FFS, and other conditions for triggering such mechanisms are not excluded.

[0023] It was also agreed that the following signals could be configured for the UE to detect beam faults and to identify new potential beams, although references to these signals remain in the FFS. The signals are, for example, RS for beam management, RS for fine timing / frequency tracking, SS block, DM-RS for PDCCH (including group common PDCCH and / or UE-specific PDCCH), and DM-RS for PDSCH. Whether the UE provides an indicator to L3 if a beam fault event occurs and no new potential beam is detected by the UE in the serving cell, and whether this indicator links to a radio link fault event, remains in the FFS. Note: The criteria for declaring a radio link fault are determined by RAN2. The need for such an indicator is also in the FFS. NR supports configuring resources to send recovery-oriented requests in symbols containing RACH and / or FFS scheduling requests, or in other indicated symbols.

[0024] Subsequently, in RAN1#88Bis, it was agreed that the UE beam fault recovery mechanism would include the following aspects: beam fault detection, identification of new candidate beams, and transmission of beam fault recovery requests, with the UE monitoring the gNB's response to the beam fault recovery requests. In beam fault detection, the UE monitors the beam fault detection RS to evaluate whether the beam fault trigger conditions have been met. The beam fault detection RS would include at least a periodic CSI-RS for beam management, and if sounding signal SS-blocks are also used in beam management, SS-blocks within the serving cell may be considered. However, the specific trigger conditions for declaring a beam fault are left to the FFS.

[0025] Regarding the identification of new candidate beams, it was also agreed that the UE would monitor the beam identification RS to find new candidate beams. The beam identification RS, if composed by the NW, would include a periodic CSI-RS for beam management, and / or, if SS-blocks are also used in beam management, it would include a periodic CSI-RS and SS-blocks in the serving cell.

[0026] Regarding the transmission of beam fault recovery requests, it was agreed that the information carried by the beam fault recovery request would include at least one of the following: explicit / implicit information regarding the identification of the UE and new gNB TX beam information, and explicit / implicit information regarding the identification of the UE and whether or not a new candidate beam exists. Information indicating UE beam faults, and additional information, such as the quality of the new beam, were left as FFS. It was agreed that the selection range limitations between channels for transmitting beam fault recovery requests would include PRACH, PUCCH, and PRACH-like (e.g., preamble sequence parameters different from PRACH). The beam fault recovery request resource / signal may additionally be used for scheduling requests.

[0027] In this regard, the UE monitors the control channel search space to receive the gNB's response to beam fault recovery requests, but it is the FFS that determines whether the control channel search space may be the same as or different from the current control channel search space related to the serving BPL, and / or what further responses the UE may have if the gNB does not receive the beam fault recovery request transmission.

[0028] Thus, it can be concluded that the beam fault recovery procedure discussed above facilitates an efficient method for re-establishing the connection between the UE and the gNB (i.e., TRP) after a downlink beam fault event, i.e., a method for re-establishing the connection without having to declare a radio link fault to higher layers. However, it was recognized that this beam fault recovery procedure only works if the procedure provides a means for the UE to act quickly before a radio link fault event is triggered.

[0029] In other words, the concept of recovery after a beam failure relies on a procedure in which, after the UE detects a beam failure in the downlink beam, the UE indicates to the gNB an alternative (i.e., candidate) downlink beam that can be used to restore communication between the gNB and the UE. Thus, this procedure relies on the fact that the UE can still indicate an alternative (i.e., candidate) downlink beam to the gNB, but only for a short period of time after the downlink beam failure occurs.

[0030] Accordingly, one non-limiting exemplary embodiment of the present disclosure proposes a robust mechanism that would enable the UE to respond to a beam fault detection event by initiating a beam fault recovery procedure as quickly as possible to avoid any adverse effects resulting from the intrinsic correspondence between the downlink beam and the uplink beam.

[0031] The proposed robust mechanism can be better understood when we look at the source or cause of beam interference in communication between the gNB and UE. This understanding is generally based on the deployment scenarios of 3GPP NR, i.e., scenarios in which the concept of beams is introduced to improve directivity and / or coverage, although this is not limited to the following scenarios. This is particularly advantageous in light of the very high frequency bandwidth (millimeter waves) in which 3GPP NR is intended to operate.

[0032] As shown in Figures 7a and 7b, the gNB can be configured to communicate over multiple beams (e.g., beams #0 to #4). This is necessary for initial access by the UE. After establishing a connection between the gNB and the UE, the gNB serves the UE using a downlink on a single beam (referred to as the "downlink serving beam" or "downlink beam"). However, it should be understood that multi-beam scenarios, i.e., scenarios in which the gNB serves the UE using downlinks over two or more separate beams, for example to increase capacity, are also conceivable.

[0033] Similarly, a UE can be configured to communicate over multiple beams (e.g., beams #0 through #4). This is equally necessary for initial access by the UE. After establishing the connection, the UE sends uplink traffic to the gNB using an uplink on a single beam (referred to as the "uplink serving beam" or "uplink beam"). However, this single uplink serving beam is not necessarily the same beam on which the downlink is served. Multiple beam scenarios are also possible for uplinks, and therefore this disclosure should be interpreted as not being limited in any way.

[0034] Generally, a pair of downlink and uplink serving beams can be assumed to have characteristics suitable for downlink and uplink communication between the gNB and the UE. In many cases, it is easy to understand that there is a directional correspondence between the downlink and uplink serving beam pair, i.e., the downlink and uplink serving beam pair are beams with opposite directions and similar coverage.

[0035] In this context, it is meant that a gNB in ​​3GPP NR is configured using one or more TRPs (transmit / receive points, or Tx / Rx points), with each TRP linked to a downlink and / or uplink serving beam having a specific direction and coverage. Therefore, in a multi-beam configuration, the gNB will necessarily be configured using more than one TRP, that is, it will be configured to transmit / receive beams with different directions and / or coverage.

[0036] Returning to the source or cause of beam interference, it can be readily deduced from the figure that one of the main causes of beam interference (see Figure 7a) is an obstruction that hinders the propagation of the serving beam between the gNB and the UE and vice versa. Another major cause of beam interference (see Figure 7b) is the movement of the UE relative to the gNB, resulting in the beam propagating in an inappropriate direction.

[0037] With this understanding, however, it can be recognized that both of these main causes do not necessarily affect the downlink and uplink serving beam pair in the same way. In other words, if downlink communication is served on a beam in a direction other than the beam serving uplink communication, it is quite possible that only one of the downlink or uplink beams is affected by beam interference.

[0038] Furthermore, if the distance between the obstacle and the UE is shorter than the distance between the obstacle and the gNB, it is possible that the uplink serving beam will not be affected by beam obstruction at close range, but the downlink serving beam will be affected by beam obstruction at a greater distance.

[0039] Therefore, the need for a beam fault recovery procedure was readily apparent, specifically in situations where the downlink serving beam suffers a beam fault but the uplink serving beam remains operational. In this situation, the UE may send a beam fault recovery request indicating an alternative (i.e., candidate) downlink beam to serve to the downlink communications.

[0040] This disclosure provides a robust mechanism that enables a UE to respond to the detection of a downlink beam fault event and reduces the amount of uplink radio resources blocked (allocated) for initiating a beam fault recovery procedure. This mechanism is particularly suitable for the proposed scenario in 3GPP NR where the beam fault recovery procedure relies on contention-free physical random access channel (PRACH) resources or contention-free physical uplink control channel (PUCCH) resources.

[0041] As is evident from this scenario, using contention-free PRACH or PUCCH resources for beam fault recovery procedures has both advantages and disadvantages. Relying on contention-free resources on the uplink beam facilitates rapid access by the UE to signal to the gNB that a beam fault event has been detected on the downlink beam. However, because it is uncertain when and under what directional conditions a radio link fault will be detected, the UE must be allocated all potentially available combinations to successfully initiate the beam fault recovery procedure.

[0042] As a result of this uncertainty, each UE will block a vast amount of individual uplink radio resources, especially in the case of the proposed contention-free physical random access channel (PRACH) or contention-free physical uplink control channel (PUCCH) resources. Given the large number of UEs that will be served by each gNB, this results in a significant overhead of individual uplink radio resources that cannot be used for other purposes. Therefore, this approach is in direct conflict with existing design principles in which resources (especially scarce resources) are allocated (and thus blocked) by the gNB only when they are needed and expected to be used in the UE in the near future.

[0043] This disclosure provides a solution that mitigates these shortcomings while still enabling the initiation of a beam fault recovery procedure in a robust (reliable) manner, i.e., by utilizing individual uplink radio resources more efficiently (context-dependently).

[0044] Generally, this disclosure provides devices and methods for initiating a beam fault recovery procedure using individual uplink radio resources only for relevant constellations that are (actually) expected to be encountered when a beam fault is detected, rather than for all potentially available constellations. Since the relevant constellations may change over time, the individual uplink radio resources can be flexibly (re)allocated without incurring significant signaling overhead.

[0045] To this end, it is proposed that the gNB allocate uplink radio resources, dedicated to initiating beam fault recovery procedures, to the UE in a restrictive but efficient manner. This is done by restricting the signaling of beam fault recovery signals to only a subset of all potentially available uplink beams that can be exclusively or non-exclusively allocated to the UE by the gNB. After limiting individual uplink radio resources to a subset, for example, one, two, or three uplink beams out of a maximum of ten potentially available uplink beams, blocking these individual uplink radio resources will have far less impact on the operation of the wireless communication system.

[0046] In particular, this stands in effective contrast to alternative approaches to beam fault recovery procedures in which the beam fault recovery signal is transmitted using a full beam sweeping scheme (i.e., by continuously utilizing all potentially available uplink beams for transmitting the beam fault recovery signal). This beam sweeping would require allocating (and thus blocking) individual uplink radio resources on all potentially available uplink beams.

[0047] In addition, it is proposed to adopt an efficient mechanism for (re)allocating these individual uplink radio resources, such that the gNB ensures that only the most appropriate individual uplink radio resources are allocated to the UE. In each (actual) situation, the UE must still be able to initiate a beam fault recovery procedure upon detection of a downlink beam fault event. In this context, it may be advantageous to reduce blocking if the (re)allocation of individual uplink radio resources expires after a given time period, or if the (re)allocation of individual uplink radio resources is periodically updated.

[0048] Figure 1 illustrates a block diagram of a wireless communication system including a mobile terminal 110 and a base station 160 that communicate with each other using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams. In other words, communication between the mobile terminal 110 and the base station 160 takes place over a pair of downlink and uplink (serving) beams 150.

[0049] In the context of this disclosure, the term "beam" should be interpreted as having a specific (predetermined) directivity and / or coverage. Each uplink beam and each downlink beam have different directivity and / or coverage, as a result of which the transmitter can transmit signals to receivers located at different (spatial) positions. In other words, each uplink beam and each downlink beam have different spatial parameters (e.g., gain and / or beamwidth).

[0050] The mobile terminal 110 includes a transceiver 120, which, when operating, receives an allocation of a separate uplink radio resource from the base station 160 for sending a beam fault recovery signal for a beam fault recovery (BFR) procedure. Furthermore, the mobile terminal 110 includes a processor 130, which, when operating, detects a downlink beam fault event and initiates a beam fault recovery procedure in response. The beam fault recovery procedure includes the transceiver 120 transmitting a beam fault recovery signal to the base station 160 using the separate uplink radio resource from which it was allocated.

[0051] In particular, the individual uplink radio resources allocated to the mobile terminal 110 are limited to transmitting to a subset of multiple uplink beams that can be exclusively allocated by the base station 160. This ensures that only a subset, and not all, of the individual uplink radio resources are not used exclusively by another mobile terminal.

[0052] Alternatively, the individual uplink radio resources allocated to the mobile terminal 110 are restricted to transmitting to a subset of multiple uplink beams that can be non-exclusively allocated by the base station 160. This ensures that, again, only a subset, not all, of the individual uplink radio resources are not used non-exclusively by another mobile terminal.

[0053] In the context of this disclosure, a distinction is made between exclusive and non-exclusive allocation of individual uplink radio resources on an uplink beam. Exclusive allocation should be interpreted as meaning that the same individual uplink radio resources, including the same uplink beam, cannot be allocated to any other mobile terminal over the same period of time. In contrast, non-exclusive allocation should be interpreted as meaning that the same individual uplink radio resources, including the same uplink beam, may be allocated to other mobile terminals over the same period of time.

[0054] The base station 160 includes a transceiver 170, which, when in operation, transmits to the mobile terminal 110 an allocation of individual uplink radio resources for the mobile terminal 110 to send beam fault recovery signals for the beam fault recovery (BFR) procedure. Furthermore, the base station 160 includes a processor 180, which, when in operation, performs the beam fault recovery procedure in response to receiving beam fault recovery signals from the mobile terminal 110 using the individual uplink radio resources allocated by the transceiver 170.

[0055] In particular, here again, the individual uplink radio resources allocated by the base station 160 are limited to transmitting to a subset of multiple uplink beams that can be exclusively allocated to the mobile terminal 110. This ensures that only a subset, and not all, of the individual uplink radio resources are not used exclusively by another mobile terminal.

[0056] Alternatively, the individual uplink radio resources allocated by the base station 160 are restricted to transmitting to a subset of multiple uplink beams that can be non-exclusively allocated to the mobile terminal 110. This, again, ensures that only a subset, and not all, of the individual uplink radio resources are not used non-exclusively by another mobile terminal.

[0057] The initiation of the beam fault recovery procedure, particularly the allocation of individual uplink radio resources, will be described in more detail with respect to Figure 2. In particular, this figure represents the present disclosure in the context of an exemplary four-step beam fault recovery procedure. Above all, this disclosure should be construed as being without limitation in any respect.

[0058] In Figure 2, a mobile terminal 110 (also referred to as a UE) and a base station 160 (also referred to as a gNB) communicate in a wireless communication network using a pair of downlink and uplink (serving) beams 150. Specifically, the downlink beam and uplink beam pair consists of one of several downlink beams and one of several uplink beams that can be configured by the base station 160 within the mobile terminal 110.

[0059] For the beam fault recovery procedure, a separate uplink radio resource is allocated to the mobile terminal 110 by the base station 160 (Figure 2 S01). As previously mentioned, these uplink radio resource allocations are dedicated to use in conjunction with beam fault recovery signaling. In other words, by dedicating the uplink radio resources in this way, it is possible to prevent the uplink radio resources from being used in different contexts. In either case, by dedicating the uplink radio resources, the base station 160 can identify (recognize) and initiate the relevant function (i.e., initiate the beam fault recovery procedure) when it receives beam fault recovery signaling on the separate uplink radio resource.

[0060] In addition, the allocation of individual uplink radio resources may include an instruction from base station 160 instructing mobile terminal 110 to include its identification information (e.g., a radio network terminal identifier (RNTI)) in subsequent messages of the beam fault recovery procedure for the purpose of beam fault recovery procedures. This may be particularly advantageous when individual uplink radio resources are allocated to mobile terminal 110 non-exclusively rather than exclusively, which will be discussed further later.

[0061] Subsequently, the mobile terminal 110 detects a downlink (also called DL) beam fault event, that is, a beam fault in the downlink (serving) beam of the beam pair 150 through which the base station 160 and the mobile terminal 110 communicate with each other. The two main causes of beam faults, namely obstacles and UE movement, have already been discussed above.

[0062] Furthermore, there are many ways for the mobile terminal 110 to detect a beam fault event for the downlink (serving) beam, for example, by measuring the reference signal received power RSRP or reference signal received quality RSRQ on this (serving) downlink beam and determining that the measured value falls below a given threshold. Another way for the mobile terminal 110 to detect a beam fault event for the downlink (serving) beam may include the passage of a given (countdown) timer, that is, when no periodic control data and / or user data is received within the time period defined by a given (countdown) timer.

[0063] In this regard, beam interference events can be understood as events that can be detected in the mobile terminal 110 either directly (i.e., by measurement) or indirectly (i.e., by the passage of a timer).

[0064] In response to the detection of a downlink beam fault event, the mobile terminal 110 transmits a beam fault recovery signal to the base station 160 (Figure 2 S02). In particular, the beam fault recovery signal uses the allocated individual uplink radio resources described above. As already mentioned earlier, the use of individual uplink radio resources allows the base station 160 to immediately identify (recognize) and initiate the relevant function (i.e., initiate the beam fault recovery procedure).

[0065] If the number of uplink beams is greater than the number of uplink beams that form the subset used when the fault recovery signal is transmitted, the mobile terminal 110 may transmit this signal using a beam sweeping method. However, this is more efficient than transmitting a beam fault recovery signal using a full (not partial) beam sweeping method, due to the limitation to a subset of all possible uplink beams.

[0066] Most importantly, the allocation of individual uplink radio resources restricts transmission to a subset of potentially available uplink beams. This restriction to a subset of uplink beams is enforced regardless of whether the individual uplink radio resource is allocated exclusively or non-exclusively to the mobile terminal 110 by the base station 160. The individual uplink radio resource may be limited to a subset, for example, one, two, or three uplink beams from a subset of potentially available uplink beams, such as up to 10.

[0067] However, after receiving the beam fault recovery signal, this does not (yet) enable the base station 160 to complete the beam fault recovery procedure for the downlink beam for which the mobile beam fault was detected by the terminal 110. As discussed earlier, the beam fault recovery procedure also includes sending a message that allows the mobile terminal 110 to explicitly or implicitly indicate to the base station 160 an alternative (candidate) downlink beam that can be used to recover from the beam fault.

[0068] For this purpose, base station 160 transmits a beam fault recovery control signal to mobile terminal 110 (Figure 2 S03). This control signal most likely includes an uplink grant that enables mobile terminal 110 to transmit an alternative (candidate) downlink beam. However, this control signal is not limited to an uplink grant.

[0069] In addition, this control signal may also include an instruction from the base station 160 instructing the mobile terminal 110 to include its identification (e.g., a radio network terminal identifier (RNTI)) in subsequent messages of the beam fault recovery procedure for the purpose of the beam fault recovery procedure. This may be particularly advantageous when individual uplink radio resources are allocated to the mobile terminal 110 non-exclusively rather than exclusively, which will be discussed further later.

[0070] The mobile terminal 110, referring to the received uplink grant, transmits a beam fault recovery request to the base station 160 (Figure 2, S04). This request includes at least one of the following: explicit or implicit information regarding the identification of the mobile terminal 110 and new downlink beam candidate information for the base station 160, and explicit or implicit information regarding the identification of the mobile terminal 110 and whether or not a new downlink beam candidate exists.

[0071] Using this information, base station 170 can recover from a beam fault on the downlink beam. That is, this can be done, for example, by returning to one of the explicitly or implicitly indicated new downlink beam candidate information. This information about new downlink candidate beams can be obtained, for example, from downlink reference signals continuously transmitted by base station 160 over all potentially available downlink beams. Mobile terminal 110 can identify new downlink beam candidates by measuring these downlink reference signals.

[0072] In response to a beam fault recovery request, base station 160 transmits a beam fault recovery response to mobile terminal 110 (Figure 2, S05). This response is a response to a beam fault recovery request previously transmitted by mobile terminal 110. In particular, only after receiving this response by mobile terminal 110 does mobile terminal 110 know that information indicating a new downlink beam candidate has been successfully received and implemented.

[0073] In particular, successful beam fault recovery is possible even when a beam fault recovery request transmitted from the mobile terminal 110 to the base station 160 170 does not include any new downlink beam candidate information for the base station 160 (instead, the request includes information that no new downlink beam candidates exist). In this case, the new downlink (serving) beam is determined by the base station 160 170 itself.

[0074] In particular, if the mobile terminal 110 does not propose any new downlink beam candidates, the base station 160 may instead decide which downlink beam to restore its communication with the mobile terminal 110 to. For this purpose, the base station may refer to a report on the measured values ​​of the downlink reference signal (e.g., CSI-RS in 3GPP NR terminology) obtained (previously) from the mobile terminal 110.

[0075] Once base station 160 has determined a new downlink beam, it must also notify mobile station 110 of the new downlink beam. Only then can both base station 160 and mobile terminal 110 revert to the same new pair of the new downlink (serving) beam and the current uplink (serving) beam. Therefore, after determining a new downlink beam, base station 160 also includes information about this new downlink beam in its beam fault recovery response to mobile terminal 110.

[0076] For example, a beam fault recovery response from base station 160 may mark the point at which mobile terminal 110 switches communication to a new beam pair containing a new downlink beam as a new downlink (serving) beam. In yet another example, if there is no beam fault response from base station 160 within a given time period, mobile terminal 110 will determine that the beam fault recovery procedure was unsuccessful and will therefore signal a radio link failure event to the higher layer.

[0077] In summary, a description of the four-step beam fault recovery procedure is provided in relation to Figure 2. That is, steps S02, S03, S04, and S05 in the figure resemble the four individual steps of the procedure. In other words, step S01 in the figure is of a more preparatory nature and is not considered part of the four-step beam fault recovery procedure in this sense.

[0078] Regardless of this complete presentation of the beam fault recovery procedure, it should be reiterated that this disclosure focuses on proposing a robust and efficient mechanism for initiating (but not terminating) the beam fault recovery procedure. Because of this narrow focus, steps S03, S04, and S05 in the figure should be considered options for achieving this effect. Whether the procedure completes successfully or not does not make the initiation of the beam fault recovery procedure more robust or efficient and is not relevant to the focus described herein.

[0079] Exclusive and non-exclusive allocation As mentioned above, base station 160 can allocate individual uplink radio resources to mobile terminal 110 in an exclusive or non-exclusive manner. This may seem trivial, but as will become clear below, it has a significant impact on the beam fault recovery procedure.

[0080] Considering exclusive allocation, after receiving the beam fault recovery signal at S02 in Figure 2, base station 160 knows exactly which mobile terminal to send the control signal to at S03 in Figure 2. Since the individual uplink radio resource is exclusively allocated to only one mobile terminal 110, base station 160 can deduce from the individual uplink radio resource which mobile terminal 110 was using it. Therefore, base station 160 can also send the subsequent control signal 110 to this mobile terminal 110.

[0081] Considering non-exclusive allocation, base station 160, after receiving the beam fault recovery signal at S02 in Figure 2, does not know (and therefore) which mobile terminal to send the control signal to at S03 in Figure 2. For this purpose, it is proposed that base station 160 examine the context in which the beam fault recovery signal is received and attempt to infer which mobile terminal received the signal. As will soon become clear, if individual uplink radio resources are allocated even non-exclusively to only a few mobile terminals, e.g., only two mobile terminals, then it becomes easier to determine from the context which mobile terminal received the signal.

[0082] One possibility is that only a subset of all potentially available uplink beams is allocated to the base station as a separate uplink radio resource for beam fault recovery signals. For example, if one uplink beam is allocated non-exclusively as a subset to each of two mobile terminals, this subset reduces the number of mobile terminals that could potentially be the source of the signal.

[0083] However, regarding this possibility, the base station still has to predict, on a contextual basis, for example, based on the most recent beam status update, which of the reduced number of mobile terminals used the non-exclusively allocated individual uplink radio resources and (actually) transmitted beam fault recovery signals on those resources. Herein lies the understanding that the subset still allows the base station to better identify the mobile terminals that are the source of the signals.

[0084] If the base station cannot (with reasonable certainty) predict or fails to predict which mobile terminal is the source of the signal, the base station may decide to transmit the beam fault recovery control signal S02 in Figure 2 to more than one mobile terminal. In the example above, it may decide to transmit to two mobile terminals, both of which are non-exclusively allocated the same individual uplink radio resource.

[0085] In this case, as discussed earlier, it is advantageous to instruct the mobile terminal to include its identification information in the subsequent message, i.e., the beam fault recovery request (i.e., S04 in Figure 2). From this identification information included in the beam fault recovery request, the base station can infer the correct mobile terminal on which the beam fault recovery procedure should be performed. For other mobile terminals that were not correctly predicted, the base station will suspend the beam fault recovery procedure.

[0086] Another possibility is that beam fault recovery signals can be transmitted over individual uplink radio resources that themselves require additional control information to be attached. The base station can then use this attached control information to identify the mobile terminal as the source of the signal.

[0087] This is the case, for example, when a beam fault recovery signal is transmitted via a physical uplink control channel (PUCCH). The 3GPP NR specification for PUCCH stipulates that a mobile terminal not only transmits uplink control information (UCI) in a given format, but also adds a transmit demodulation reference signal DM-RS, which is uniquely assigned to each mobile terminal.

[0088] Therefore, when a base station receives a beam fault recovery signal in the UCI on PUCCH, it can identify the mobile terminal that transmitted this signal from the DM-RS. Again, context is crucial for the base station to identify the mobile terminal in order to send the subsequent beam fault recovery control signal to the correct mobile terminal in S03 of Figure 2.

[0089] Next, Figure 3 assumes a 3GPP NR deployment scenario. More specifically, this figure illustrates the start of a beam fault recovery procedure in the context of a four-step beam fault recovery procedure in which the UE and gNB communicate via a downlink beam and uplink beam pair. Here again, the downlink and uplink (serving) beam pair is one of several downlink beams and one of the uplink beam pairs that can be configured in the UE by the gNB.

[0090] For beam fault recovery procedures, individual uplink radio resources are allocated to the UE by the gNB (Figure 3, S11). As previously mentioned, the allocation of uplink radio resources is dedicated to use in conjunction with beam fault recovery signaling. For this purpose, the gNB sends a Radio Resource Configuration (RRC) connection reconfiguration message to the UE. Alternatively, an RRC connection setup message may be used for allocation purposes.

[0091] In another example, individual uplink radio resources are allocated to the UE via a Downlink Medium Access Control (MAC) control element (CE), Downlink Control Information (DCI), and a Packet Data Convergence Protocol (PDCP) control protocol data unit (PDU). In particular, PDCP control PDUs have the advantage of slightly lower overhead compared to RRC connection reconfiguration messages. Therefore, this can result in even higher signaling speeds.

[0092] Apart from allocation via a single message, allocation can also be achieved by a first message configuring an individual uplink radio resource and a second subsequent message activating the configuration. In this case, the UE receives the configuration of the individual uplink radio resource from the gNB via an RRC connection setup or reconfiguration message, and (then) receives the activation of the individual uplink radio resource from the configuration via one of the MAC CE, DCI, and PDCP control PDU.

[0093] This message may include a reference to a separate uplink radio resource of a physical random access channel (PRACH), i.e., a reference to one of the contention-free resources, preferably a contention-free preamble sequence having time and frequency references on the uplink beam.

[0094] This refers only to contention-free preamble sequences. This is because, in 3GPP NR, gNBs (actively) allocate only these types of preamble sequences to UEs. In contrast, with non-contention-free (contention-based) preamble sequences, gNBs cannot distinguish whether these sequences are being used by the UE to initiate a beam fault recovery procedure or whether a (conventional) time-matching procedure is being performed. This excludes any use of non-contention-free (contention-based) preamble sequences as separate uplink radio resources for initiating beam fault recovery procedures.

[0095] For example, assuming the configuration shown in Figure 5, the message may include a reference to PRACH having a preamble sequence index S1, a time reference T1, and a frequency reference F1 on uplink beam #1. This allocates a separate uplink radio resource to the UE that the UE can use to initiate the beam fault recovery procedure. In this example, the time reference T1 would be understood as an offset indicating a slot that is time-shifted from each radio frame boundary. In addition, the frequency reference F1 would be understood as an index of the resource block.

[0096] Alternatively, the message may also include a reference to a specific uplink radio resource of the physical uplink control channel (PUCCH), i.e., a reference to contention-free uplink control information (UCI) in a given format with time and frequency references on the uplink beam. For example, assuming the configuration shown in Figure 6, the message may include a reference to a PUCCH having a time reference T1 and a frequency reference F1 on beam #1.

[0097] In both examples, namely contention-free PRACH or PUCCH, dedicating uplink radio resources prevents them from being used in different contexts. In either case, dedicating uplink radio resources allows the gNB to identify (recognize) and initiate the relevant function (i.e., initiate the beam fault recovery procedure) when it receives beam fault recovery signaling on the individual uplink radio resource.

[0098] In response to detecting a beam fault event, the UE transmits a beam fault recovery signal to the gNB (Figure 3, S12). In particular, the beam fault recovery signal uses a pre-allocated individual uplink radio resource, i.e., contention-free PRACH or PUCCH. As already mentioned earlier, the use of an individual uplink radio resource allows the gNB to immediately identify (recognize) and initiate the relevant function (i.e., initiate the beam fault recovery procedure). In particular, the PRACH resource implicitly indicates a scheduling request (SR), while a UCI of a given format may explicitly or implicitly include an SR.

[0099] When a gNB receives an individual PRACH or PUCCH resource, it initiates a beam fault recovery procedure. As part of this procedure, the gNB transmits Physical Downlink Control Channel (PDCCH) Downlink Control Information (DCI), which includes the uplink grant (Figure 3 S13). The DCI on the PDCCH also includes a Cyclic Redundancy Check (CRC) field scrambled with the UE's Radio Network Temporary Identifier (RNTI). This allows the UE to detect whether the gNB intended the DCI for the UE to be used in the beam fault recovery procedure.

[0100] Assuming the UE has received an uplink grant, the mobile terminal 110 transmits a beam fault recovery request to the gNB in ​​the form of an uplink MAC control element (Figure 3, S14). This request includes at least one of the following: explicit or implicit information regarding the identification of the UE and new downlink beam candidate information for the gNB, and explicit or implicit information regarding the identification of the UE and whether or not a new downlink beam candidate exists.

[0101] Finally, in response to the beam fault recovery request, the gNB sends a beam fault recovery response to the UE in the form of a PDCCH DCI, including an acknowledgment (e.g., response acknowledgment) (Figure 3 S15). This response is a response to the beam fault recovery request previously sent by the UE. In particular, only upon receiving this response by the UE does the UE know that the information indicating a new downlink beam candidate has been successfully received and put into action.

[0102] Alternatively, if the mobile terminal does not propose any new downlink beam candidates, the gNB may include information about a new downlink beam in the beam fault recovery response to the UE. Depending on the number of potentially available downlink beams, this information may also be included in a response in the form of a PDCCH DCI. Then, both the gNB and the UE can revert to the same pair of new downlink (serving) beams and current uplink (serving) beams, thereby successfully completing the beam fault recovery procedure.

[0103] Next, Figure 4 assumes another 3GPP NR deployment scenario. More specifically, this figure depicts the initiation of a beam fault recovery procedure in the context of a two-step beam fault recovery procedure, where the UE and gNB communicate via a pair of downlink and uplink (serving) beams. Here again, the downlink and uplink (serving) beams are one of several downlink beams and one of a pair of uplink beams that the gNB can configure for the UE. In particular, the two-step beam fault recovery procedure is limited to individual uplink radio resources from the physical uplink control channel (PUCCH).

[0104] This procedure is very similar to the four-step beam fault recovery procedure shown in the previous figure. The transmission between the UE and gNB for the allocation of individual uplink resources (Figure 4 S21) and the transmission of the beam fault recovery response (Figure 4 S23) correspond to the respective steps in the previous procedure. Furthermore, the only difference lies in the format of the beam fault recovery signal (Figure 4 S22).

[0105] Here, it is utilized that the uplink control information (UCI) on a PUCCH, which depends on a given format, can contain a sufficient number of bits, for example, 1 or 2 bits in PUCCH format 1a / 1b, 20 encoded bits in PUCCH format 2 / 2a / 2b, and even 48 encoded bits in PUCCH format 3.

[0106] Therefore, in this example, it is proposed that the UE not only transmits a UCI of PUCCH, similar to an individual uplink radio resource, as a beam fault recovery signal to the gNB, but also carries at least one of the following: information regarding the beam fault recovery request, namely, explicit or implicit information regarding identifying the UE and information regarding a new downlink beam candidate for the gNB, and explicit or implicit information regarding identifying the UE and whether or not a new downlink beam candidate exists.

[0107] Robust allocation mechanism As previously discussed, this disclosure focuses on a robust mechanism that enables base stations to respond to the detection of downlink beam fault events and reduces the amount of uplink radio resources blocked (allocated) for initiating beam fault recovery procedures. However, reducing the amount of uplink radio resources requires, in one example, that the base station carefully selects which individual uplink radio resources are allocated.

[0108] For this purpose, the base station may determine a subset of all potentially available uplink beams based on the most recent quality and / or power measurements. In this context, it may be advantageous to refer to a reference signal signaled on either all potentially available downlink beams or uplink beams. From this, the base station can then select a subset by referring to the measured quality and / or power values.

[0109] Assuming a 3GPP NR deployment scenario, a base station may refer to all potentially available uplink reference signals, preferably sounding reference signals (SRS), transmitted by mobile terminals on the potentially available or at least most relevant uplink beams, in order to determine a subset of uplink beams.

[0110] The base station may also refer to reports (preferably channel status information (CSI) reports) made by the mobile terminal for measurements of downlink reference signals (preferably CSI-RS) transmitted by the base station over all potentially available downlink beams for this uplink beam subset determination.

[0111] Either method can ensure that a subset of uplink resources is suitable for the purpose of enabling mobile terminals to respond robustly to downlink beam fault events (i.e., without the risk of the base station being unable to receive beam fault recovery signals).

[0112] Mobility status In one exemplary implementation, the focus is on an efficient mechanism for allocating individual uplink radio resources on a subset of uplink beams. To achieve this, the base station varies the number of uplink beams that form the subset to which individual uplink radio resources are allocated to mobile terminals. In particular, by varying the number of uplink beams, the base station attempts to reflect the fluctuating (actual) circumstances at the mobile terminal (e.g., a few or many position changes).

[0113] As the above discussion shows, one of the main causes of beam faults is the mobility of mobile terminals (i.e., their fluctuating spatial location). If mobile terminals change their location at a high rate, it becomes difficult for base stations to predict which individual uplink radio resources will be most appropriate in the event of a downlink beam fault. In other words, when the location of mobile terminals changes rapidly, it becomes difficult for base stations to allocate individual uplink radio resources on a subset of uplink beams that still meet the requirements of a reliable beam fault recovery procedure.

[0114] With these difficulties in mind, this disclosure proposes that base stations maintain a mobility state for each mobile terminal. The mobility state distinguishes between a small number of location changes and a large number of location changes for each mobile terminal during a given time period. In other words, based on the mobility state, base stations can determine whether location changes for each mobile terminal occurred at a low rate or a high rate (in the past).

[0115] Next, this mobility state is used by the base station to predict the number of uplink beams in the subset, thereby ensuring a reliable beam fault recovery procedure. Thus, the number of uplink beams forming a subset of all potentially available uplink beams may be determined by the base station in accordance with the mobility state of each mobile terminal.

[0116] In one example, for a mobile terminal with a mobility state corresponding to a low rate of location change, the base station can reasonably predict that the mobile terminal's location will not change frequently in the future, and therefore it is sufficient to allocate individual uplink radio resources on a small number of uplink beams (e.g., one or two uplink beams). In a different example, for a mobile terminal with a mobility state corresponding to a high rate of location change, the base station can, conversely, reasonably predict that the mobile terminal's location will change frequently in the future, and therefore it is necessary to allocate individual uplink radio resources on a large number of uplink beams (e.g., three or more).

[0117] For example, the mobility state and therefore the rate of change of position can be determined by both the base station and the mobile terminal based on the number of reconfiguration commands (beam steering) for the downlink beam transmitted from the base station to the mobile terminal. Although the reconfiguration of the downlink beam is performed at the base station, the mobile terminal takes this into account in the form of reconfiguration commands, i.e., reconfiguration commands that instruct the mobile terminal to reconfigure its beam pair to include a new downlink beam.

[0118] As another example, the mobility state and therefore the rate of change of position can be determined based on the number of position changes, which is preferably determined from positioning measurements in the mobile terminal over a given time period and then signaled to the base station. In other words, the mobile terminal itself determines its rate of change of position by performing positioning measurements, including, for example, checking whether there is a new downlink beam, and then signals this rate of change of position to the base station.

[0119] In both cases, the mobility state facilitates the selection of enough uplink beams for the mobile terminal to respond robustly to the detection of downlink beam fault events (i.e., without the risk that the base station will not receive beam fault recovery signals).

[0120] Recentness of allocation Another exemplary implementation focuses on an efficient mechanism for allocating individual uplink radio resources on a subset of the uplink radio beam. To achieve this, each allocation of individual uplink radio resources to a mobile terminal has an expiration time. This ensures the timeliness of the individual uplink radio resource allocation, as well as that the resources are blocked only for a limited amount of time.

[0121] As is clear from the above discussion, base stations that allocate individual uplink radio resources to mobile stations are not always able to adequately cope with the fluctuating (actual) circumstances (e.g., changes in location) of the mobile terminal. An allocation on a subset of uplink beams may be effective for a mobile terminal at one location but not for the same mobile terminal after it has moved to a different location.

[0122] Therefore, this disclosure suggests that each allocation is valid only for a given (short) time period, and exceptionally, only until a new (re)allocation is received. In other words, whether a mobile station receives an exclusive or non-exclusive allocation of individual uplink resources from a base station for beam fault recovery procedures, these resources are blocked only for a limited amount of time.

[0123] This can be guaranteed by the base station 160 when it transmits an allocation to the mobile station 110 that also indicates the time period during which the individual uplink radio resource is valid (see Figure 2 S01). For example, along with the allocation of the individual uplink radio resource, both the base station and the mobile terminal can start a countdown timer. When this timer expires, both the base station and the mobile terminal know that the individual uplink radio resource is no longer available and therefore cannot be blocked any further.

[0124] However, to avoid situations where there are no allocations or only expired allocations, the mobile terminal may transmit a signal to the base station to prompt the base station to (re)initiate the allocation of individual uplink radio resources for beam fault recovery procedures.

[0125] Assuming an NR deployment scenario, the signal for (re)starting the allocation of individual uplink radio resources is either an (implicit) Channel Status Information (CSI) report signaling the quality or power of the serving downlink beam below a given threshold, or an individual transmission (preferably in the form of an RRC message or an uplink MAC CE) signaling an explicit request to (re)start the allocation of individual uplink radio resources.

[0126] In summary, the expiration of individual uplink radio resource allocations further improves the efficient use of these resources. Resource allocation expiration not only promotes the up-to-dateness that is necessary anyway for allocations to reflect the actual (current) situation of mobile stations, but also prevents resources from being blocked, which is particularly advantageous when these resources are allocated in an exclusive manner.

[0127] This disclosure can be implemented by software, hardware, or software in conjunction with hardware. Each functional block used in the descriptions of the embodiments described above can be implemented partially or entirely by an LSI, such as an integrated circuit, and each process described in each embodiment can be controlled partially or entirely by the same LSI or combination of LSIs. The LSI may be formed individually as chips, or one chip may be formed to include some or all of the functional blocks. The LSI may have data inputs and outputs coupled thereto. The LSI here may be called an IC, system LSI, super LSI, or ultra LSI depending on the degree of integration. However, the techniques for implementing the integrated circuit are not limited to LSIs and may be implemented using dedicated circuits, general-purpose processors, or dedicated processors. In addition, an FPGA (field-programmable gate array) that can be programmed after the manufacture of the LSI, or a reconfigurable processor in which the connections and settings of circuit cells located inside the LSI can be reconfigured may be used. This disclosure can be implemented as digital or analog processing. If future integrated circuit technology replaces LSIs as a result of advances in semiconductor technology or other derivative technologies, functional blocks may also be integrated using future integrated circuit technology. Biotechnology may also be applied.

[0128] According to a first embodiment, a mobile terminal is proposed for communicating with a base station in a mobile communication system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each having different directivity and / or coverage. The mobile terminal comprises, in operation, a transceiver that receives an allocation of a separate uplink radio resource for transmitting a beam fault recovery signal for a beam fault recovery (BFR) procedure, and, in operation, a processor that detects a downlink beam fault event and initiates a beam fault recovery procedure in response thereto, the beam fault recovery procedure including the transceiver transmitting a beam fault recovery signal using the separate uplink radio resource from which it has been allocated. The separate uplink radio resource restricts transmission to a subset of a plurality of uplink beams that can be exclusively allocated to the mobile terminal by the base station.

[0129] According to a second embodiment that can be combined with the first embodiment, a subset of uplink beams is exclusively allocated to a mobile terminal based on uplink reference signals (preferably sounding reference signals (SRS)) transmitted by the mobile terminal over the uplink beams, or based on reports (preferably channel status information (CSI) reports) by the mobile terminal regarding measurements of downlink reference signals (preferably CSI-RS) transmitted by the base station over the downlink beams.

[0130] According to a third embodiment which can be combined with the first or second embodiment, the number of uplink beams forming a subset of multiple uplink beams corresponds to one, two, or three uplink beams.

[0131] According to a fourth embodiment which can be combined with one of the first to third embodiments, the number of uplink beams forming a subset of multiple uplink beams corresponds to the mobility state of the mobile terminal, distinguishing between low-rate and high-rate position changes of the mobile terminal.

[0132] According to a fifth embodiment that can be combined with the fourth embodiment, the mobility state of a mobile terminal is determined based on the number of reconfiguration commands for the downlink beam transmitted to the mobile terminal by the base station over a period of time, or based on the number of positional changes that are preferably determined from positional measurements in the mobile terminal over a period of time and signaled to the base station.

[0133] According to a sixth embodiment, which can be combined with one of the first to fifth embodiments, the transceiver additionally receives, during operation, an indicator indicating the number of uplink beams in a subset of uplink beams that will be used in the beam fault recovery procedure for the beam fault recovery procedure.

[0134] According to a seventh embodiment, which can be combined with the first to sixth embodiments, an indicator indicating the number of uplink beams in a subset of uplink beams to be used is received in a radio resource configuration (RRC) message, a medium access control (MAC) control element (CE), or downlink control information (DCI).

[0135] According to the eighth aspect, another mobile terminal is proposed for communicating with a base station in a mobile communication system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each having different directivity. The mobile terminal comprises, in operation, a transceiver that receives an allocation of a separate uplink radio resource for transmitting a beam fault recovery signal for a beam fault recovery (BFR) procedure, and, in operation, a processor that detects a downlink beam fault event and initiates a beam fault recovery procedure in response thereto, the beam fault recovery procedure comprising the transceiver transmitting a beam fault recovery signal using the allocated separate uplink radio resource. The separate uplink radio resource restricts the transmission to a subset of a plurality of uplink beams that can be non-exclusively allocated to the mobile terminal by the base station.

[0136] According to a ninth aspect which can be combined with the eighth aspect, transmitting a beam fault recovery signal on an individual uplink radio resource over a subset of multiple uplink beams that are limited enables a base station to identify a mobile terminal.

[0137] According to a tenth embodiment which can be combined with the eighth or ninth embodiment, if an individual uplink radio resource includes a physical uplink control channel (PUCCH), transmitting a demodulated reference signal DM-RS along with a beam fault recovery signal in the PUCCH enables the base station to identify a mobile terminal.

[0138] According to an eleventh embodiment, which can be combined with one of the eighth to tenth embodiments, the allocation of individual uplink radio resources includes an instruction that instructs the mobile terminal to include the mobile terminal's identification information in a subsequent message of the beam fault recovery procedure.

[0139] According to a twelfth embodiment that can be combined with the first to eleventh embodiments, the individual uplink radio resource corresponds to either a contention-free resource of a physical random access channel (PRACH) (preferably a contention-free preamble sequence including time and frequency references) or a contention-free resource of a physical uplink control channel (PUCCH) (preferably uplink control information (UCI) including time and frequency references).

[0140] According to a thirteenth embodiment, which can be combined with one of the first to twelfth embodiments, the allocation of individual uplink radio resources is received via one of the following: a Radio Resource Configuration (RRC) connection reconfiguration or RRC connection setup message, a Downlink Medium Access Control (MAC) control element (CE), Downlink Control Information (DCI), and a Packet Data Convergence Protocol (PDCP) control protocol data unit (PDU).

[0141] According to a fourteenth embodiment that can be combined with one of the first to twelfth embodiments, the allocation of individual uplink radio resources includes, when the transceiver is operating, receiving the configuration of the individual uplink radio resources via an RRC connection setup or reconfiguration message, and the activation of the individual uplink radio resources from the configuration via one of MAC CE, DCI, and PDCP control PDU.

[0142] According to a 15th embodiment, which can be combined with one of the 1st to 14th embodiments, the allocation of individual uplink radio resources is valid either over a period of time or until a new allocation is received.

[0143] According to a 16th aspect which can be combined with one of the 15th aspects, the time period for which the allocation of an individual uplink resource is valid is indicated in the allocation.

[0144] According to a 17th embodiment, which can be combined with one of the 1st to 16th embodiments, the transceiver transmits a signal during operation for the base station to (re)start the allocation of individual uplink radio resources for beam fault recovery procedures.

[0145] According to an 18th aspect which can be combined with the 17th aspect, the signal for (re)starting the allocation of an individual uplink radio resource is either a channel status information (CSI) report signaling the quality or power of a serving downlink beam below a threshold, or an individual transmission (preferably in the form of an RRC message or an uplink MAC CE) signaling an explicit request to (re)start the allocation of an individual uplink radio resource.

[0146] According to the 19th aspect, a method is proposed for initiating a beam fault recovery procedure performed by a mobile terminal configured to communicate with a base station in a mobile communication system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each having different directivity and / or coverage. The method includes the steps of receiving an allocation of a separate uplink radio resource for transmitting a beam fault recovery signal for a beam fault recovery (BFR) procedure, and detecting a downlink beam fault event and initiating a beam fault recovery procedure in response thereto, the beam fault recovery procedure including transmitting a beam fault recovery signal using the separate uplink radio resource from the allocation. The separate uplink radio resource restricts the transmission to a subset of a plurality of uplink beams that can be exclusively allocated to the mobile terminal by the base station.

[0147] According to a 20th embodiment, which can be combined with the 19th embodiment, a subset of uplink beams is exclusively allocated to a mobile terminal based on uplink reference signals (preferably sounding reference signals (SRS)) transmitted by the mobile terminal over the uplink beams, or based on reports (preferably channel status information (CSI) reports) by the mobile terminal regarding measurements of downlink reference signals (preferably CSI-RS) transmitted by the base station over the downlink beams.

[0148] According to a 21st embodiment which can be combined with the 19th or 20th embodiment, the number of uplink beams forming a subset of multiple uplink beams corresponds to one, two, or three uplink beams.

[0149] According to a 22nd embodiment, which can be combined with one of the 19th to 21st embodiments, the number of uplink beams forming a subset of multiple uplink beams corresponds to the mobility state of the mobile terminal, distinguishing between low-rate and high-rate position changes of the mobile terminal.

[0150] According to a 23rd embodiment, which can be combined with one of the 19th to 22nd embodiments, the mobility state of a mobile terminal is determined based on the number of reconfiguration commands for the downlink beam transmitted to the mobile terminal by a base station over a period of time, or based on the number of positional changes over a period of time, which are preferably determined from positional measurements in the mobile terminal and signaled to the base station.

[0151] According to a 24th embodiment, which can be combined with one of the 19th to 23rd embodiments, the method includes the additional step of receiving an indicator for the beam fault recovery procedure, indicating the number of uplink beams in a subset of uplink beams that will be used in the beam fault recovery procedure.

[0152] According to a 25th embodiment, which can be combined with the 24th embodiment, an indicator indicating the number of uplink beams in a subset of uplink beams to be used is received in a Radio Resource Configuration (RRC) message, or in a Medium Access Control (MAC) control element (CE), or in Downlink Control Information (DCI).

[0153] According to the 26th aspect, an alternative method is proposed for initiating a beam fault recovery procedure, which is performed by a mobile terminal configured to communicate with a base station using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each having different directivity. The method includes the steps of receiving an allocation of individual uplink radio resources for a beam fault recovery signal for a beam fault recovery (BFR) procedure, and detecting a downlink beam fault event and initiating a beam fault recovery procedure in response thereto, the beam fault recovery procedure including transmitting a beam fault recovery signal using the allocated individual uplink radio resources. The individual uplink radio resources restrict the transmission to a subset of a plurality of uplink beams, which can be non-exclusively allocated to the mobile terminal by the base station.

[0154] According to a 27th aspect which can be combined with the 26th aspect, transmitting a beam fault recovery signal on an individual uplink radio resource over a subset of multiple uplink beams that are limited enables a base station to identify a mobile terminal.

[0155] According to a 28th embodiment, which can be combined with the 26th or 27th embodiment, if an individual uplink radio resource includes a physical uplink control channel (PUCCH), transmitting a demodulated reference signal (DM-RS) along with a beam fault recovery signal in the PUCCH enables the base station to identify a mobile terminal.

[0156] According to a 29th embodiment, which can be combined with one of the 26th to 28th embodiments, the allocation of individual uplink radio resources includes an instruction instructing a mobile terminal to include the mobile terminal's identification information in a subsequent message of the beam fault recovery procedure.

[0157] According to a 30th embodiment, which can be combined with one of the 19th to 29th embodiments, the individual uplink radio resource corresponds to either a contention-free resource of a physical uplink control channel (PUCCH) (preferably uplink control information (UCI) including time and frequency references).

[0158] According to a 31st embodiment, which can be combined with one of the 19th to 30th embodiments, the allocation of individual uplink radio resources is received via one of the following: a Radio Resource Configuration (RRC) connection reconfiguration or RRC connection setup message, a Downlink Medium Access Control (MAC) control element (CE), Downlink Control Information (DCI), and a Packet Data Convergence Protocol (PDCP) control protocol data unit (PDU).

[0159] According to a 32nd aspect which can be combined with one of the 19th to 30th aspects, the allocation of an individual uplink radio resource includes receiving the configuration of the individual uplink radio resource via an RRC connection establishment or reconfiguration message, and the activation of the individual uplink radio resource from the configuration via one of MAC CE, DCI, and PDCP control PDU.

[0160] According to a 33rd aspect which can be combined with one of the 19th to 32nd aspects, the allocation of individual uplink radio resources is valid either over a period of time or until a new allocation is received.

[0161] According to a 34th aspect which can be combined with the 33rd aspect, the time period for which the allocation of an individual uplink resource is valid is indicated in the allocation.

[0162] According to a 35th embodiment, which can be combined with one of the 19th to 34th embodiments, the method includes the step of transmitting a signal for a base station to (re)start the allocation of individual uplink radio resources for a beam fault recovery procedure.

[0163] According to a 36th aspect which can be combined with the 35th aspect, the signal for (re)starting the allocation of individual uplink radio resources is either a channel status information (CSI) report signaling the quality or power of a serving downlink beam below a threshold, or an individual transmission (preferably in the form of an RRC message or an uplink MAC CE) signaling an explicit request to (re)start the allocation of individual uplink radio resources.

[0164] According to the 37th aspect, a base station is proposed for communicating with a mobile terminal in a mobile communication system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each of which has different directivity and / or coverage. The base station comprises a processor that performs a beam fault recovery procedure when in operation, the beam fault recovery procedure including a transceiver receiving a beam fault recovery signal from the mobile terminal using an individual uplink radio resource from which it has been allocated. The individual uplink radio resource restricts transmission to a subset of the plurality of uplink beams, which can be exclusively allocated to the mobile terminal by the base station.

[0165] According to the 38th aspect, another base station is proposed for communicating with a mobile terminal in a mobile communication system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each of which has different directivity and / or coverage. The base station comprises a processor that initiates a beam fault recovery procedure when in operation, the beam fault recovery procedure including a transceiver receiving a beam fault recovery signal from the mobile terminal using individual uplink radio resources from which it has been allocated. The individual uplink radio resources restrict transmission to a subset of a plurality of uplink beams, which can be non-exclusively allocated to the mobile terminal by the base station.

[0166] According to the 39th aspect, a method is proposed for initiating a beam fault recovery procedure, which is performed by a base station configured to communicate with a mobile terminal in a mobile communication system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each having different directivity and / or coverage. The method includes the step of initiating a beam fault recovery procedure in response to receiving a beam fault recovery signal from the mobile terminal using an individual uplink radio resource from an allocation, the individual uplink radio resource restricting transmission to a subset of the plurality of uplink beams which can be exclusively allocated to the mobile terminal by the base station.

[0167] According to the 40th aspect, an alternative method is proposed for initiating a beam fault recovery procedure, which is performed by a base station configured to communicate with a mobile terminal in a mobile communication system using at least one of a plurality of downlink beams and at least one of a plurality of uplink beams, each having different directivity and / or coverage. The method includes the step of initiating a beam fault recovery procedure in response to receiving a beam fault recovery signal from the mobile terminal using an individual uplink radio resource from an allocation, the individual uplink radio resource restricting transmission to a subset of a plurality of uplink beams that can be non-exclusively allocated to the mobile terminal by the base station.

Claims

1. A communication device, A transceiver that receives the configuration of a physical random access channel (PRACH) resource for transmitting a beam fault recovery signal, The system includes a processor that detects a downlink beam fault event and, in response, initiates a beam fault recovery procedure (BFR), wherein the beam fault recovery procedure includes the transceiver using the PRACH resources to transmit the beam fault recovery signal. The configuration includes first information indicating a reference to a plurality of PRACH resources allocated exclusively to the communication device, second information indicating the number of PRACH resources in a subset of the plurality of PRACH resources, and third information indicating the time period during which the allocation of the plurality of PRACH resources is valid. The transceiver restricts the PRACH resources used for transmission to a subset of the plurality of PRACH resources based on the second information, If the aforementioned time period expires, the PRACH resource will become unusable. Communication device.

2. The above configuration remains valid until a new configuration is received. The communication device according to claim 1.

3. The number of PRACH resources forming the subset of the plurality of PRACH resources corresponds to one, two, or three PRACH resources. The communication device according to claim 1.

4. The second piece of information mentioned above is • Radio Resource Configuration (RRC) messages and • Media Access Control (MAC) control element (CE), - Downlink control information (DCI), Received in at least one of the following: The communication device according to claim 1.

5. The above configuration of the PRACH resource is - Wireless Resource Configuration (RRC) connection reconfiguration or RRC connection setup message, - Downlink media access control (MAC) control element (CE), - Downlink control information (DCI), - The Control Protocol Data Unit (PDU) of the Packet Data Convergence Protocol (PDCP), Including being received via one of the following, The communication device according to claim 1.

6. A communication device, Receive the configuration of a physical random access channel (PRACH) resource for transmitting beam fault recovery signals. The system detects downlink beam fault events and, in response, initiates a beam fault recovery procedure (BFR). The beam fault recovery procedure uses the PRACH resource to transmit the beam fault recovery signal. The configuration includes first information indicating a reference to a plurality of PRACH resources allocated exclusively to the communication device, second information indicating the number of PRACH resources in a subset of the plurality of PRACH resources, and third information indicating the time period during which the allocation of the plurality of PRACH resources is valid. The PRACH resources used for the transmission are limited to a subset of the plurality of PRACH resources based on the second information, If the aforementioned time period expires, the PRACH resource will become unusable. method.

7. A transceiver that transmits the configuration of a physical random access channel (PRACH) resource for a communication device to transmit a beam fault recovery signal, The system comprises a processor that performs a beam fault recovery procedure (BFR), wherein the beam fault recovery procedure includes the transceiver receiving the beam fault recovery signal using the PRACH resources from the communication device. The configuration includes first information indicating a reference to a plurality of PRACH resources allocated exclusively to the communication device, second information indicating the number of PRACH resources in a subset of the plurality of PRACH resources, and third information indicating the time period during which the allocation of the plurality of PRACH resources is valid. The PRACH resources are limited to the subset based on the second information of the plurality of PRACH resources, If the aforementioned time period expires, the PRACH resource will become unusable. Base station.

8. A base station, The communication device transmits the configuration of a physical random access channel (PRACH) resource for transmitting beam fault recovery signals. The Beam Fault Recovery Procedure (BFR) is performed. The beam fault recovery procedure receives the beam fault recovery signal using the PRACH resource from the communication device. The configuration includes first information indicating a reference to a plurality of PRACH resources allocated exclusively to the communication device, second information indicating the number of PRACH resources in a subset of the plurality of PRACH resources, and third information indicating the time period during which the allocation of the plurality of PRACH resources is valid. The PRACH resource is limited to the subset of the plurality of PRACH resources based on the second information, If the aforementioned time period expires, the PRACH resource will become unusable. method.

9. An integrated circuit that controls the processing of a communication device, wherein the processing is The process of receiving the configuration of a physical random access channel (PRACH) resource for transmitting a beam fault recovery signal, The process includes detecting a downlink beam fault event and initiating a beam fault recovery procedure (BFR) in response, wherein the beam fault recovery procedure includes transmitting the beam fault recovery signal using the PRACH resources. The configuration includes first information indicating a reference to a plurality of PRACH resources allocated exclusively to the communication device, second information indicating the number of PRACH resources in a subset of the plurality of PRACH resources, and third information indicating the time period during which the allocation of the plurality of PRACH resources is valid. The process includes restricting the PRACH resources used for the transmission to a subset of the plurality of PRACH resources based on the second information, If the aforementioned time period expires, the PRACH resource will become unusable. Integrated circuit.

10. An integrated circuit that controls the processing of a base station, wherein the processing is The process involves transmitting the configuration of a physical random access channel (PRACH) resource for a communication device to transmit a beam fault recovery signal, The process includes performing a beam fault recovery procedure (BFR), the beam fault recovery procedure including receiving the beam fault recovery signal using the PRACH resources from the communication device, The configuration includes first information indicating a reference to a plurality of PRACH resources allocated exclusively to the communication device, second information indicating the number of PRACH resources in a subset of the plurality of PRACH resources, and third information indicating the time period during which the allocation of the plurality of PRACH resources is valid. The PRACH resource is limited to the subset of the plurality of PRACH resources based on the second information, If the aforementioned time period expires, the PRACH resource will become unusable. Integrated circuit.

Images