Method and apparatus for processing and transmitting beam tracking requests

Abstract

Embodiments of the present disclosure relate to methods, terminal devices and apparatuses for transmitting beam tracking requests, and methods, network devices and apparatuses for processing beam tracking requests. In embodiments of the present disclosure, the method for processing a beam tracking request may include: receiving a beam tracking request containing beam identification information; transmitting an acknowledgement as a response to the beam tracking request; and if an acknowledgment is transmitted as the acknowledgement, performing an operation corresponding to the beam tracking request. With embodiments of the present disclosure, a solution with reduced latency while maintaining beam operation reliability can be provided, which is particularly important for emergency situations.

Description

Technical Field

[0001] Non-limiting and exemplary embodiments of the present disclosure generally relate to the field of wireless communication technology, and more specifically to methods, terminal devices and apparatuses for transmitting beam tracking requests and methods, network devices and apparatuses for processing beam tracking requests. Background Art

[0002] The New Radio Access System (also known as the NR system or NR network) is the next generation communication system. At the Radio Access Network (RAN) #71 meeting of the 3rd Generation Partnership Project (3GPP) working group, the study of the NR system was approved. The NR system will consider the frequency range up to 100Ghz, and its goal is a single technical framework that can address all use cases, requirements and deployment scenarios defined in the technical report TR 38.913, which includes requirements such as enhanced mobile broadband, massive machine type communications, and ultra-reliable low-latency communications.

[0003] In 3GPP RAN1#90, it was agreed that there are two cases regarding beam failure. In the first case, beam failure is declared only when all serving control channels fail; in the second case, a subset of the serving control channels fails and this event also needs to be handled.

[0004] In a beam reporting instance, the UE may be configured to report N different transmit (Tx) beams that may be received simultaneously, and the UE may report N or fewer beams in a given reporting instance.

