Wireless device configured to initiate a time-domain predictive beam report and use of such beam report

Abstract

A method implemented in a wireless device (120) for facilitating a determination of at least one TRP beam to be used by a transmit-receive point, TRP (115) in a wireless network (110) in relation to the wireless device, the method comprising: performing measurements on two or more TRP beams associated with respective downlink reference signal resources; establishing a UE-initiated time-domain predictive beam report based on the measurements, wherein the UE-initiated time-domain predictive beam report indicates a predicted quality or predicted relative quality of the TRP beams; and transmitting the UE-initiated time-domain predictive beam report to a network node.

Description

WIRELESS DEVICE CONFIGURED TO INITIATE A TIME-DOMAIN PREDICTIVE BEAM REPORT AND USE OF SUCH BEAM REPORTTECHNICAL FIELD

[0001] The present disclosure relates to the field of cellular communication between multiantenna transceivers. In particular, it proposes a novel beam report to be transmitted from a wireless device to the network, wherein the beam report is initiated by the wireless device and contains information obtained by temporal prediction. Further disclosed are methods for facilitating a determination of a TRP beam to be used by a transmit-receive point (TRP) in relation to a wireless device, in which the novel beam report is utilized.BACKGROUND

[0002] The tendency towards ever larger antenna arrays at millimeter-wave and sub-terahertz frequencies - particularly in TRPs - is making an increasing number of narrow analog beams available. In order to support the network's decision-making related to beam management, there is a concurrent growing need for measurements and reporting.

[0003] The beam management framework specified in 3GPP Releases 15 and 16 provides the network with great flexibility in some areas, though at the cost of considerable signaling overhead. In other areas, the specifications may be considered overly restrictive, to the point of stopping truly efficient beam management as far as signaling overhead and responsiveness is concerned. These limitations are particularly noticeable and costly when the user equipment (UE) is moving and adaptations become necessary. One example is that a beam update mediated by layer-1 signaling can only be performed for the PDSCH channel (more precisely, by indicating a change of Transmission Configuration Indicator, TCI, state in Downlink Control Information, DCI), whereas higher-layer signaling (MAC-CE and / or RRC) is required to update the beam for other reference signals / channels. This split solution contributes to the total overhead and latency. Furthermore, in the overwhelming majority of cases, the specified beam management flexibility is not genuinely needed, knowing that the network will typically transmit to and receive from the UE using the same beam for both data and control. Hence, using TCI state for downlink (DL) signals / channels and spatial relations for uplink (UL) signals / channels complicates the implementations.

[0004] The unified TCI state framework, which was introduced with 3GPP Release 17, may be said to streamline the indication of spatial properties, and more precisely lets a single TCI state indicate quasi co-location (QCL) properties for multiple downlink and uplink signals or channels. It is further possible to use a joint TCI state for both DL and UL signals or channels.

[0005] Despite these relatively recent improvements, there is broad consensus in the industry to keep optimizing the beam reporting framework, with a view to limiting or reducing the signaling overhead. One way forward that may be explored in 3GPP Release 19 includes UE-initiated beam reporting. The protocol schematically illustrated in figure 9 embodies a generic form of UE-initiated beam reporting. In the step 930, a UE 120 carries outperformance measurements on several candidate network beams repeatedly using periodically transmitted downlink reference signals (DL-RSs), such as SSB or CSI-RS. In the next step 940, when the UE has determined that one of the candidate network beams is better than the currently used network beam, a trigger condition is fulfilled, which causes the UE to send, in step 950, a UE-initiated beam report to the network 110, 115. The network then receives this report and, in step 960, sends a response back to the UE that confirms that the UE shall switch to the new reported network beam. After some beam application time has elapsed, the network (step 970a) and the UE (step 970b) switch to the new beam.

[0006] As suggested by figure 9, even the UE-initiated beam report will produce a nonnegligible amount of latency and overhead. For example, latency is introduced in steps 930 and 940, since it will take a certain time for the UE to determine that another network beam is better than the currently used network beam. Further, the beam application time following after the beam report response 960 will also introduce some latency. This means that for high-speed UEs and for network nodes with many narrow beams, the beam-switching procedure for a generic UE-initiated beam report might still take so long that it deteriorates the overall performance. In addition, when beam switches are frequent, the UE-initiated beam report will be triggered rather often which will multiply the contribution of the signaling overhead associated with step 950. For these reasons, one may expect that the introduction of a generic UE-initiated beam report of the type described may be effective to reduce signaling overhead but will not lead to an ideally responsive beam management.

[0007] One problem is thus to limit or reduce the latency associated with the beam reporting, ultimately to render the beam management more responsive to changes in the radio conditions and UE movements.SUMMARY

[0008] One objective of the present disclosure is to address the adverse system-level and device-level consequences of the steadily growing number of narrow TRP beams in need of radio measurements by UEs, including overhead and latency. The present disclosure specifically aims to make methods and devices available which allow a more efficient determination of at least one TRP beam to be used by the TRP in relation to a UE. It is a further objective to propose methods and devices that allow such TRP-beam determination with an improved latency.

[0009] At least some of these objectives are achieved by the invention as defined by the independent claims. The dependent claims are directed to advantageous embodiments.

[0010] In a first aspect of the present disclosure, there is provided a method implemented in a wireless device for facilitating a determination of at least one TRP beam to be used by a TRP in a wireless network in relation to the wireless device, i.e., for transmitting communications to the wireless device and / or for receiving communications from the wireless device. The method comprises: performing measurements on one or more, preferably two or more, TRP beams associated with respective downlink reference signal resources; establishing a UE-initiated time-domain predictive beam report based on the measurements, wherein the UE-initiated time-domain predictivebeam report indicates a predicted quality or predicted relative quality of the TRP beams; and transmitting the UE- initiated time-domain predictive beam report to a network node.

[0011] As used in the present disclosure, a "predicted quality” may for example be a performance metric, such as predicted RSRP, predicted SI NR or predicted RSRQ. A "predicted relative quality” may for example be an indication of a best beam or a number of best beams (out of all the configured TRP beams associated with the triggered UE-initiated time-domain predictive beam report), i.e., information to the effect that the predicted quality of said beam is superior to the predicted quality of other beams which are not indicated by the UE-initiated timedomain predictive beam report. A "predicted quality” can also be a probability that the reported beam is the best beam.

[0012] The novel UE-initiated beam report proposed herein is time-domain predictive in the sense that the validity of the predicted quality or predicted relative quality begins a nonzero delay after completion of the measurements. By contrast, a report where a measured value is considered reliable from the time of measuring and for a further nonzero period is not time-domain predictive according to the terminology of the present disclosure.

[0013] The method according to the first aspect leverages those tools for predicting future beam quality with high accuracy that have become available in recent years. Advantageously, the use of predicted (relative) beam quality makes it possible to initiate a needed beam-switch operation earlier than with a conventional protocol where the UE is required to await a change in actual (relative) beam quality before reporting it to the network. (An example of such a conventional protocol was described with reference to figure 9, where the trigger condition in step 940 refers to actual beam quality.) The invention may therefore be expected to limit or reduce latencies in the wireless network.

[0014] In a second aspect of the disclosure, there is provided a method implemented in a network node of a wireless network for facilitating a determination of at least one TRP beam to be used by at least one TRP in the wireless network in relation to a wireless device. Mirroring the method of the first aspect, the present method comprises: transmitting to the wireless device a configuration authorizing the wireless device to transmit UE- initiated time-domain predictive beam reports; and receiving from the wireless device a UE-initiated time-domain predictive beam report, which indicates a predicted quality or predicted relative quality of two or more TRP beams associated with respective downlink reference signal resources.