[0005] In addition, to improve the robustness of the Physical Downlink Control Channel (PDCCH), it is agreed to use multi-beam operation. For illustration purposes, Figure 1 Possible options for multi-beam operation are shown. Figure 1, three options using four possible configurations of control channel resource sets (CORESETs) (CORESET #1 to #4) are shown. In option 1, CONRESET #1 and #2 are multi-beam operations configured at the CORESET level, where in CONRESET #1, all physical downlink control channel (PDCCH) candidates #1 to #4 are carried on beam 1 represented by an ellipse filled with dots, and in CONRESET #2, all physical downlink control channel (PDCCH) candidates #1 to #4 are repeatedly carried on beam 2 represented by an ellipse filled with cross lines. In option 2, CORESET #3 is a multi-beam operation configured at the PDCCH level, where PDCCH candidates #1 and #2 are carried on beam 1 represented by an ellipse filled with dots, and PDCCH candidates #3 and #4 are carried on beam 2 represented by an ellipse filled with cross lines. In option 3, CORESET #4 is a multi-beam operation configured at the resource block group (RBG) or control channel element (CCE) level, where a portion of each of PDCCH candidates #1 to #4 is carried on beam 1 and another portion thereof is carried on beam 2.

[0006] In multi-beam operation, it is possible that only a subset of the serving control channels may fail, and in this case, partial beam failure needs to be handled.

[0007] In 3GPP technical document R1-1713420, a solution for improving beam tracking latency and reliability is disclosed. Figure 2 As shown in the figure, in the proposed solution, when the network detects a beam failure, or when a beam switching request is received from a terminal device, downlink control information (DCI) will be used as a beam switching signal to notify the terminal device of the beam switching; in response to the reception of the DCI, the terminal device transmits a positive acknowledgement (ACK) to the network within a time interval m; and within a predetermined time period S d After the expiration, the network and the terminal device simultaneously perform beam switching. In the disclosed solution, beam switching is performed only after ACK is transmitted from the terminal device to the network device, and the beam switching results in a long response time.

[0008] In the patent application publication WO2017 / 12306061A1, a beam tracking solution based on the random access channel (RACH) process is also proposed. Figure 3As shown, the terminal device can transmit a RACH preamble that can trigger beam change / switching, and the network sends an explicit beam change / switching instruction together with Msg4 or separately to instruct the terminal device to change the beam. This solution is suitable for the first beam failure situation, that is, all beams fail, and similarly, it may also cause additional processing delays. Summary of the invention

[0009] To this end, in the present disclosure, a new solution for beam tracking request is provided to alleviate or at least mitigate at least part of the problems in the prior art.

[0010] According to a first aspect of the present disclosure, a method for processing a beam tracking request is provided. The method may include: receiving a beam tracking request including beam identification information; transmitting an acknowledgement as a response to the beam tracking request; and if an acknowledgment is transmitted as the acknowledgement, performing an operation corresponding to the beam tracking request.

[0011] According to a second aspect of the present disclosure, a method for transmitting a beam tracking request is provided. The method may include transmitting a beam tracking request including beam identification information; receiving an acknowledgement as a response to the beam tracking request; and in response to receiving a positive acknowledgement as the acknowledgement, performing an operation corresponding to the beam tracking request.

[0012] According to a third aspect of the present disclosure, a network node is provided. The network node may include: a transceiver configured to receive a beam tracking request including beam identification information and transmit an acknowledgement as a response to the beam tracking request; and a processor configured to perform an operation corresponding to the beam tracking request if the transmission is a positive response to the acknowledgement.

[0013] According to a fourth aspect of the present disclosure, a terminal device is provided. The terminal device may include: a transceiver configured to transmit a beam tracking request containing beam identification information and receive a confirmation as a response to the beam tracking request; and a processor configured to perform an operation corresponding to the beam tracking request in response to receiving a positive response as the confirmation.

[0014] According to a fifth aspect of the present disclosure, a network device is provided. The network device may include a processor and a memory. The memory may be coupled to the processor and have a program code therein, which, when executed on the processor, causes the network device to perform the operation of the first aspect.

[0015] According to a sixth aspect of the present disclosure, a terminal device is provided. The terminal device may include a processor and a memory. The memory may be coupled to the processor and have a program code therein, which, when executed on the processor, causes the terminal device to perform the operation of the second aspect.

[0016] According to a seventh aspect of the present disclosure, there is provided a computer-readable storage medium having computer program code embodied thereon, the computer program code being configured to cause an apparatus to perform actions of the method according to any embodiment of the first aspect when executed.

[0017] According to an eighth aspect of the present disclosure, there is provided a computer-readable storage medium having computer program code embodied thereon, the computer program code being configured to cause an apparatus to perform actions of the method according to any embodiment of the second aspect when executed.

[0018] According to a ninth aspect of the present disclosure, there is provided a computer program product comprising the computer-readable storage medium according to the seventh aspect.

[0019] According to a tenth aspect of the present disclosure, there is provided a computer program product comprising the computer-readable storage medium according to the eighth aspect.

[0020] Utilizing embodiments of the present disclosure, a solution may be provided with reduced latency while maintaining reliability of beam operation, which is particularly important for emergency situations. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The above and other features of the present disclosure will become more apparent by describing in detail embodiments shown in the embodiments with reference to the accompanying drawings, in which the same reference numerals represent the same or similar components throughout the drawings, and in which:

[0022] Figure 1 Possible options for multi-beam operation are schematically shown;

[0023] Figure 2 Existing solutions for improving beam tracking latency and reliability are schematically shown;

[0024] Figure 3 schematically illustrates network-based beam tracking via a random access channel (RACH) procedure;

[0025] Figure 4 A flowchart of a method for processing a beam tracking request according to an embodiment of the present disclosure is schematically shown;

[0026] Figures 5A to 5E schematically illustrates example transmission options for an acknowledgement of a beam tracking request according to an embodiment of the present disclosure;

[0027] Figure 6 schematically illustrates possible signal paths according to an embodiment of the present disclosure;

[0028] Figures 7A to 7D schematically illustrates example operations corresponding to a beam tracking request according to an embodiment of the present disclosure;

[0029] Figure 8 A signaling diagram of a beam tracking process according to an embodiment of the present disclosure is schematically shown;

[0030] Figures 9A to 9C Schematically illustrating exemplary possible PDCCH transmission options according to an embodiment of the present disclosure;

[0031] Fig. 10A and 10B schematically illustrates an example beam set update according to an embodiment of the present disclosure;

[0032] Fig.11 schematically illustrates an example failed beam indication according to an embodiment of the present disclosure;

[0033] Fig. 12A and 12B schematically illustrates an example beam quality indication according to an embodiment of the present disclosure;

[0034] Fig.13 A flowchart of a method for transmitting a beam tracking request according to an embodiment of the present disclosure is schematically shown;

[0035] Fig.14 A block diagram of an apparatus for processing a beam tracking request according to an embodiment of the present disclosure is schematically shown;

[0036] Fig.15 A block diagram schematically shows an apparatus for transmitting a beam tracking request according to an embodiment of the present disclosure; and

[0037] Fig.16 A simplified block diagram of an apparatus 1610 as described herein that may be implemented as or included in a network device such as a gNB and an apparatus 1620 that may be implemented as or included in a terminal device such as a UE is schematically shown. DETAILED DESCRIPTION

[0038] Hereinafter, the solutions provided in the present disclosure will be described in detail by way of embodiments with reference to the accompanying drawings. It should be understood that these embodiments are only provided to enable those skilled in the art to better understand and implement the present disclosure, and are not intended to limit the scope of the present disclosure in any way.

[0039] In the accompanying drawings, various embodiments of the present disclosure are shown in block diagrams, flow charts and other figures. Each box in the flow chart or block diagram can represent a module, program or code portion containing one or more executable instructions for performing a specified logical function, and in the present disclosure, non-essential boxes are shown with dotted lines. In addition, although these boxes are shown in a specific order for the steps of the execution method, in fact, they do not necessarily have to be strictly executed in the order shown. For example, they can be executed in reverse order or simultaneously, depending on the nature of the corresponding operation. It should also be noted that each box in the block diagram and / or flow chart and a combination thereof can be implemented by a dedicated hardware-based system for performing a specified function / operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0040] In general, unless otherwise expressly defined herein, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field. Unless otherwise expressly indicated, all references to "a / an / the / said [element, device, component, means, step, etc.]" should be openly interpreted as referring to at least one instance of the element, device, component, means, unit, step, etc., without excluding a plurality of such devices, components, means, units, steps, etc. In addition, the indefinite article "a / an" used herein does not exclude a plurality of such steps, units, modules, devices, objects, etc.

[0041] In addition, in the context of the present disclosure, a user equipment (UE) may refer to a terminal, a mobile terminal (MT), a subscriber station, a portable subscriber station, a mobile station (MS) or an access terminal (AT), and some or all functions of the UE, terminal, MT, SS, portable user station, MS or AT may be included. In addition, in the context of the present disclosure, the term "BS" may refer to, for example, a Node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), a gNB (next generation Node B), a radio head (RH), a remote radio head (RRH), a relay or a low power node (such as a femto, a pico, etc.).

[0042] As described in the background, the existing solution is a network-based beam switching solution, which may cause additional processing delays. To this end, in the present disclosure, a new solution for beam tracking requests for reducing processing delays is proposed. In the proposed solution, a request and grant mode will be adopted, in which an explicit "grant" for a beam tracking request can enable the corresponding operation to be performed without additional delays.

[0043] In the following, further reference will be made to Figures 4 to 16The solution proposed in the present disclosure is described in detail. It should be understood that the following embodiments are given for illustrative purposes only, and the present disclosure is not limited thereto.

[0044] First reference Figure 4 , Figure 4 A flowchart of a method for processing a beam tracking request according to an embodiment of the present disclosure is schematically shown. The method 400 may be performed at a network device or a network node (e.g., a gNB or other similar network device).

[0045] like Figure 4 As shown, first in step 401, the network device may receive a beam tracking request from the terminal device. During beam monitoring, the terminal device may detect that a service beam fails, a new beam exists, or a beam switch from a degraded beam to a better beam is required, etc. In this case, the terminal device may transmit a beam tracking request to the network device. The beam tracking request may include beam identification information so that the network can be informed of the operation corresponding to the beam tracking request that can be performed. The beam identification information may include, for example, a faulty beam ID, a new beam ID, or both. As needed, the beam tracking request may also include beam tracking type information. If the beam tracking request only contains beam identification information, the beam tracking type information may not be explicitly transmitted when a default beam tracking type exists. Types of beam tracking requests include, but are not limited to: (1) a beam switching request from a degraded serving beam to a better beam; (2) a request to remove a faulty beam from the current serving beam set; (3) a request to add a new beam to the current serving beam set; (4) a beam recovery request without further beam management, where beam recovery recovers a downlink faulty beam by using a new beam provided by the terminal device. The beam tracking request may be transmitted on a physical uplink control channel (PUCCH). As another example, the beam tracking request may also be transmitted on a physical random access channel (PRACH).

[0046] Next, in step 402, the network device may transmit an acknowledgment as a response to the beam tracking request. Upon receiving the beam tracking request, if the network device decides to perform an operation corresponding to the beam tracking request, the network device will immediately transmit a positive acknowledgment of the beam tracking request to the terminal device. The positive acknowledgment may be, for example, a positive acknowledgement (ACK). If the network decides not to perform any operation corresponding to the beam tracking request, the network may transmit a negative acknowledgement (NACK) to explicitly notify the terminal device, or simply not transmit anything to implicitly notify the terminal device. In the following, for illustrative purposes, ACK will be taken as an example of acknowledgment, and those skilled in the art will appreciate that some descriptions of ACK may also be applied to NACK.

[0047] In an embodiment of the present disclosure, the confirmation may be transmitted in a physical downlink control channel (PDCCH). Figure 5A As shown, the beam tracking request can be carried by PUCCH or PRACH, and the ACK can be included in the DCI on PDCCH. In this case, there are several options for carrying ACK / NACK.

[0048] In one option, ACK can be indicated by a PDCCH scrambled with a terminal device identity, without any other content such as time advance (TA), resource allocation (RA), quasi co-location (QCL) indicator. In other words, if the terminal device successfully descrambles the PDCCH, this indicates an ACK for the previously transmitted beam tracking request. The terminal device identity used to scramble / descramble the PDCCH can be a dedicated identity used only for beam tracking purposes, or the identity can be reused for other purposes. In addition, the terminal device identity can be determined based on a specific random sequence, time-frequency resource allocation, or CRC code, etc.

[0049] In another option, ACK / NACK can be indicated by using a bit corresponding to the target terminal device in a PDCCH scrambled with a common identity of a group of terminal devices (e.g., DCI format 3 in LTE). The DCI carried by the PDCCH contains multiple bit fields, each bit field is dedicated to one of the terminal devices in the group. Therefore, the group of terminal devices can receive the PDCCH, and each terminal device can obtain its ACK / NACK on the bit field dedicated to the terminal device.

[0050] In another option, a new bit may be added in the DCI of the PDCCH, where the DCI may contain other content such as TA, RA or a quasi configuration (QCL) indicator. In other words, ACK / NACK may be indicated by a new bit in the DCI of the PDCCH.

[0051] In yet another option, the ACK may be indicated by repeating the information of the beam tracking request in the PDCCH. In other words, the beam tracking request may be retransmitted in the PDCCH so that it may contain the same information as that contained in the beam tracking request so that the terminal device can identify it as an ACK for the beam tracking request.

[0052] Figure 5B Schematically illustrates another example transmission option for confirmation of a beam tracking request according to an embodiment of the present disclosure. Figure 5B As shown, the beam tracking request can be carried by PUCCH or PRACH, and the ACK can be included in the DCI of PDCCH; however, Figure 5AThe difference is that the PDCCH contains two parts, one of which contains the newly added bits for ACK of the PUCCH, and the other is the DCI for other purposes.

[0053] Figure 5C Another example transmission option for confirmation of a beam tracking request according to an embodiment of the present disclosure is schematically shown. Figure 5C In the MAC-CE, the beam tracking request can be carried by PUCCH or PRACH, and the ACK for the beam tracking request can be carried in MAC-CE to notify the terminal device of the confirmation.

[0054] Figure 5D Schematically illustrates another example transmission option of a confirmation of a beam tracking request according to an embodiment of the present disclosure. Figure 5D In the case of a beam tracking request, the beam tracking request can be carried by PUCCH or PRACH, and if there is no uplink data transmission, the ACK for the beam tracking request can be carried in the Physical Hybrid ARQ Indicator Channel (PHICH). In this case, the downlink resources of the PHICH to the terminal device can be based on the resource allocation of its PUCCH and the ID of the DMRS.

[0055] Figure 5E Schematically illustrates another example transmission option of a confirmation of a beam tracking request according to an embodiment of the present disclosure. Figure 5E In the embodiment of the present invention, the beam tracking request and the uplink data are transmitted simultaneously, and the confirmation of both transmissions is required. In this case, the beam tracking request can be carried by PUCCH or PRACH, and the ACK for the beam tracking request and the ACK for the uplink data transmission on PUSCH can be carried by PHICH and PDCCH, respectively. For example, the confirmation of the beam tracking request can be transmitted on PDCCH, and the confirmation of the uplink data transmission on PUSCH can be transmitted on PHICH. As another example, the confirmation of the beam tracking request can be transmitted on PHICH, and the confirmation of the uplink data transmission on PUSCH is transmitted on PDCCH.

[0056] The beam tracking request and the confirmation of the uplink data transmission may also be transmitted in another manner. For example, the confirmation of the beam tracking request may be multiplexed with the confirmation of the uplink data transmission on the PUSCH. The multiplexing may use either frequency division multiplexing or code division multiplexing.

[0057] In addition, the confirmation of the beam tracking request and the confirmation of the uplink data transmission can be bundled together. In other words, the confirmation of the beam tracking request can also indicate the confirmation of the uplink data transmission on the PUSCH. For illustration purposes, two example bundling settings A and B are given.