[0015] A network node executing the method according to the second aspect will trust the predicted (relative) beam quality reported by the wireless device, and thereby accept to initiate a needed beam-switch operation earlier. This is not possible with the conventional protocol illustrated in figure 9, where the network bases its decision-making on measured actual (relative) beam quality only.

[0016] There is further provided, according to a third and fourth aspect of the present disclosure, a wireless device and a network node that operate in accordance with the above-described two methods. In general terms, the wireless device and the network node share the effects and advantages of these methods, and they can be implemented with a corresponding degree of technical variation.

[0017] This disclosure will further describe a computer program containing instructions for causing a computer, or the wireless device or network node in particular, to carry out the above methods. The computer program may be stored or distributed on a data carrier. As used herein, a "data carrier” may be a transitory data carrier, such as modulated electromagnetic or optical waves, or a non-transitory data carrier. Non-transitory data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of magnetic, optical or solid-state type. Still within the scope of "data carrier”, such memories may be fixedly mounted or portable.

[0018] In some embodiments, there is provided a capability of UE-initiated time-domain predictive beam report, which is a data structure through which a wireless device can indicate that it supports a UE-initiated time-domain predictive beam report. This allows the network to adapt the interaction relating to beam management to suit each connected wireless device. The use of the capability further allows wireless devices capable of the UE- initiated time-domain predictive beam report to coexist with legacy wireless devices in the same wireless network.

[0019] In some embodiments, the network sends a triggering configuration to the wireless device. Thanks to this triggering configuration, the network can adapt the trigger condition causing the transmission of the UE-initiated time-domain predictive beam report to suit different wireless devices and / or to make adjustments over time.

[0020] In still further embodiments, the network sends to the wireless device a report configuration, which specifies a content of the UE-initiated time-domain predictive beam report.

[0021] For the purposes of the present disclosure, a "beam” may be defined in terms of an DL RS resource. More precisely, the network may enable UE-side measurements by transmitting on a set of DL RS resources, wherein each DL RS resource is transmitted on a separate beam. The network may then schedule the UE on one of said beams by referring to one of the transmitted DL RS resources, e.g., in terms of DL RS indices or beam identities (beam IDs), which are in a one-to-one relationship with the corresponding beams. When reciprocity holds, the TRP may use the same beam for transmission and receipt, which justifies the term "TRP beam”.

[0022] In the present disclosure, a "wireless device” may be a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptopmounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE), a vehicle-mounted wireless terminal device and the like. The terms wireless device and user equipment (UE) are used interchangeably.

[0023] A "network node” may be any equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or equipment in the wireless network to enable and / or provide wireless access to the wireless device and / or to perform other functions (e.g., administration) in the wireless network. Examples of network nodes include, but are not limited to, access points (APs), base stations (BSs) including radio base stations, evolved NodeBs (eNBs) and NR NodeBs (gNBs). It is understood that one network node may be associated with one TRP or multiple TRPs, wherein each TRPcomprises at least one antenna panel and any associated radio and processing units. The special term access point (AP), which is sometimes used to designate antenna panels in dense localized deployment, shall be considered a special case of a TRP.

[0024] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a / an / the element, apparatus, component, means, step, etc.” are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order described, unless this is explicitly stated.BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, on which: figure 1 shows a wireless device in the coverage area of one single-TRP base station and one multi-TRP base station; figure 2 is a flowchart illustrating two-stage TCI updating; figure 3 illustrates MAC signaling relating to TCI states activation / deactivation; figure 4 illustrates a DCI indication of a TCI state in the form of a pointer into an ordered list of activated TCI states; figures 5 and 6 show example activated TCI states and their mapping to TCI field codepoints for Joint DL / UL TCI in 3GPP NR Release 17; figures 7 and 8 are plots of trigger quantities as a function of time, respectively illustrating Event A3 and Event A5; figure 9 is a sequence diagram illustrating a generic UE-initiated beam report; and figure 10 is a sequence diagram illustrating a UE-initiated time-domain predictive beam report according to embodiments herein.DETAILED DESCRIPTION

[0026] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, on which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of the invention to those skilled in the art. Like numbers refer to like elements throughout the description.System overview

[0027] Figure 1 relates to a first deployment where a wireless device 120 is located in the coverage area of one base station 110 with a single TRP 115 (upper portion of figure 1 ), and one base station 110 with two TRPs 115a, 115b (lower portion of figure 1). The base stations 110 are configured as network nodes in a radio access network within a cellular telecommunication system, such as a 3GPP NR system.

[0028] The figure schematically illustrates, in terms of a number of functional units, the components of the wireless device 120 according to an embodiment. Processing circuitry 122 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 124, e.g. in the form of a storage medium 123. The processing circuitry 122 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA). Particularly, the processing circuitry 122 is configured to cause the wireless device 120 to perform a set of operations, or steps, as disclosed below with reference to figure 7. For example, the storage medium 123 may store the set of operations, and the processing circuitry 122 may be configured to retrieve the set of operations from the storage medium 123 to cause the wireless device 120 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 122 is arranged to execute the method for facilitating the determination of a beam to be used when the wireless device 120 communicates with the network node 110, to be described with reference to figure 7. The storage medium 123 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0029] The wireless device 120 may further comprise a communications interface 125 for communications with the network nodes 110. As such, the communications interface 125 may comprise one or more transmitters and receivers, comprising analog and digital components. The processing circuitry 122 controls the general operation of the wireless device 120, e.g. by sending data and control signals to the communications interface 125 and the storage medium 123, by receiving data and reports from the communications interface 125, and by retrieving data and instructions from the storage medium 123. Other components, as well as the related functionality, of the wireless device 120 are omitted in order not to obscure the concepts presented herein.

[0030] Figure 1 further illustrates, in terms of a number of functional units, the components of the network nodes 110 according to an embodiment. Each network node 110 comprises a frontend unit 111 and at least one TRP 115. The frontend unit 111 may be co-located with the TRP 115 or located remotely from this. In the frontend unit 111, processing circuitry 112 is provided using any combination of one or more of a suitable CPU, multiprocessor, microcontroller, DSP, etc., capable of executing software instructions stored in a computer program product 114, e.g. in the form of a storage medium 113. The processing circuitry 112 may further be provided as at least one ASIC or FPGA. Particularly, the processing circuitry 112 is configured to cause each network node 110 to perform a set of operations, or steps, as disclosed below with reference to figure 7. For example, the storage medium 113may store the set of operations, and the processing circuitry 112 may be configured to retrieve the set of operations from the storage medium 113 to cause the wireless device 110 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 112 is arranged to execute the method for determining a beam to be used when the network node 110 communicates with the wireless device 120, to be described with reference to figure 7. The storage medium 113 may also comprise persistent storage, as exemplified above.

[0031] The network node 110 may further comprise a communications interface, including the TRP 115, for communications with the wireless device 120. As such, the communications interface may comprise one or more transmitters and receivers, comprising analogue and digital components. The processing circuitry 112 controls the general operation of the network node 110, e.g. by sending data and control signals to the communications interface (with the TRP 115) and the storage medium 113, by receiving data and reports from the communications interface, and by retrieving data and instructions from the storage medium 113. Other components, as well as the related functionality, of the network nodes 110 are omitted in order not to obscure the concepts presented herein.Beam management framework in 3GPP NR

[0032] By way of technical background, the existing beam management framework according to 3GPP NR Releases 15 / 16 and Release 17 will now be briefly summarized. The summary will refer to the concept of quasi co-location (QCL) and the related information element Transmission Configuration Indicator (TCI).

[0033] In NR, several signals can be transmitted from different antenna ports of a same base station. These signals can have the same large-scale properties such as Doppler shift / spread, average delay spread, or average delay. These antenna ports are then said to be quasi co-located (QCL).

[0034] If the UE knows that two antenna ports are QCL with respect to a certain parameter (e.g. Doppler spread), the UE can estimate that parameter based on one of the antenna ports and apply that estimate for receiving signal on the other antenna port.

[0035] For example, there may be a QCL relation between a CSI-RS for tracking RS (TRS) and the PDSCH DMRS. When UE receives the PDSCH DMRS it can use the measurements already made on the TRS to assist the DMRS reception.

[0036] Information about what assumptions can be made regarding QCL is signaled to the UE from the network. In NR, four types of QCL relations between a transmitted source RS and transmitted target reference signal (RS) were defined:- Type A: {Doppler shift, Doppler spread, average delay, delay spread}- Type B: {Doppler shift, Doppler spread}- Type C: {average delay, Doppler shift}- Type D: {Spatial Rx parameter}QCL Type D was introduced to facilitate beam management with analog beamforming and is known as spatial QCL. There is currently no strict definition of spatial QCL, but the understanding is that if two transmitted antenna ports are spatially QCL, the UE can use the same Rx beam to receive them. This is helpful for a UE that uses analog beamforming to receive signals, since the UE needs to adjust its RX beam in some direction prior to receiving a certain signal. If the UE knows that the signal is spatially QCL with some other signal it has received earlier, then it can safely use the same RX beam to receive also this signal. Note that for beam management, the discussion mostly revolves around QCL Type D, but it is also necessary to convey a Type A QCL relation for the RSs to the UE, so that it can estimate all the relevant large-scale parameters.

[0037] Typically, this is achieved by configuring the UE with a CSI-RS for tracking (TRS) for time / frequency offset estimation. To be able to use any QCL reference, the UE would have to receive it with a sufficiently good SINR. In many cases, this means that the TRS must be transmitted in a suitable beam to a certain UE.

[0038] To introduce dynamics in beam and transmission point (TRP) selection, the UE can be configured through RRC signaling with up to 128 TCI (Transmission Configuration Indicator) states. The TCI-State information element is defined in 3GPP TS 38.331 .

[0039] Each TCI state contains QCL information related to one or two RSs. For example, a TCI state may contain CSI-RS1 associated with QCL Type A and CSI-RS2 associated with QCL Type D. If a third RS, e.g. the PDCCH DMRS, has this TCI state as QCL source, it means that the UE can derive Doppler shift, Doppler spread, average delay, delay spread from CSI-RS1 and Spatial Rx parameter (i.e. the RX beam to use) from CSI-RS2 when performing the channel estimation for the PDCCH DMRS.

[0040] A first list of available TCI states is configured for PDSCH, and a second list of TCI states is configured for PDCCH. Each TCI state contains a pointer, known as TCI State ID, which points to the TCI state. The network then activates via MAC CE one TCI state for PDCCH (i.e. provides a TCI for PDCCH) and up to eight TCI states for PDSCH. The number of active TCI states the UE support is a UE capability, but the maximum is 8.

[0041] To illustrate, it is assumed that a UE has 4 activated TCI states (from a list of totally 64 configured TCI states). Hence, 60 TCI states are inactive for this particular UE and the UE need not be prepared to have large- scale parameters estimated for those inactive TCI states. But the UE continuously tracks and updates the large- scale parameters for the RSs in the 4 active TCI states. When scheduling a PDSCH to a UE, the DCI contains a pointer to one activated TCI state. The UE then knows which large-scale parameter estimate to use when performing PDSCH DMRS channel estimation and thus PDSCH demodulation.

[0042] As long as the UE can use any of the currently activated TCI states, it is sufficient to use DCI signaling. However, at some point in time, none of the source RSs in the currently activated TCI states can be received by the UE, i.e., when the UE moves out of the beams in which the source RSs in the activated TCI states are transmitted. When this happens (or actually before this happens), the gNB would have to activate new TCI states.Typically, since the number of activated TCI states is fixed, the gNB would also have to deactivate one or more of the currently activated TCI states.

[0043] The two-step procedure related to TCI state update is depicted in Figure 2. When a need to update a current TCI state has been determined (step 201), it is assessed whether the updating requires the activation of a new set of TCI states (step 202). This is true if the new TCI state is not among the currently activated TCI states, and then MAC signaling is used for activating the new set (Y branch, step 204). Conversely, the use of MAC signaling is not necessary if the new TCI state belongs to an already activated set, in which case the new TCI state is selected using DCI (N branch, step 203).

[0044] TCI states Activation / Deactivation for UE-specific PDSCH via MAC CE. The details of the MAC CE signaling that is used to activate / deactivate TCI states for UE specific PDSCH will now be provided. The structure of the MAC CE for activating / deactivating TCI states for UE specific PDSCH is given in Error! Reference source not found., which is adapted from Figure 6.1.3.14-1 of 3GPP TS 38.321.

[0045] As shown in Error! Reference source not found., the MAC CE contains the following fields:Serving Cell ID: This field indicates the identity of the Serving Cell for which the MAC CE applies. The length of the field is 5 bits;BWP ID: This field contains the ID corresponding to a downlink bandwidth part for which the MAC CE applies. The BWP ID is given by the higher layer parameter BWP-ld as specified in 3GPP TS 38.331. The length of the BWP ID field is 2 bits since a UE can be configured with up to 4 BWPs for DL;- A variable number of fields 7): If the UE is configured with a TCI state with TCI State ID / , then the field T indicates the activation / deactivation status of the TCI state with TCI State ID / . If the UE is not configured with a TCI state with TCI State ID / , the MAC entity shall ignore the Ti field. The Ti field is set to "1" to indicate that the TCI state with TCI State ID / shall be activated and mapped to a codepoint (i.e., value) of the DCI Transmission Configuration Indication field, as specified in 3GPP TS 38.214 / 38.321 . The Ti field is set to "0" to indicate that the TCI state with TCI State ID / shall be deactivated and is not mapped to any codepoint of the DCI Transmission Configuration Indication field. It should be noted that the codepoint to which the TCI State is mapped is determined by the ordinal position among all the TCI States with field set to "1". That is the first TCI State with field set to "1" shall be mapped to the codepoint value 0 of DCI Transmission Configuration Indication field, the second TCI State with field set to "1" shall be mapped to the codepoint value 1 of DCI Transmission Configuration Indication field, and so on. In NR Rel-15, the maximum number of activated TCI states is 8;- A Reserved bit R: this bit is set to ‘O' in NR Rel-15.

[0046] Note that the TCI States Activation / Deactivation for UE-specific PDSCH MAC CE is identified by a MAC PDU sub-header with logical channel ID (LCID) as specified in Table 6.2.1-1 of 3GPP TS 38.321 (this table isreproduced below as Table 1). The MAC CE for Activation / Deactivation of TCI States for UE-specific PDSCH has variable size.

[0047] TCI state indication for UE-specific PDSCH via DCI. The gNB can use DCI format 1_1 or 1_2 to indicate to the UE that it shall use one of the activated TCI states for the subsequent PDSCH reception. The field being used in the DCI is Transmission configuration indication, which is three bits if tci-Presentl nDCI is "enabled” or tci-PresentForDCI-Format1-2-r16 is present respectively for DCI format 1_1 and DCI format 1_2 by higher- layer signaling. One example of such a DCI indication is depicted in figure 4.

[0048] The DCI acts as pointer into an ordered list of activated TCI states. DCI codepoint 0 indicates the first TCI state index in the list of TCI states, DCI codepoint 1 indicates the second TCI state index in the list, and so on.Overview of the TCI state framework in 3GPP NR Releases 15 and 16

[0049] The NR Rel-15 / 16 framework for beam management is based on the framework of spatial QCL assumptions and spatial relations in order to support, e.g., analog beamforming implementations at the UE and / or the network. The framework allows great flexibility for the network (i.e., the gNB) to instruct the UE to receive signals from several directions and to transmit signals in several directions. In this framework, the uplink and downlink configurations are decoupled, e.g., there is no direct relation between the configured spatial QCL assumptions and the spatial relations.