[0058] Setting A:

[0059] 1. Data ACK + beam tracking request ACK = ACK

[0060] 2. Data NACK + beam tracking request NACK = NACK

[0061] 3A. Data NACK + beam tracking request ACK = NACK

[0062] 4A. Data ACK + beam tracking request NACK = ACK

[0063] Setting B:

[0064] 1. Data ACK + beam tracking request ACK = ACK

[0065] 2. Data NACK + beam tracking request NACK = NACK

[0066] 3B. Data NACK + beam tracking request ACK = ACK

[0067] 4B. Data ACK + beam tracking request NACK = NACK

[0068] The selection of setting A or setting B may be configured by radio resource control (RRC) signaling to the terminal device. The network device may send an acknowledgement by using the configured setting, and thus the terminal device may interpret the acknowledgement based on the setting configured by the RRC signaling.

[0069] It should be understood that for the bundling setting and resource multiplexing as described above, the acknowledgment of uplink data and beam tracking request can have the same or different priorities, and the PUCCH carrying the beam tracking request and the PUSCH carrying the uplink data should be located in the same time slot. In addition, it can also be understood that the ACK can be on the PHICH or on the PDCCH.

[0070] Reference again Figure 4 In step 403, if an ACK is transmitted as a response to the beam tracking request, the network performs an operation corresponding to the beam tracking request. The operation may include beam switching, failed beam removal, new beam addition, beam recovery without further beam management, or any other predefined beam tracking type. Figure 6 Describe these operations.

[0071] Figure 6 Schematically illustrates possible signal paths according to an embodiment of the present disclosure. Figure 6As can be seen in the figure, a good path is a desired signal path, an unimportant path is a possible path, but it will not cause serious system impact; and a bad path is an undesirable path, which may cause serious system impact. In order to solve this problem, some improved schemes are proposed. For example, NACK may not be explicitly transmitted from the network device to the terminal device. Therefore, no ACK or no transmission at the terminal device can be understood as NACK. As another example, a beam tracking request transmitted in the uplink control information (UCI) of the PUCCH may be accompanied by a CRC. Therefore, the network can perform a CRC check to detect decoding errors, thereby avoiding the possibility of incorrect reception, which in turn prevents the sending of possible misleading confirmations as a response to the beam tracking request from the terminal device. In addition, the network device can also repeat the beam tracking request of the terminal device in the DCI of the PDCCH. In this way, the possibility of misunderstanding on the terminal device will be reduced accordingly.

[0072] Figures 7A to 7D Further schematically illustrated are example operations performed corresponding to different types of beam tracking requests according to an embodiment of the present disclosure. Fig. 7A FIG. 2 shows a beam switching operation corresponding to a type of beam tracking request according to an embodiment of the present disclosure. Fig. 7A As shown, in response to the beam tracking request, the transmission will be switched from a beam with lower channel quality in the serving beam subset to another beam with better channel quality in the serving beam subset. Figure 7B FIG. 2 shows a failed beam removal operation corresponding to another type of beam tracking request according to an embodiment of the present disclosure. Figure 7B As shown, in response to the beam tracking request, the failed beam in the serving beam subset indicated by the beam tracking request is removed from the serving beam subset. Figure 7C FIG. 2 shows a new beam adding operation corresponding to another type of beam tracking request according to an embodiment of the present disclosure. Figure 7C As shown, in response to a beam tracking request, a new beam with good channel quality will be added to the serving beam subset. Fig.7D FIG. 4 shows a beam recovery operation corresponding to a beam tracking request without further beam management according to an embodiment of the present disclosure. Fig.7DAs shown, in response to a beam tracking request, a new beam with good channel quality will replace the faulty beam for downlink transmission in the service beam subset. The beam tracking request may include beam identification information, and as required, it may also include beam tracking type information that specifies the exact beam tracking type to the network device. The beam tracking type information may be information for indicating beam switching, removal of a faulty beam, addition of a new beam, beam recovery operations without further beam management, and any other pre-configured beam tracking types. The set of pre-configured beam tracking types may be configured by RRC signaling to the terminal device. One of the beam tracking types may be implicitly set to the default beam tracking type, or the RRC signaling may explicitly configure one of the beam tracking types as the default type. For example, a beam recovery request may be the default at both the network device and the terminal device. In this case, the beam tracking request may include only the beam identification information, and in response to the beam tracking request, the default beam tracking type will be performed at both the network device and the terminal device.

[0073] It can be understood that the beam tracking operation can be requested on the UCI in the PUCCH through the beam tracking request, and the beam tracking operation can be confirmed in the PDCCH or PHICH. In addition, a subset of beams without failure can be used to deliver necessary DL signaling.

[0074] Figure 8 The signaling diagram of the beam tracking process according to an embodiment of the present disclosure is schematically shown. Figure 8 As shown, first in step 801, a terminal device such as a UE performs beam monitoring. Once it is determined based on beam monitoring that it is necessary to send a beam tracking request, at step 802, the UE sends a beam tracking request with at least a beam ID to the network, gNB. Upon receiving the beam tracking request, the gNB sends an ACK as a response to the UE request at step 803 as needed. The response signaling will be offloaded to the surviving DL beams. At the same time, the UE may expect to receive responses only about the surviving DL beams. For example, an ACK signal will be transmitted on one of the surviving beams requested by the UE. After a preconfigured time offset from the start of ACK transmission / reception, beam tracking operations can be performed simultaneously at the network device and the terminal device. The preconfigured time offset can be configured through RRC signaling or MAC CE signaling.

[0075] In this case, the gNB needs to perform other operations. For example, it can turn on / off COREST #1 or #2, such as Fig.9A As shown; it can choose to reschedule PDCCH candidates at the PDCCH level, such as Fig. 9B As shown; or alternatively, the gNB can reallocate PDCCH candidate resources at the CCE or RGB level, such as Fig. 9C shown.