[0050] In the Rel-15 / Rel-16 framework, downlink beam management is performed by conveying spatial QCL (‘Type D') assumptions to the UE, which are conveyed in TCI states. One TCI state contains one or two RSs, and each RS is associated with a QCL type.PDCCH beam management: The network configures the UE with a set of PDCCH TCI states by RRC, and then activates one TCI state per CORESET using MAC CE.PDSCH beam management: The network configures the UE with a set of PDSCH TCI states by RRC, and then activates up to 8 TCI states by MAC CE. After activation, the network dynamically indicates one of these activated TCI states using a TCI field in DCI when scheduling PDSCH. o Alternatively, the network may simplify the beam management by not setting the RRC parameter tci-PresentlnDCI (which is configured per CORESET) to enabled. In this case, the UE uses the same TCI state for PDSCH as for PDCCH.

[0051] In the Rel-15 / Rel-16 framework, uplink beam management is performed using configuration of spatial relations. A spatial relation is defined at the UE side between a source RS and a target RS. The source RS can be a received DL RS (SSB or CSI-RS) or an SRS. The target RS can be a transmitted PUCCH DMRS or an SRS. Note that there is no direct configuration of the spatial relation for a PUSCH: the PUSCH follows the spatial relation of a PUCCH or an SRS.- PUCCH beam management: For PUCCH, the network configures the UE with a set of 8 spatial relations using RRC, and subsequently activates one of these spatial relations using MAC CE. The spatialrelation is defined perPUCCH resource. In Rel-16, enhancements were made such that spatial relation could be updated for a group of PUCCH resources using a single MAC-CE. In addition, default spatial relation for PUCCH was introduced in Rel-16, such that when no spatial relation is configured / activated for a PUCCH resource, the UE uses the TCI state / QCL assumption of the CORESET with lowest ID, both to derive spatial relation and to derive path loss reference signal.- PUSCH beam management: A PUSCH scheduled by DCI Format 0_1 is transmitted over the ports where a configured SRS resource may also be transmitted. Either two (codebook-based) or four (non- codebook-based) SRS resources can be defined in the SRS resource set. The network selects which SRS resource in the set should correspond to the PUSCH transmission (i.e., PUSCH is transmitted on the same ports as the selected SRS and using the spatial relation of the selected SRS) using the SRS resource indicator (SRI) field in DCI. The spatial relation for the SRS resources in the set is provided either by RRC (for periodic or aperiodic SRS) or MAC-CE (for aperiodic or semi-persistent SRS). For PUSCH scheduled by DCI Format 0_0, there is no SRI and the spatial relation instead follows that of a PUCCH resource. In Rel-16, default spatial relation for SRS was introduced, such that when no spatial relation is configured / activated for an SRS resource, the UE uses the TCI state / QCL assumption of the CORESET with lowest ID, both to derive spatial relation and to derive path loss reference signal.- SRS beam management: Spatial relations for SRS are configured by RRC (for periodic and aperiodic) or by MAC CE (aperiodic or semi-persistent)

[0052] Although the Release-15 / Rel-16 framework provides the network with great flexibility in some areas, at the cost of quite some signaling. In some other areas, the specification is overly restrictive and prohibits efficient (low signaling overhead) and rapid beam management. These limitations are particularly noticeable and costly when UE movement is considered. One example is that beam update using DCI can only be performed for PDSCH, and MAC-CE and / or RRC is required to update the beam for other reference signals / channels, with cause extra overhead and latency.

[0053] Furthermore, in the overwhelming majority of cases, the specified beam management flexibility is not really needed since the network will transmit to and receive from the UE using the same beam for both data and control. Hence, using TCI state for DL signals / channels and spatial relations for UL signals / channels complicates the implementations.

[0054] Another issue is related to the path loss reference signal used for UL power control. In NR, only up to four path loss reference signals can be configured for a UE, which typically is significantly less than the number of beams a TRP at Frequency Range 2 (FR2) uses to cover the cell. Hence, when a UE moves around in the cell, the path loss reference signal needs to be updated using MAC-CE and / or RRC, which introduces extra latency and overhead.Overview of the TCI state framework in 3GPP NR Releases 17

[0055] In 3GPP Release 17, a new unified TCI state framework is specified, which aims to streamline the indication of transmit / receive spatial filter (and other QCL properties) to the UE by letting a single TCI state indicate QCL properties for multiple different DL and / or UL signals / channels.

[0056] The unified TCI state framework of Release 17 can be RRC configured in one out of two modes of operation "Joint DL / UL TCI” or "Separate DL / UL TCI”. For "Joint DL / UL TCI” operation, one common Joint TCI state is used for both DL and UL signals / channels. For "Separate DL / UL TCI” operation, one common DL-only TCI state is used for DL channels / signals, and one common UL-only TCI state is used for UL signals / channels.

[0057] It is expected that "Joint DL / UL TCI” operation will be the most common use case, but "Separate DL / UL TCI” operation can be useful in specific scenarios where the optimal DL beam differs from optimal UL beam, for example in case a UE panel associated with the best DL beam is affected by P-MPR (power management - maximum power reduction), and hence need to reduce the maximum allowed output power.

[0058] Beam indication using Release-17 TCI state framework. The common TCI state ID can be updated in a similar way as the TCI state ID is update for PDSCH in Release 15 / 16, i.e. with one of two alternatives:- Two-stage: RRC signaling is used to configure a number TCI states in PDSCH-config, and MAC-CE is used to activate a single TCI state (that TCI state will then be applied)- Three-stage: RRC signaling is used to configure a number TCI state in PDSCH-config, MAC-CE is used to activate up to 8 TCI states, and a 3-bit TCI state bitfield (consisting of up to 8 codepoints) in DCI is used to indicate one of the activate TCI states (that TCI state will then be applied)

[0059] For "Joint DL / UL TCI” operation, maximum one Joint TCI state can be activated per TCI codepoint. One schematic example of how this may look is illustrated in figure 5, which is an example of activated TCI states and their mapping to TCI field codepoints for "Joint DL / UL TCI”. If the indicated TCI codepoint is "0”, the UE should apply "Joint TCI state 7” as common QCL source for both DL and UL signals / channels.

[0060] For "Separate DL / UL TCI” operation, up to two TCI states can be activated per TCI codepoint, one for DL signals / channels (DL-only TCI state) and one for UL signals / channels (UL-only TCI state). One schematic example of how this may look is illustrated in figure 6, in a similar format as figure 5. In case the TCI codepoint is "0”, the UE should apply "DL-only TCI state 3” as common QCL source for DL signals / channels, and not update the QCL source for UL signals channel. In case the TCI codepoint is "7”, the UE should apply "UL-only TCI state 57” as QCL source for UL signals / channels, and not update the QCL source for DL signals / channel. In case the TCI codepoint is "3”, the UE should apply "DL-only TCI state 9” as QCL source for DL signals / channels and apply "UL-only TCI state 1” as QCL source for UL signals / channels.

[0061] The existing DCI formats 1_1 and 1_2 in NR are reused (like in the Release-15 / 16 beam management framework) for beam indication, both with and without DL assignment. For DCI formats 1_1 and 1_2 with DL assignment, ACK / NACK of the PDSCH can be used as indication of successful reception of beam indication. ForDCI formats 1_1 and 1_2 without DL assignment, a new ACK / NACK mechanism analogous to that for semi- persistent scheduling (SPS) PDSCH release with both type-1 and type-2 HARQ-ACK codebook is used, where upon a successful reception of the beam indication DCI, the UE reports an ACK.

[0062] For DCI-based beam indication, the first slot to apply the indicated TCI state is at least Y symbols after the last symbol of the acknowledgment of the joint or separate DL / UL beam indication. The Y symbols are configured by the gNB based on UE capability, which is also reported in units of symbols.

[0063] QCL and UL spatial relation rules. For both "Joint DL / UL TCI” operation and "Separate DL / UL TCI” operation, the large scale QCL properties are inferred from one source RS (qcl-Type1 only) or two source RSs (qcl-Type1 and qcl-Type2) analogous to Rel-15 / 16 beam management framework. For "Joint DL / UL TCI” operation, the UL spatial filter is derived from that corresponding to the source RS of DL QCL Type D, analogous to default beam operation for Rel-15 / 16 beam management framework.

[0064] In DL, the Joint / DL-only TCI state can provide common QCL information at least for:- UE-dedicated PDCCH,- PDSCH,- Aperiodic CSI-RS for CSI, and- Aperiodic CSI-RS for beam management. o CSI-RS for other time-domain behaviors has not been agreed.

[0065] RRC configuration is used to indicate if a non-UE dedicated PDCCH / PDSCH, aperiodic CSI-RS for CSI (channel state indication) and BM (beam management) should follow the common beam or not. Common beam here means that the same beam is used for receiving DL signals / channels that are indicated to follow the common beam. For DL signal / channels that do not follow the common beam, a Rel-17 TCI state can be indicated as QCL source in a similar way as for Rel-15 / 16 beam management framework. As an example, for a periodic CSI-RS that does not follow the common beam, a Rel-17 TCI state can be configured in the parameter “qcl-l nfoPeriodicCSI-RS” in "NZP-CSI-RS-Resource information element” as specified in 3GPP TS 38.331 V16.7.0. The possible target and source RS and corresponding QCL properties for that are supported for Joint / DL-only TCI state indication are summarized in Error! Reference source not found..

[0066] In UL, the Joint / UL-only TCI state can provide common QCL information as least for: all or a subset of all PUCCH resources,- dynamic-grant / configured-grant PUSCH,SRS for all usages (except for usage 'Positioning').RRC configuration is used to indicate whether a SRS and PUCCH resource should follow the common beam or not. With following the common beam, it is meant that the same beam is used for receiving UL signals / channels that are indicated to follow the common beam. For UL signal / channels that do not follow the common beam, a Release-17 TCI state can be used to indicate spatial relation instead of a DL / UL-RS which is used to indicate spatial relation for Rel-15 / 16 beam management framework. As an example, for a periodic SRS resource that does not follow the common beam, a new RRC parameter in an SRS resource can be configured with a Rel-17 TCI state, and the UE will use that Rel-17 TCI state to determine the spatial relation for that SRS resource. Any of the following reference signals can be used to indicate spatial relation for a UL signal / channel in Rel-17 TCI state framework:- SSB,- TRS (tracking reference signal),- CSI-RS for beam management,SRS with usage set to ‘Beam management'.

[0067] Inter-cell beam management Inter-cell beam management has been included in the Rel-17 TCI state framework to facilitate L1 / L2 inter-cell mobility (to be specified for higher layers in NR Rel-18) as well as inter-cell multi-TRP operation.

[0068] For inter-cell beam management, a UE can be configured to measure and report Release-15 L1-RSRP for SSB(s) associated with non-serving cells. Which serving cell an SSB is associated with is indicated by RRC signaling, where each SSB is paired with a PCI. The maximum number of PCIs different from the serving cell that could be used for SSB measurement / reporting is up to UE capability and can be one of 0, 1, 2, 3 and 7. The beam indication for inter-cell beam management will work in the same way as for intra-cell Rel-17 unified TCI state framework, as described in section Beam indication using Rel-17 TCI state framework above.

[0069] The DL QCL rules and UL spatial relation rules for inter-cell beam management will work in the same way as for intra-cell Rel-17 unified TCI state framework, as described in section Beam indication using Rel-17 TCI state framework.Mobility measurements in LTE and NR

[0070] The UE can be configured by the network to perform measurements of serving and neighbor cells, by sending a measurement configuration, provided in an RRCReconfiguration message (in case of NR) or an RRCConnectionReconfiguration message (for LTE), or as part of broadcasted system information. In accordance with this measurement configuration provided by the network, the UE also reports measurement information, using a Measurement Report RRC message, to the network. The network then typically uses the measurement reports to trigger handover of the UE to a neighbor cell.

[0071] The neighbor-cell measurements are classified into intra-frequency, inter-frequency or inter-RAT measurements.

[0072] The UE measures on what is defined as a measurement object, which is part of the measurement configuration. A measurement object is- for LTE: a carrier frequency- for NR: frequency / time location and subcarrier spacing of reference signals.The measurement object may be further refined by listed cells (such as allowed cells, and / or excluded cells) as well as listed cell-specific offsets. Excluded (also called blacklisted cells) are not considered in event evaluation or measurement reporting. The allowed (also called whitelisted) cells may be the only ones considered for event evaluation and measurement reporting if so configured. If neither allowed nor excluded cells are configured, the UE considers all detect cells in event evaluation and measurement reporting.

[0073] The measurement configuration also includes a reporting configuration, consisting of a reporting criterion (used to trigger the report) and reporting format (which quantities to include in the report). The reporting criterion is either "periodic” or "single event”. The reporting quantity may be RSRP for example.

[0074] The measurement configuration also includes a list of measurement identities where each measurement identity links one measurement object with one reporting configuration. By configuring multiple measurement identities, it is possible to link more than one measurement object to the same reporting configuration, as well as to link more than one reporting configuration to the same measurement object. The measurement identity is also included in the measurement report that triggered the reporting, serving as a reference to the network.

[0075] The measurement configuration also includes a quantity configuration, which defines the measurement filtering configuration used for all event evaluation and related reporting, and for periodical reporting of that measurement.

[0076] Finally, the measurement configuration includes Measurement gaps, which are periods that the UE may use to perform measurements.

[0077] In case of single event reporting criterion, there are a number of event types defined to trigger measurement reports. Examples of two event types are the following:Event A3, as shown in figure 7: For LTE it is also known as "Neighbour becomes offset better than PCell” . In case of NR it is also known as "Neighbour becomes offset better than PCell / PSCell”. The offset is the cell specific offset part of the measurement object corresponding to the particular neighbor cell. The offset acts as an additional margin by which the trigger quantity for the neighbor cell must surpass the PCell.Event A5, as shown in figure 8: For LTE it is also known as "PCell becomes worse than threshold 1 and neighbour becomes better than threshold2” . In case of NR it is also known as "PCell / PSCell becomes worse than threshold 1 and neighbour becomes better than threshold2”. The thresholds are part of the reporting configuration.

[0078] As part of the configuration for events A3, A5 and also other type of events, a hysteresis may also be included. The hysteresis is useful in combination with configuration of "reportOnLeave”, where the UE transmits a report when a trigger quantity of a measurement object ceases to fulfil the criterion (and taking the hysteresis into account) for reporting. For example, as also illustrated in Figure 9, when using the "reportOnLeave” applied on event A3 for a neighbor cell, the UE transmits a measurement report when the neighbor cell falls below the serving cell plus offset minus the hysteresis.UE-initiated time-domain predictive beam report

[0079] As the above summary suggests, today's mobile networks are experiencing a steady growth in measurements and reporting due to the increasing number of narrow TRP beams. To address the adverse system-level and device-level consequences that this growth may bring with it, including signaling overhead andbeam-switching latency, the inventors have developed an efficient TRP beam determination method to be described next.

[0080] Reference is made to figure 10, which is a sequence diagram illustrating a method 1000 of determining at least one TRP beam to be used by a TRP 115 in a wireless network 110 in relation to a wireless device 120.From the wireless device's 120 point of view, figure 10 provides a method for facilitating the determination of one or more beams to be used by the wireless device 120 for receiving in downlink and transmitting in uplink in relation to the TRP 115. From the network node's 110 perspective, figure 10 provides a method for determining one or more beams to be used by the TRP 115 for transmitting in downlink and receiving in uplink in relation to the wireless device 120. Preferably, the wireless device 120 is a wireless device which is capable of at least partially analog beamforming, including various forms of constrained digital beamforming, such as time-domain digital beamforming or frequency-domain digital beamforming including narrowband beamforming.

[0081] In an optional first step 1010, the wireless device 120 indicates to the network node a capability signifying that it supports a UE-initiated time-domain predictive beam report, that is, a beam report with the novel content and / or novel trigger condition proposed in the present disclosure. The capability can for example be indicated by RRC signaling, such as within a U ECapability Information message.

[0082] In an optional next step 1020, the network node 110 transmits - and the wireless device 120 receives - a configuration authorizing the wireless device to transmit UE-initiated time-domain predictive beam reports. In some embodiments, network node 110 transmits the configuration in response to being requested by the wireless device 120 to do so; for example, the wireless device 120 may set a flag in a message to a value indicating that the wireless device 120 intends to use predictive beam reporting, and the network node 110 may acknowledge this by transmitting the predictive beam report configuration. If the network node 110 has received a UE capability which contains specifics about the wireless device 120, the network node 110 may in some embodiments adapt the configuration to these specifics. The configuration may include DL-RS resources on which the wireless device 120 is to perform measurements. The DL-RS resources may for example be expressed in terms of timefrequency resources or beam identities (beam IDs).

[0083] In particular, the network node 110 may transmit within step 1020 a triggering configuration which includes a trigger condition; the wireless device 120 shall be configured to evaluate the trigger condition and, if it is determined to be fulfilled transmit the UE-initiated time-domain predictive beam report (see step 1050 below). Additionally or alternatively, the network node 110 may transmit within step 1020 a report configuration to the wireless device, wherein the report configuration specifies a content of the UE-initiated time-domain predictive beam report; the wireless device 120 shall be configured to populate a corresponding set of fields in said report, and the network node 110 expects to receive it.

[0084] In such embodiments where no configuration is transmitted (i.e., where step 1020 is absent), the wireless device 120 may be configured to transmit the UE-initiated time-domain predictive beam report in accordance with a pre-agreed (standardized) specification.

[0085] In a third step 1030, the network node 110 causes the TRP 115 to transmit using two or more TRP beams associated with respective DL-RS resources or respective beam identities (beam IDs). The different DL-RS are transmitted in different TRP beams. The wireless device 120 performs measurements on these TRP beams.

[0086] Next, in a fourth step 1040, the wireless device 120 establishes an instance of the UE-initiated timedomain predictive beam report, which indicates a predicted quality or predicted relative quality of the TRP beams on which the measurements were performed. The predicted quality or predicted relative quality relates to one or more future time instances, i.e., these quantities are predictions targeting one or more future time instances. The wireless device 120 may indicate the maximum numbers of such future time instances that its supports to the network using the capability transmitted in the optional step 1010. It is understood that a "time instance” may be point-like, or it may be a period (i.e. have a nonzero duration).

[0087] Parts of the information in the beam report, particularly the predicted relative quality, may be indicated implicitly. For example, it suffices to explicitly indicate a best beam (i.e., the beam with highest predicted quality) if measurements were performed on two beams; this will allow a recipient of the beam report - including the network node 110 - to determine implicitly that the other beam has lower quality. It suffices to explicitly indicate one best beam even if measurements were performed on three or more beams, as this allows an inference that the two or more not-indicated beams have lower quality. The predicted quality may for example relate to predicted Reference Signal Received Power (RSRP), predicted signal to interference and noise ratio (SI NR) or predicted Reference Signal Received Quality (RSRQ). Further, the predicted quality can be expressed as a probability that the reported beam is the best beam (out of all the configured TRP beams associated with the triggered UE-initiated time-domain predictive beam report). Further still, the UE-initiated time-domain predictive beam report may express the predicted relative quality by indicating a future time instance at which the predicted relative quality of one of the candidate TRP beams will surpass (or will have surpassed) the predicted relative quality of a currently used TRP beam; according to this option, in other words, the future time instance is not fixed or preconfigured but it depends on the predicted quality of the TRP beams. Optionally, for the purpose of determining the time of surpassing, an offset is applied to the predicted performance metric of the currently used TRP beam.

[0088] The wireless device 120 establishes the UE-initiated time-domain predictive beam report on the basis of the measurements. This may include predicting the quality or the relative quality of the TRP beams using a conventional predictor, such as linear or nonlinear time-series extrapolation, or an observer (e.g., Kalman filter). Alternatively, the wireless device may execute step 1040 by predicting the quality or relative quality of the TRP beams using a trained machine-learning (or artificial-intelligence) model to process data from the measurements collected in step 1030.

[0089] In order to implement the latter option, the use of a machine-learning (ML) model having as its backbone a transformer, a convolutional neural network (CNN), or a recurrent neural network (RNN) is advisable. The ML model of any of these types may in particular be configured for predicting the channel in respect of a beam for acertain time-frequency resource. The expected performance of such predictor depends on several different aspects, for example time / frequency variation of channel due to UE mobility or changes in the environment. There are inherent correlations in time, frequency and the spatial domain of the channel, and an ML model can be trained to exploit such correlations. The spatial domain can comprise different beams, where the correlation properties partly depend on the how the TRP antennas form the different beams, and how UE forms the receiver beams. Such an ML based prediction model may be used to reduce the necessary amount of measurements that is needed to support beamforming.

[0090] For example, 3GPP TDoc RP-202650, "Study on Al based PHY layer enhancement for Rel-18", reports on an ML model that is claimed to eliminate up to 75% of the measurement time which is conventionally considered necessary for the task of predicting the best beam out of a subset of beams.

[0091] Another suitable implementation of the wireless device's 120 quality prediction may be derived from the applicant's prior disclosure WO2020226542A1 , which presents a method for predicting future beam quality values based on historical quality values. Based on received device data from measurement reports, the network can learn, for example, which sequences of signal quality measurements (e.g., RSRP measurements) lead to large signal quality drop events (e.g., turning around the certain street corners a built environment). This learning procedure can be enabled, for example, by dividing periodically reported RSRP data into a training window and a prediction window. In the example case of RSRP, a network owner may initiate training of the ML model by feeding a time series of field-measured, laboratory-measured or simulated RSRP for times... , tninto the model (e.g., neural network), which allows the model to learn the subsequent elements of the time series, namely, the RSRP at p > 1 future times tn+1, ... , tn+p. The times... , tnand tn+1, ... , tn+prespectively correspond to the training window and the prediction window. After the ML model has been trained, the network owner can make the model available for downloading to the wireless devices connecting to the network, thereby allowing the wireless devices to predict future RSRP values in a uniform manner. The ML model may additionally be trained with quantities representing further signal quality aspects. To provide synthetic data for the training, notably simulate, a simulation in accordance with a 3GPP 3D channel model (e.g., as described in 3GPP Technical Report 36.873 V12.2.0, "Study on 3D channel model for LTE”, July 2015) may be performed.

[0092] Still relating to step 1040, if time elapses between the measuring step 1030 and the present step 1040, then results of the measurements may have to be temporarily stored in a memory. The option of delaying step 1040 until after a trigger event (i.e., when it is known that the UE-initiated time-domain predictive beam report is to be transmitted) is advantageous since the beam report will then be established closer to the future time instance(s) to which it relates, so that supporting information that could improve the prediction may have become available. Delaying step 1040 until after a trigger event may have the further advantage of not wasting the effort of establishing a beam report whose transmission is not triggered until the measurements are so old that reliable prediction is no longer possible.

[0093] In a next step 1050 of the method 1000, the wireless device 120 transmits the UE-initiated time-domain predictive beam report to the network node 110, e.g., through the intermediary of a TRP 115. The UE-initiated time-domain predictive beam report may have the format of a CSI report according to the 3GPP NR specifications and transmitted on the same channels and uplink resources, although modified in such manner that the reported beam-related quantities are to be interpreted as predictions, and / or that the beam report is triggered by a condition in terms of predicted quality values. In future 3GPP releases, including future sixth-generation technology, the UE-initiated time-domain predictive beam report may have the format of a new type of beam report (CSI report) that is transmitted either on newly defined uplink channels or on legacy uplink channels (e.g., PUCCH, PUSCH) in this technology.

[0094] In some embodiments, the transmission 1050 of the UE-initiated time-domain predictive beam report is triggered by a determination by the wireless device that the predicted relative quality of a candidate TRP beam will surpass (i.e., become better than) the predicted relative quality of a currently used TRP beam. This determination may optionally be subject to a maximum delay, within which the surpassing shall occur, i.e., if the expected surpassing event is too distant in time, it cannot trigger the transmission of the UE-initiated time-domain predictive beam report. The maximum delay to be applied may be either a fixed constant from specification, or it may be a configurable setting controlled by the network.

[0095] In further embodiments of the method 1000, the transmission 1050 of the UE-initiated time-domain predictive beam report is triggered by a determination by the wireless device that, at one or more future time instances (point-like instances or periods with a nonzero duration), a predicted performance metric of a candidate TRP beam will be superior to a predicted performance metric of a currently used TRP beam. Optionally, for the purpose of the determination, an offset may be applied to the predicted performance metric of the currently used TRP beam. Further optionally, it may be required that the future time instances be closer in time than a maximum delay for the trigger condition to be considered fulfilled.

[0096] In further embodiments of the method 1000, the UE-initiated time-domain predictive beam report indicates a predicted performance metric of two or more candidate TRP beams for one or more future time instances. Additionally or alternatively, the UE-initiated time-domain predictive beam report may indicate a predicted performance metric of a currently used TRP beam for one or more future time instances. The performance metric may for example be predicted RSRP, predicted SINR, predicted RSRQ of a TRP beam or a probability that the TRP beam is the best beam.

[0097] After the network node 110 receives the UE-initiated time-domain predictive beam report, the execution flow of the method 1000 may then continue to a step 1060 where the network node 110 sends a response back to the wireless device 120 that confirms that it shall switch to a new beam, such as the currently best TRP beam indicated in the beam report. A step 1070 is then performed where the network node 110 and the wireless device 120 switch to said new beam and use it for communications in downlink or uplink or both. Optionally, step 1070 begins after some beam application time has elapsed.

[0098] In some embodiments of the method 1000, the capability transmitted in step 1010 may include one or more of the following indications: a) a maximum number of beams whose predicted quality or predicted relative quality the UE-initiated timedomain predictive beam report is to indicate for each of one or more future time instances; b) a maximum number of future time instances to which the UE-initiated time-domain predictive beam report relates; c) a maximum prediction window size; d) support of predictive beam reporting relating to joint uplink / downlink TCI operation; e) support of predictive beam reporting relating to joint downlink-only TCI operation; f) support of predictive beam reporting relating to joint uplink-only TCI operation; g) support of predictive beam reporting relating to separate uplink and downlink TCI operation; h) support of reporting predicted quality for a first set of beams while reporting measured quality for a second set of beams (where the first and second set of beams are disjoint, or partly overlapping).Relating to items d), e), f) and g), reference is made to section Overview of the TCI state framework in 3GPP NR Releases 17 above.