[0076] In addition, the proposed solution can achieve flexible beam set update between two periodic full reports. Fig. 10A As shown in FIG. 1 , when the service beam subset includes the required number of beams, the terminal device can send a beam tracking request (1001a) to remove the faulty beam when there is a faulty beam, and send another beam tracking request (1002a) to add a new beam when there is a new beam with good channel quality. Fig. 10B In another embodiment shown, when the service beam subset contains fewer beams than required, when there is a new beam with good channel quality, the terminal device can first issue a beam tracking request (1001b) to add the new beam, and when there is a faulty beam, send another beam tracking request to remove the faulty beam (1002b). Through a simple atomic operation, the service beam subset can be updated in a flexible manner.

[0077] In an embodiment of the present disclosure, the beam identification information included in the beam tracking request can be indicated in a more efficient manner. For example, the UCI can have a UCI field 1, which is used to indicate the failed serving beam through a low-overhead bitmap. In the proposed indication scheme, the beam identification information indicates the beam identification based on the serving beam set. For example, the bitmap only refers to the current serving beam subset, that is, the serving subset previously reported or acknowledged. For example, Fig.11 As shown, there are 8 beams, so the entire beam set = {1, 2, 3, 4, 5, 6, 7, 8}; and there are only four serving beams, so the current serving beam subset = {1, 4, 5, 8}. If beams 4 and 5 fail, the bitmap can be 0 1 1 0, indicating the second and third beams in the current serving beam set, regardless of the entire beam set. In this way, a bitmap with only 4 bits is sufficient. It should be understood that the bitmap can be used to indicate both the working beam and the new beam.

[0078] In another embodiment of the present disclosure, another UCI field 2 containing beam channel quality information may also be provided to the UCI, and the beam channel quality information is indicated by a beam quality mode, which represents the quality relationship of the reported beam relative to the surviving beams in the serving beam set.

[0079] The term "beam quality pattern" used in this document is a pattern indicating the quality relationship of each beam relative to a beam quality threshold. Specifically, the beam quality pattern may indicate a threshold range in which each beam is located. Therefore, unlike existing solutions, information about the beam quality pattern may be transmitted to a network device to provide rough information about the beam quality.

[0080] The term "beam quality" used herein refers to information that can reflect the channel quality of the beam, and may also be referred to in other ways, such as beam measurement quantity, beam measurement value, CQI of the beam, etc. As an example, the beam quality may be indicated by the reference signal received power (RSRP) of the beam. In the following, RSRP is taken as an example of beam quality information. However, it can be easily understood by those skilled in the art that this is given for illustrative purposes only, and the present disclosure is not limited thereto, and in practice, any other measurement may be used to reflect the beam quality.

[0081] For example, the UCI field in the PUCCH carrying the beam tracking request may contain the new serving beam ID and optional beam channel quality ranking information. The ranking information may also contain two parts: the ranked subset and the beam quality mode. The beam quality mode may be determined based on the beam quality of the surviving beams in the serving beam set. Specifically, the beam quality of the surviving beams may be used as the beam quality threshold. Fig. 12A As shown, there are four non-serving nodes {2, 3, 6, 7}, and beam {3, 6} is a new beam to be added to the serving beam subset. The sorted subset may be {10, 01}, and the RSRP values ​​T1 and T2 of the surviving beams 1 and 8 may be used as the beam quality thresholds for the beam quality mode. Fig. 12B As further shown in FIG12 , there are four possible beam quality relationships between the two beams. The terminal device may determine the mode of beams 4 and 5 and include it in UCI field 2. For the example shown in FIG12 , the mode is mode B, which may be represented by 10, for example. After receiving this information, the gNB may learn the sorting information included in the UCI based on the reference thresholds T1 and T2.

[0082] In an embodiment of the present disclosure, possible RSRP tables for different reference signals (RS) are also proposed. In the proposed solution, different RSRP dynamic ranges can be used for different reference signals. For example, a synchronization signal block may have a smaller RSRP dynamic range than a periodic channel state information (P-CSI) RS, and a periodic CSI RS has a smaller RSRP dynamic range than an aperiodic channel state information (AP-CSI) RS. For illustrative purposes, Tables 1 to 3 give exemplary RSRP tables. A smaller dynamic range corresponding to a smaller number of RSRP states can result in less RSRP reporting overhead from a terminal device to a network device.

[0083] Table 1 RSRP report mapping for AP-CSI

[0084] AP-CSI RSRP(dBm) RSRP_00 RSRP<-140 RSRP_01 -140≤RSRP<-139 … … RSRP_96 -45≤RSRP<-44 RSRP_97 -44≤RSRP

[0085] Table 2 RSRP report mapping for P-CSI

[0086] P-CSI RSRP(dBm) RSRP_00 RSRP<-140 RSRP_01 -140≤RSRP<-139 … … RSRP_64 -77≤RSRP<-76 RSRP_65 -76≤RSRP

[0087] Table 3 RSRP report mapping for SSB

[0088] P-CSI RSRP(dBm) RSRP_00 RSRP<-140 RSRP_01 -140≤RSRP<-139 … … RSRP_64 -77≤RSRP<-76 RSRP_65 -76≤RSRP

[0089] Therefore, in the proposed solution, the terminal device will select the RSRP report mapping based on the type of reference signal. On the network side, after receiving the RSRP index, the gNB first determines the RSRP mapping table to be used based on the type of reference signal, and then uses the RSRP index to obtain the reported RSRP value from the determined mapping table.

[0090] In another embodiment of the present disclosure, only one standard RSRP table may be used, but different reference signals only use RSRP indexes corresponding to their corresponding threshold ranges. In addition, for different types of reference signals, it is also possible to use different offset values. For example, Table 1 may be provided as a standard mapping table, and for SSB, the standard mapping table may be used; and for P-CSI, a shift value of 10 dBm may be applied to each RSRP threshold to obtain a new table for P-CSI. Alternatively, the same standard table may be used, but the corresponding shift value may be applied to the RSRP value each time to obtain a modified RSRP value for P-CSI.

[0091] Fig.13 The flowchart of a method 1300 for transmitting a beam tracking request according to an embodiment of the present disclosure is schematically shown. The method 1300 may be executed at a terminal device (eg, a UE or other similar terminal device).

[0092] like Fig.13As shown, first in step 1301, the terminal device can transmit a beam tracking request containing beam identification information. On the terminal device side, the terminal device can monitor all beams, and if the trigger condition is met, the terminal device can transmit a beam tracking request to the network device. The beam tracking request may include beam identification information so that the network can know the operation to be performed corresponding to the beam tracking request. The beam identification information may include, for example, a faulty beam ID, a new beam ID, or both. As needed, the beam tracking request may also include beam tracking type information. When there is a default beam tracking type of beam tracking request containing only beam identification information, the beam tracking type information may not be transmitted in the beam tracking request. The types of beam tracking requests include, but are not limited to: (1) a beam switching request from a degraded service beam to a better beam; (2) a request to remove a faulty beam from the current service beam set; (3) a request to add a new beam to the current service beam set; (4) a beam recovery request without further beam management, where beam recovery recovers the downlink faulty beam by using a new beam provided by the terminal device. The beam tracking request may be transmitted on the physical uplink control channel (PUCCH). As another example, the beam tracking request may also be transmitted on the physical random access channel (PRACH).

[0093] Next, at step 1302, the terminal device may receive an acknowledgement as a response to the beam tracking request. Upon receiving the beam tracking request, if the network decides to perform an operation corresponding to the beam tracking request, the network will immediately transmit a positive acknowledgement of the beam tracking request to the terminal device. In this case, the terminal device may receive the acknowledgement of the beam tracking request from the network device. The positive acknowledgement may be, for example, an ACK. As needed, the network may transmit a NACK to explicitly notify the terminal device, or transmit nothing to implicitly notify the terminal device.

[0094] The acknowledgement may be received in the PDCCH. For example, the acknowledgement may be indicated by any PDCCH scrambled with a terminal device identifier. As an example, the acknowledgement may be indicated by a bit corresponding to the target terminal device in a PDCCH scrambled with a common identifier for a group of terminal devices. As another example, the acknowledgement may be indicated by a new bit in the downlink control information (DCI) of the PDCCH. As another example, the acknowledgement may be indicated by repeating the information of the beam tracking request in the PDCCH. For details on the acknowledgement transmission options on the PDCCH, please refer to Figures 5A to 5E .

[0095] The confirmation may also be performed by the MAC CE. In addition, the PHICH may also be used for confirmation. For example, the confirmation of the beam tracking request may be transmitted on the PHICH, and the confirmation of the uplink data transmission on the PUSCH may be transmitted on the PDCCH. As another example, the confirmation of the beam tracking request may be transmitted on the PDCCH, and the confirmation of the uplink data transmission on the PUSCH may be transmitted on the PHICH.

[0096] The acknowledgement may also be multiplexed with an acknowledgement of uplink data transmission on a physical uplink shared channel (PUSCH) in either frequency division multiplexing or code division multiplexing. In addition, the acknowledgement may be bundled with an acknowledgement of uplink data transmission on the PUSCH. In other words, the acknowledgement may also indicate an acknowledgement of uplink data transmission on the PUSCH.

[0097] To prevent signals from bad paths, there are several schemes. In an embodiment of the present disclosure, the confirmation may include only a positive acknowledgement to the beam tracking request, and any negative acknowledgement to the beam tracking request is not transmitted. In another embodiment of the present disclosure, a cyclic redundancy check (CRC) code is used to transmit the beam tracking request. In addition, the beam tracking request may be retransmitted in the PDCCH.

[0098] In another embodiment of the present disclosure, a beam tracking request is transmitted between two full beam reports to provide flexible serving beam update.

[0099] In another embodiment of the present disclosure, the beam tracking request further includes beam channel quality information, and the beam channel quality information is indicated by a beam quality mode, which indicates the quality relationship of the reported beam relative to the surviving beams in the serving beam set. Through the beam quality mode, RSRP can be effectively reported.

[0100] In response to the reception of the ACK, at step 1303, the terminal device may perform an operation corresponding to the beam tracking request in response to receiving the positive acknowledgement as confirmation. The beam tracking request corresponds to any of the following operations: beam switching; failed beam removal; new beam addition; and beam restoration without further beam management.

[0101] In the above, the above reference Fig.13 An embodiment of a method for receiving a beam tracking request is briefly described. However, it can be understood that the operation at the terminal device corresponds to the operation at the network device, so for some operation details, reference can be made to Figure 4 to 1 2 Description.

[0102] Fig.14A block diagram of an apparatus for processing a beam tracking request according to an embodiment of the present disclosure is schematically shown. Apparatus 1400 may be implemented at a network device such as a gNB.

[0103] like Fig.14 As shown, the apparatus 1400 may include a request receiving module 1401, a confirmation transmission module 1402, and an operation execution module 1403. The request receiving module 1401 may be configured to receive a beam tracking request including beam identification information. The confirmation transmission module 1402 may be configured to transmit a confirmation as a response to the beam tracking request. If a positive response as a confirmation is transmitted, the operation execution module 1403 may be configured to perform an operation corresponding to the beam tracking request.

[0104] In an embodiment of the present disclosure, the acknowledgement may be transmitted in any one of the following: PDCCH; MAC CE; and PHICH.

[0105] In another embodiment of the present disclosure, the acknowledgement may be multiplexed with the acknowledgement of the uplink data transmission on the PUSCH in any one of frequency division multiplexing or code division multiplexing.

[0106] In another embodiment of the present disclosure, the confirmation may also indicate confirmation of uplink data transmission on the PUSCH.

[0107] In another embodiment of the present disclosure, confirmation can be indicated by any one of the following: a PDCCH scrambled by a terminal device identifier; a bit corresponding to a target terminal device in a PDCCH scrambled by an identifier shared by a group of terminal devices; a new bit in the downlink control information of the PDCCH; and information of a repeated beam tracking request in the PDCCH.

[0108] In another embodiment of the present invention, the confirmation may include only a positive acknowledgement of the beam tracking request, and any negative acknowledgement of the beam tracking request is not transmitted.

[0109] In another embodiment of the present disclosure, the beam tracking request may include a CRC code.