[0099] In some embodiments of the method 1000, the triggering configuration transmitted in step 1010 may indicate one or more of: a) a performance metric being one of predicted RSRP, predicted SI NR, predicted RSRQ or a probability that a TRP beam is a best beam, wherein the trigger condition is formulated in terms of the performance metric; b) an offset which the wireless device, for the purpose of evaluating the trigger condition, is to apply to the predicted performance metric of a currently used TRP beam when comparing it with a predicted performance metric of a candidate TRP beam; c) one or more future time instances at which the wireless device, for the purpose of evaluating the trigger condition, is to compare the predicted performance metric of a candidate TRP beam with the predicted performance metric of a currently used TRP beam, wherein optionally each of the future time instances has a nonzero duration; d) a maximum delay within which the predicted relative quality of one of the candidate TRP beams is to surpass the predicted relative quality of a currently used TRP beam for the trigger condition to be fulfilled (i.e., if the expected surpassing event is too distant in time, it cannot trigger the transmission of the UE- initiated time-domain predictive beam report); e) downlink reference signal resources or beam identities associated with the candidate TRP beams;f) downlink reference signal resources or a beam identity associated with a currently used TRP beam; g) an indication of an active trigger condition selected from a plurality of configured trigger conditions; h) a refractory period representing a minimum separation of two consecutive UE-initiated time-domain predictive beam reports.Item h) may be used to ensure that the UE-initiated time-domain predictive beam reports is not triggered too frequently, for thereby controlling the amount of overhead.