[0110] In an embodiment of the present disclosure, a beam tracking request may be received between two full beam reports.

[0111] In another embodiment of the present disclosure, the beam identification information may indicate a beam identification based on a serving beam set.

[0112] In an embodiment of the present disclosure, the beam tracking request may also include beam channel quality information. The beam channel quality information may be indicated by a beam quality mode, which indicates the quality relationship of the reported beam relative to the surviving beams in the serving beam set.

[0113] In an embodiment of the present disclosure, a beam tracking request may correspond to any of the following operations: beam switching; failed beam removal; new beam addition; and beam restoration without further beam management.

[0114] Fig.15 The block diagram of the apparatus for receiving a beam tracking request according to an embodiment of the present disclosure is schematically shown. The apparatus 1500 may be implemented at a terminal device such as a UE.

[0115] like Fig.15 As shown, the apparatus 1500 may include a request transmission module 1501, a confirmation receiving module 1502, and an operation execution module 1503. The request transmission module 1501 may be configured to transmit a beam tracking request including beam identification information. The confirmation receiving module 1502 may be configured to receive a confirmation as a response to the beam tracking request. If a positive response as a confirmation is transmitted, the operation execution module 1503 may be configured to perform an operation corresponding to the beam tracking request.

[0116] In an embodiment of the present disclosure, the acknowledgement may be received in any one of the PDCCH, MAC CE, and PHICH.

[0117] In another embodiment of the present disclosure, the acknowledgement may be multiplexed with the acknowledgement of the uplink data transmission on the PUSCH in any one of frequency division multiplexing or code division multiplexing.

[0118] In another embodiment of the present disclosure, the confirmation may also indicate confirmation of uplink data transmission on the PUSCH.

[0119] In another embodiment of the present disclosure, confirmation can be indicated by any one of the following: a PDCCH scrambled by a predetermined terminal device identifier; a bit corresponding to the target terminal device in a PDCCH scrambled by an identifier shared by a group of terminal devices; a new bit in the downlink control information of the PDCCH; and information of a repeated beam tracking request in the PDCCH.

[0120] In yet another embodiment of the present disclosure, the confirmation may include only a positive acknowledgement of the beam tracking request, and any negative acknowledgement of the beam tracking request is not transmitted.

[0121] In another embodiment of the present disclosure, the beam tracking request may be transmitted using a CRC code.

[0122] In another embodiment of the present disclosure, a beam tracking request may be transmitted between two full beam reports.

[0123] In yet another embodiment of the present disclosure, the beam identification information may indicate a beam identification based on a serving beam set.

[0124] In yet another embodiment of the present disclosure, the beam tracking request may further include beam channel quality information, and the beam channel quality information is indicated by a beam quality mode, which represents the quality relationship of the reported beam relative to the surviving beams in the serving beam set.

[0125] In another embodiment of the present disclosure, the beam tracking request may correspond to any of the following operations: beam switching; failed beam removal; new beam addition; and beam restoration without further beam management.

[0126] In the above, reference Fig.14 and 15 The apparatuses 1400 and 1500 are briefly described. It should be noted that the apparatuses 1400 and 1500 may be configured to implement the Figures 4 to 13 Therefore, for details on the operation of the modules in these devices, please refer to the Figures 4 to 13 The individual steps of the method are described below.

[0127] It should also be noted that the components of apparatuses 1400 and 1500 may be embodied in hardware, software, firmware and / or any combination thereof. For example, the components of apparatuses 1400 and 1500 may be implemented by circuits, processors or any other suitable selection devices, respectively.

[0128] Those skilled in the art will understand that the above examples are for illustration only and not limitation, and the present disclosure is not limited thereto; many changes, additions, deletions and modifications can be easily conceived from the teachings provided herein, and all such changes, additions, deletions and modifications fall within the scope of protection of the present disclosure.

[0129] In addition, in some embodiments of the present disclosure, the apparatuses 1400 and 1500 may include at least one processor. As an example, the at least one processor suitable for use with the embodiments of the present disclosure may include general-purpose processors and special-purpose processors known or developed in the future. The apparatuses 1400 and 1500 may also include at least one memory. The at least one memory may include, for example, semiconductor memory devices such as RAM, ROM, EPROM, EEPROM, and flash memory devices. The at least one memory may be used to store a computer-executable instruction program. The program may be written in any high-level and / or low-level compatible or interpretable programming language. According to an embodiment, the computer-executable instructions may be configured to cause the apparatuses 1400 and 1500 to perform at least one operation according to reference 1, respectively, together with the at least one processor. Figures 4 to 13 Discuss the methods to perform the operation.

[0130] Fig.16Further shown is a simplified block diagram of an apparatus 1610 as described herein that can be embodied as or included in a network device such as a base station (gNB) in a wireless network and an apparatus 1620 that can be embodied as or included in a terminal device such as a UE.

[0131] The device 1610 includes at least one processor 1611 (such as a data processor (DP)) and at least one memory (MEM) 1612 coupled to the processor 1611. The device 1610 may also include a transmitter TX and a receiver RX 1613 coupled to the processor 1611, and the transmitter TX and the receiver RX 1613 may be operable to be communicatively connected to the device 1620. The MEM 1612 stores a program (PROG) 1614. The PROG 1614 may include instructions that enable the device 1610 to operate according to an embodiment of the present disclosure (e.g., method 400) when executed on the associated processor 1611. The combination of at least one processor 1611 and at least one MEM 1612 may form a processing device 1615 suitable for implementing various embodiments of the present disclosure.

[0132] The device 1620 includes at least one processor 1621 (such as a DP) and at least one MEM 1622 coupled to the processor 1621. The device 1620 may also include a suitable TX / RX 1623 coupled to the processor 1621, which may be operable to wirelessly communicate with the device 1610. The MEM 1622 stores a PROG 1624. The PROG 1624 may include instructions that, when executed on the associated processor 1621, enable the device 1620 to operate according to embodiments of the present disclosure (e.g., perform the method 1300). The combination of at least one processor 1621 and at least one MEM 1622 may form a processing device 1625 suitable for implementing various embodiments of the present disclosure.