[0100] In some embodiments of the method 1000, the report configuration transmitted in step 1010 may indicate one or more of: a) a performance metric being one of predicted RSRP, predicted SI NR, predicted RSRQ of a TRP beam or a probability that the TRP beam is the best beam, wherein the UE-initiated time-domain predictive beam report shall indicate the performance metric for each candidate TRP beam; b) a number of future time instances such that the UE-initiated time-domain predictive beam report shall indicate the predicted quality or predicted relative quality of the TRP beams for each of the future time instances; c) an extent of a future time instance (e.g., start and end, start and duration, end and duration) such that the UE-initiated time-domain predictive beam report shall indicate the predicted quality or predicted relative quality of the TRP beams for the future time instance; d) a number of TRP beams for which the UE-initiated time-domain predictive beam report shall indicate the predicted quality or predicted relative quality for each of one or more future time instances; e) numbers N, M such that the UE-initiated time-domain predictive beam report shall indicate a predicted quality or predicted relative quality of (exactly) N beams for (exactly) M future time instances.Relating to item e), it may be pre-agreed or signaled that the UE-initiated time-domain predictive beam report shall indicate a predicted quality or predicted relative quality of exactly N beams for exactly M future time instances. Alternatively, it may be pre-agreed or signaled that the UE-initiated time-domain predictive beam report shall indicate a predicted quality or predicted relative quality of at most N beams for exactly M future time instances. Alternatively, it may be pre-agreed or signaled that the UE-initiated time-domain predictive beam report shall indicate a predicted quality or predicted relative quality of exactly N beams for at most M future time instances.

[0101] The aspects of the present disclosure have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

Claims

CLAIMS1. A method (1000) implemented in a wireless device (120) for facilitating a determination of at least one TRP beam to be used by a transmit-receive point, TRP (115) in a wireless network (110) in relation to the wireless device, the method comprising: performing (1030) measurements on two or more TRP beams associated with respective downlink reference signal resources; establishing (1040) a UE-initiated time-domain predictive beam report based on the measurements, wherein the UE-initiated time-domain predictive beam report indicates a predicted quality or predicted relative quality of the TRP beams; and transmitting (1050) the UE-initiated time-domain predictive beam report to a network node.

2. The method of claim 1, wherein the transmission (1050) of the UE-initiated time-domain predictive beam report is triggered by a determination by the wireless device that the predicted relative quality of a candidate TRP beam will surpass the predicted relative quality of a currently used TRP beam.

3. The method of claim 2, wherein the determination is subject to a maximum delay, within which the surpassing shall occur.

4. The method of any of the preceding claims, wherein the transmission (1050) of the UE-initiated timedomain predictive beam report is triggered by a determination by the wireless device that, at one or more future time instances, a predicted performance metric of a candidate TRP beam will be superior to a predicted performance metric of a currently used TRP beam, wherein optionally, for the purpose of the determination, an offset is applied to the predicted performance metric of the currently used TRP beam.