[0133] Various embodiments of the present disclosure may be implemented by a computer program executable by one or more of the processors 1611 , 1621 , software, firmware, hardware, or a combination thereof.

[0134] MEMs 1612 and 1622 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as, by way of non-limiting example, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

[0135] Processors 1611 and 1621 may be of any type suitable for the local technical environment, and may include, by way of non-limiting example, one or more of a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor DSP, and a processor based on a multi-core processor architecture.

[0136] In addition, the present disclosure may also provide a carrier wave containing the computer program as described above, wherein the carrier wave is one of an electric signal, an optical signal, a radio signal or a computer-readable storage medium. The computer-readable storage medium may be, for example, an optical disc or an electronic storage device such as a RAM (random access memory), a ROM (read-only memory), a flash memory, a magnetic tape, a CD-ROM, a DVD, a Blu-ray disc, etc.

[0137] The techniques described herein may be implemented by various means, so that the device for implementing one or more functions of the corresponding device described in one embodiment includes not only prior art means, but also means for implementing one or more functions of the corresponding device described in the embodiment, and it may include a separate device for each separate function, or may include a device that can be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or a combination thereof. For firmware or software, implementation may be performed by a module (e.g., a process, a function, etc.) that performs the functions described herein.

[0138] Exemplary embodiments herein have been described above with reference to block diagrams and flowchart illustrations of methods and apparatus. It will be appreciated that each block of the block diagrams and flowcharts and combinations of the blocks of the block diagrams and flowcharts may be implemented by various means including computer program instructions, respectively. These computer program instructions may be loaded onto a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed on the computer or other programmable data processing apparatus produce an apparatus for implementing the functions specified in the flowchart blocks.

[0139] Although this specification contains many specific implementation details, these should not be interpreted as limitations on the scope of any implementation or possible protection content, but as descriptions of features specific to a particular embodiment of a particular implementation. Certain features described in the context of separate embodiments in this specification may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments or in any suitable sub-combination. Moreover, although the features may be described above as working in certain combinations and even initially claimed as such, one or more features in the claimed combination may be cut out from the combination in some cases, and the claimed combination may involve a sub-combination or a variant of a sub-combination.

[0140] It is clear to those skilled in the art that, with the advancement of technology, the inventive concept can be implemented in various ways. The above embodiments are given to describe rather than limit the present disclosure, and it should be understood that, as those skilled in the art will readily appreciate, modifications and changes may be made without departing from the spirit and scope of the present disclosure. Such modifications and changes are considered to be within the scope of the present disclosure and the appended claims. The scope of protection of the present disclosure is defined by the appended claims.

Claims

1. A method performed by a terminal device, comprising: If the terminal device detects a beam failure during beam monitoring, a physical random access channel (PRACH) is transmitted to the network device, wherein the PRACH includes information corresponding to the beam identifier, and An acknowledgement for the PRACH transmission is received on a physical downlink control channel (PDCCH) from the network device, wherein the PDCCH is scrambled by a terminal device identity, wherein the PDCCH is received based on a time-frequency resource allocation dedicated for beam failure recovery. 2 . The method according to claim 1 , wherein the PDCCH is received in resources indicated by the PRACH.

3. The method according to claim 1, wherein the PRACH indicates beam identification information for beam failure recovery. The method according to claim 3 , wherein the beam identification information indicates a new beam for the beam failure recovery.

5. The method according to claim 1 further includes receiving a configuration related to beam failure recovery from the network device via RRC signaling. The method of claim 5 , wherein the PRACH is transmitted based on the configuration.

7. The method according to claim 1, further comprising: An operation for receiving a downlink transmission is performed after a time offset from the reception of the PDCCH.

8. The method of claim 7, wherein performing the operation comprises considering receiving the downlink transmission using the beam used for the reception of the PDCCH.

9. A method performed by a network device, comprising: receiving a physical random access channel (PRACH) indicating information related to a beam failure from a terminal device, the PRACH including information corresponding to a beam identity, Send an acknowledgement in response to the beam tracking request, and In response to the PRACH, a physical downlink control channel (PDCCH) is transmitted to the terminal device, wherein the PDCCH is scrambled by the terminal device identification, and wherein the PDCCH is transmitted based on a time-frequency resource allocation dedicated to beam failure recovery.

10. The method of claim 9, wherein the PDCCH is transmitted in resources indicated by the PRACH.

11. The method according to claim 9, wherein the PRACH indicates beam identification information for beam failure recovery. 12 . The method according to claim 11 , wherein the beam identification information indicates a new beam for the beam failure recovery.

13. The method according to claim 9 further includes transmitting a configuration related to beam failure recovery to the terminal device via RRC signaling. The method of claim 13 , wherein the PRACH is received based on the configuration.

15. The method according to claim 9, further comprising: An operation for transmitting a downlink transmission is performed after a time offset from the transmission of the PDCCH.

16. The method of claim 15, further comprising transmitting the downlink transmission using a beam used for the transmission of the PDCCH.

17. A terminal device, comprising a processor, wherein the processor is configured to: If the terminal device detects a beam failure during beam monitoring, a physical random access channel (PRACH) is transmitted to the network device, wherein the PRACH includes information corresponding to the beam identifier, and An acknowledgement for the PRACH transmission is received on a physical downlink control channel (PDCCH) from the network device, wherein the PDCCH is scrambled by a terminal device identifier, wherein the PDCCH is received based on a time-frequency resource allocation dedicated to beam failure recovery.

18. A network device comprising a processor, wherein the processor is configured to: receiving a physical random access channel (PRACH) indicating information related to a beam failure from a terminal device, the PRACH including information corresponding to a beam identity, Send an acknowledgement in response to the beam tracking request, and In response to the PRACH, a physical downlink control channel (PDCCH) is transmitted to the terminal device, wherein the PDCCH is scrambled by the terminal device identifier, wherein The PDCCH is transmitted based on time-frequency resource allocation dedicated for beam failure recovery.

Images