5. The method of any of the preceding claims, wherein a validity of the predicted quality or predicted relative quality begins a nonzero delay after completion of the measurements.

6. The method of any of the preceding claims, wherein the establishing (1040) of the UE-initiated timedomain predictive beam report includes predicting a quality or relative quality of the TRP beams, optionally using a trained machine-learning model to process data from the measurements (1030).

7. The method of any of the preceding claims, further comprising: receiving (1020) a triggering configuration from the network node, wherein the triggering configuration includes a trigger condition causing the transmission (1050) of the UE-initiated time-domain predictive beam report.

8. The method of any of the preceding claims, further comprising: receiving (1020) a report configuration from the network node, wherein the report configuration specifies a content of the UE-initiated time-domain predictive beam report.

9. The method of any of the preceding claims, further comprising: indicating (1010) to the network node a capability signifying that the wireless device supports a UE-initiated timedomain predictive beam report.

10. The method of any of the preceding claims, further comprising: receiving (1020) from the network node a configuration authorizing the wireless device to transmit UE-initiated time-domain predictive beam reports.

11. A method (1000) implemented in a network node of a wireless network (110) for facilitating a determination of at least one TRP beam to be used by at least one transmit receive point, TRP (115) in the wireless network in relation to a wireless device (120), the method comprising: transmitting (1020) to the wireless device a configuration authorizing the wireless device to transmit UE-initiated time-domain predictive beam reports; and receiving (1050) from the wireless device a UE-initiated time-domain predictive beam report, which indicates a predicted quality or predicted relative quality of two or more TRP beams associated with respective downlink reference signal resources.

12. The method of claim 11, further comprising: transmitting (1020) a triggering configuration to the wireless device, wherein the triggering configuration includes a trigger condition for causing the wireless device to transmit the UE-initiated time-domain predictive beam report.

13. The method of claim 11 or 12, further comprising: transmitting (1020) a report configuration to the wireless device, wherein the report configuration specifies a content of the UE-initiated time-domain predictive beam report.

14. The method of any of claims 11 to 13, further comprising: receiving (1010) from the wireless device a capability signifying that the wireless device supports a UE-initiated time-domain predictive beam report.

15. The method of claim 7 or 12, wherein the triggering configuration indicates one or more of: a) a performance metric being one of predicted RSRP, predicted SINR, predicted RSRQ or a probability that a TRP beam is a best beam, wherein the trigger condition is formulated in terms of the performance metric; b) an offset which the wireless device, for the purpose of evaluating the trigger condition, is to apply to the predicted performance metric of a currently used TRP beam when comparing it with a predicted performance metric of a candidate TRP beam; c) one or more future time instances at which the wireless device, for the purpose of evaluating the trigger condition, is to compare the predicted performance metric of a candidate TRP beam with the predictedperformance metric of a currently used TRP beam, wherein optionally each of the future time instances has a nonzero duration; d) a maximum delay within which the predicted relative quality of one of the candidate TRP beams is to surpass the predicted relative quality of a currently used TRP beam for the trigger condition to be fulfilled; e) downlink reference signal resources or beam identities associated with the candidate TRP beams; f) downlink reference signal resources associated with a currently used TRP beam; g) an indication of an active trigger condition selected from a plurality of configured trigger conditions; h) a refractory period representing a minimum separation of two consecutive UE-initiated time-domain predictive beam reports.

16. The method of claim 8 or 13, wherein the report configuration indicates one or more of: a) a performance metric being one of predicted RSRP, predicted SI NR, predicted RSRQ or a probability that a TRP beam a best beam, wherein the UE-initiated time-domain predictive beam report shall indicate the performance metric for each candidate TRP beam; b) a number of future time instances such that the UE-initiated time-domain predictive beam report shall indicate the predicted quality or predicted relative quality of the TRP beams for each of the future time instances; c) an extent of a future time instance such that the UE-initiated time-domain predictive beam report shall indicate the predicted quality or predicted relative quality of the TRP beams for the future time instance; d) a number of TRP beams for which the UE-initiated time-domain predictive beam report shall indicate the predicted quality or predicted relative quality for each of one or more future time instances.

17. The method of any of the preceding claims, wherein the report configuration indicates numbers N, M such that the UE-initiated time-domain predictive beam report shall indicate a predicted quality or predicted relative quality of N beams for M future time instances.

18. The method of any of the preceding claims, wherein the UE-initiated time-domain predictive beam report indicates a predicted performance metric of two or more candidate TRP beams for one or more future time instances.

19. The method of any of the preceding claims, wherein the UE-initiated time-domain predictive beam report indicates a predicted performance metric of a currently used TRP beam for one or more future time instances.

20. The method of any of the preceding claims, wherein the UE-initiated time-domain predictive beam report indicates a future time instance at which the predicted relative quality of one of the candidate TRP beams will surpass the predicted relative quality of a currently used TRP beam,wherein optionally, for the purpose of determining the time of surpassing, an offset is applied to the predicted performance metric of the currently used TRP beam.

21. The method of claim 9 or 14, wherein the capability indicates one or more of: a) a maximum number of beams whose predicted quality or predicted relative quality the UE-initiated timedomain predictive beam report is to indicate for each of one or more future time instances; b) a maximum number of future time instances to which the UE-initiated time-domain predictive beam report relates; c) a maximum prediction window size; d) support of predictive beam reporting relating to joint uplink / downlink Transmission Configuration Indicator, TCI, operation; e) support of predictive beam reporting relating to joint downlink-only TCI operation; f) support of predictive beam reporting relating to joint uplink-only TCI operation; g) support of predictive beam reporting relating to separate uplink and downlink TCI operation; h) support of reporting predicted quality for a first set of beams while reporting measured quality for a second set of beams.

22. The method of any of the preceding claims, wherein the UE-initiated time-domain predictive beam report is initiated by the wireless device.

23. The method of any of claims 10 to 22, wherein the configuration authorizing the wireless device to transmit UE-initiated time-domain predictive beam reports is transmitted (1020) from the network node to the wireless device in response to a request by the wireless device.

24. A wireless device (120) for facilitating a determination of at least one TRP beam to be used by a transmitreceive point, TRP (115) in a wireless network (110) in relation to the wireless device, the wireless device comprising processing circuitry (122) configured to: perform measurements on two or more TRP beams associated with respective downlink reference signal resources; establish a UE-initiated time-domain predictive beam report based on the measurements, wherein the UE- initiated time-domain predictive beam report indicates a predicted quality or predicted relative quality of the TRP beams; and transmit the UE-initiated time-domain predictive beam report to a network node.

25. A network node of a wireless network (110) for facilitating a determination of at least one TRP beam to be used by at least one transmit receive point, TRP (115) in the wireless network in relation to a wireless device (120), the network node comprising processing circuitry (112) configured to:transmit to the wireless device a configuration authorizing the wireless device to transmit UE-initiated timedomain predictive beam reports; and receive from the wireless device a UE-initiated time-domain predictive beam report, which indicates a predicted quality or predicted relative quality of two or more TRP beams associated with respective downlink reference signal resources.

26. A computer program (124) comprising instructions which, when run on processing circuitry (122) of a wireless device (120), cause the wireless device to perform the method (700) of any of claims 1 to 10 and 15 to 23.

27. A computer program (114) comprising instructions which, when run on processing circuitry (112) of a network node, cause the network node to perform the method (700) of any of claims 11 to 23.

28. A computer program product comprising the computer program (114, 124) of claim 26 or 27 and a computer-readable storage medium on which the computer program is stored.

Images