Report sending method and apparatus

Abstract

Provided in the embodiments of the present application are a report sending method and apparatus. The method comprises: a terminal device receiving a cell switch command for Layer 1 or Layer 2 triggered mobility (LTM); and sending a first physical uplink shared channel (PUSCH), or sending a first PUSCH and a second PUSCH, wherein the first PUSCH and / or the second PUSCH is not later than a PUSCH successfully sent for the first time, and the first PUSCH carries a first channel state information (CSI) report and / or the second PUSCH carries a second CSI report.

Description

Report sending method and device Technical Field

[0001] The embodiments of this application relate to the field of communication technology. Background Technology

[0002] During the standardization process of Release 18 (Rel-18), the 3GPP standardization organization studied Layer 1 / Layer 2 Triggered Mobility (LTM). For Rel-18 LTM, the goal is to reduce handover interruption through Layer 1 / Layer 2 signaling-based (Layer 1 / Layer 2 triggered) cell handover, thereby enabling faster handover from the serving cell (source cell) to the target cell. The target cell is the cell after the handover, which can be either the serving cell or a non-serving cell. Handover interruption refers to the time from when the terminal device receives the cell switch command to when the terminal device successfully completes its first uplink or downlink transmission with the target cell. Compared to traditional Layer 3 signaling-based cell handover, Layer 1 / Layer 2 signaling-based cell handover can further reduce handover interruption.

[0003] Rel-18 LTM includes measurement, reporting, beam indication, and cell handover. The terminal device measures the System Synchronization Block (SSB) of the candidate cell and reports the measured Layer 1 Reference Signal Receiving Power (L1-RSRP) to the serving cell. The serving cell can activate the Transmission Configuration Indicator (TCI) state of the candidate cell for the terminal device, and then send a cell handover command to instruct the terminal device to hand over to a candidate cell (i.e., the target cell), and indicate the TCI state to be used in the target cell in the cell handover command.

[0004] For Rel-18 LTM, the terminal equipment is provided with measurement resource configuration (resource configuration) and reporting configuration. According to the resource configuration, the measurement reference signals (such as synchronization signal and PBCH block, SSB, for example, simply referred to as synchronization information block (SSB)) of the candidate cell are measured, and the measurement results (such as L1-RSRP) are reported to the serving cell according to the reporting configuration.

[0005] It should be noted that the above introduction to the technical background is only for the purpose of providing a clear and complete explanation of the technical solutions of this application and facilitating understanding by those skilled in the art. It should not be assumed that these technical solutions are known to those skilled in the art simply because they have been described in the background section of this application. Summary of the Invention

[0006] Rel-18 LTM only supports sending Channel Statement Information Reports (CSI Reports) before a cell handover command. The CSI report includes L1-RSRP obtained based on SSB measurements of one or more candidate cells. In other words, the CSI report sent before the cell handover command is used to obtain beam information of the candidate cells, which can be called beam reporting. Therefore, network devices can select candidate cells with better beams for handover to terminal devices. In version 19 (Rele-19), LTM further enhances the CSI report, supporting its transmission after a cell handover command. This CSI report includes the CSI obtained based on measurements of the Channel State Information Reference Signal (CSI-RS) of the target cell. Specifically, the CSI report sent after the handover command is used to acquire the target cell's CSI. The CSI includes at least one of the following: Precoding Matrix Indicator (PMI), Channel Quality Indication (CQI), Rank Indication (RI), and CSI-RS Resource Indicator (CRI). This allows network devices to obtain the CSI as quickly as possible after handover, enabling them to select better MIMO transmission schemes and modulation / coding methods for uplink and downlink transmissions, thus facilitating the rapid achievement of high-throughput or high-reliability transmissions after handover.

[0007] Currently, the problem to be solved is how terminal devices can send a CSI report, including at least one of PMI, CQI, RI, and CRI, after a cell handover command.

[0008] To address at least one of the above-mentioned problems, embodiments of this application provide a report sending method and apparatus.

[0009] According to one aspect of the embodiments of this application, a report sending apparatus is provided, applied to a terminal device, comprising:

[0010] The receiver receives cell handover commands for mobility (LTM) triggered by Layer 1 or Layer 2.

[0011] The transmitter transmits a first Physical Uplink Shared Channel (PUSCH), or transmits a first PUSCH and a second PUSCH; the first PUSCH and / or the second PUSCH is no later than the first successfully transmitted PUSCH;

[0012] The first PUSCH carries a first channel state information (CSI) report, and the first PUSCH satisfies at least one of the following:

[0013] The first PUSCH is a configured grant PUSCH sent on the resources configured by Radio Resource Control (RRC) signaling;

[0014] The first PUSCH is the PUSCH scheduled by the Random Access Response Uplink Grant (RAR UL grant);

[0015] The first PUSCH is the PUSCH for downlink control information scheduling;

[0016] The first PUSCH is the PUSCH scheduled by the cell handover command;

[0017] And / or,

[0018] The second PUSCH carries a second CSI report, and the second PUSCH satisfies at least one of the following:

[0019] The second PUSCH is a configured grant PUSCH sent on resources configured by Radio Resource Control (RRC) signaling;

[0020] The second PUSCH is a PUSCH scheduled using downlink control information format 0_0 (DCI format 0_0);

[0021] The second PUSCH is a retransmission of the first PUSCH.

[0022] According to another aspect of the embodiments of this application, a report sending apparatus is provided, applied to a terminal device, comprising:

[0023] The receiver receives cell handover commands for mobility (LTM) triggered by Layer 1 or Layer 2.

[0024] A transmitter that transmits a first Physical Uplink Shared Channel (PUSCH) and a second PUSCH; the first PUSCH and the second PUSCH are no later than the first successfully transmitted PUSCH;

[0025] The first PUSCH carries a CSI report, while the second PUSCH does not carry a CSI report.

[0026] Both the first PUSCH and the second PUSCH are configured grant PUSCHs sent on resources configured by Radio Resource Control (RRC) signaling, and / or the second PUSCH is a retransmission of the first PUSCH.

[0027] According to another aspect of the embodiments of this application, a report receiving apparatus is provided, applied to a network device, comprising:

[0028] A transmitter that sends cell handover commands for Layer 1 or Layer 2 triggered mobility (LTM);

[0029] The receiver receives a first Physical Uplink Shared Channel (PUSCH), or receives a first PUSCH and a second PUSCH; the first PUSCH and / or the second PUSCH is no later than the first successfully received PUSCH.

[0030] The first PUSCH carries a first channel state information (CSI) report, and the first PUSCH satisfies at least one of the following:

[0031] The first PUSCH is a configured grant PUSCH sent on the resources configured by Radio Resource Control (RRC) signaling;

[0032] The first PUSCH is the PUSCH scheduled by the Random Access Response Uplink Grant (RAR UL grant);

[0033] The first PUSCH is the PUSCH for downlink control information scheduling;

[0034] The first PUSCH is the PUSCH scheduled by the cell handover command;

[0035] And / or,

[0036] The second PUSCH carries a second CSI report, and the second PUSCH satisfies at least one of the following:

[0037] The second PUSCH is a configured grant PUSCH sent on resources configured by Radio Resource Control (RRC) signaling;

[0038] The second PUSCH is a PUSCH scheduled using downlink control information format 0_0 (DCI format 0_0);

[0039] The second PUSCH is a retransmission of the first PUSCH.

[0040] One of the beneficial effects of this application's embodiments is that the PUSCH sent by the terminal device for the first time after the cell handover command and its retransmission carry a CSI report. The PUSCH can be at least one of the configured grant PUSCH of RRC, the PUSCH scheduled by DCI, the PUSCH scheduled by RAR UL grant, or the PUSCH scheduled by the cell handover command. As a result, there will be no ambiguity in the assumptions of the network device and the terminal device regarding the transmission and reception of the CSI report. The CSI report can be obtained by the network device faster and more reliably after the handover. Thus, the network device can select a better Multiple-Input Multiple-Output transmission scheme and modulation and coding method for uplink and downlink transmission, which is beneficial for quickly achieving high throughput or high reliability transmission after cell handover.

[0041] One of the advantages of this application's embodiments is that the terminal device does not carry a CSI report in the retransmission of the first PUSCH after the cell handover command. This simplifies the design and reduces the impact on existing standards. If the CSI report carried in the first PUSCH is not correctly demodulated, the network device can instruct the terminal device to send a CSI report after completing the first successful PUSCH transmission.

[0042] Specific embodiments of this application are disclosed in detail with reference to the following description and accompanying drawings, indicating how the principles of this application can be adopted. It should be understood that the embodiments of this application are not limited in scope. Within the spirit and scope of the appended claims, embodiments of this application include many changes, modifications, and equivalents.

[0043] Features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, combined with features in other embodiments, or substituted for features in other embodiments.

[0044] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, whole, step, or component, but does not exclude the presence or addition of one or more other features, wholes, steps, or components. Attached Figure Description

[0045] The elements and features described in one drawing or embodiment of this application may be combined with elements and features shown in one or more other drawings or embodiments. Furthermore, in the drawings, similar reference numerals denote corresponding parts in several drawings and can be used to indicate corresponding parts used in more than one embodiment.

[0046] Figure 1 is a schematic diagram of a communication system according to an embodiment of this application;

[0047] Figure 2 is a schematic diagram of cell handover in LTM according to an embodiment of this application;

[0048] Figure 3 is a schematic diagram of LTM based on random access;

[0049] Figure 4 is another schematic diagram of LTM based on random access;

[0050] Figure 5 is another schematic diagram of LTM based on random access;

[0051] Figure 6 is a schematic diagram of LTM without random access;

[0052] Figure 7 is another schematic diagram of LTM without random access;

[0053] Figure 8 is a schematic diagram of a report sending method according to an embodiment of this application;

[0054] Figure 9 is a schematic diagram of sending a first PUSCH and / or a second PUSCH according to an embodiment of this application;

[0055] Figure 10 is a schematic diagram of an LTM configuration according to an embodiment of this application;

[0056] Figure 11 is a schematic diagram of a report sending method according to an embodiment of this application;

[0057] Figure 12 is a schematic diagram of a report receiving method according to an embodiment of this application;

[0058] Figure 13 is a schematic diagram of a report receiving method according to an embodiment of this application;

[0059] Figure 14 is a schematic diagram of a report sending device according to an embodiment of this application;

[0060] Figure 15 is a schematic diagram of a report receiving device according to an embodiment of this application;

[0061] Figure 16 is a schematic diagram of a terminal device according to an embodiment of this application;

[0062] Figure 17 is a schematic diagram of a network device according to an embodiment of this application. Detailed Implementation

[0063] Referring to the accompanying drawings, the foregoing and other features of this application will become apparent from the following description. Specific embodiments of this application are specifically disclosed in the description and drawings, illustrating partial implementations in which the principles of this application may be employed. It should be understood that this application is not limited to the described embodiments; rather, it includes all modifications, variations, and equivalents falling within the scope of the appended claims.

[0064] In the embodiments of this application, the terms "first," "second," etc., are used to distinguish different elements by name, but do not indicate the spatial arrangement or chronological order of these elements, and these elements should not be limited by these terms. The term "and / or" includes any one or more of the terms listed in association and all combinations thereof. The terms "comprising," "including," "having," etc., refer to the presence of the stated features, elements, components, or assemblies, but do not exclude the presence or addition of one or more other features, elements, components, or assemblies.

[0065] In the embodiments of this application, the singular forms "a," "the," etc., including the plural forms, should be broadly understood as "a kind" or "a class" rather than limited to the meaning of "an." Furthermore, the term "the" should be understood to include both the singular and plural forms, unless the context explicitly indicates otherwise. Additionally, the term "according to" should be understood as "at least partially based on…," and the term "based on" should be understood as "at least partially based on…," unless the context explicitly indicates otherwise.

[0066] In the embodiments of this application, the term "communication network" or "wireless communication network" may refer to a network that conforms to any of the following communication standards, such as Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), etc.

[0067] Furthermore, communication between devices in a communication system can be carried out according to communication protocols at any stage, including but not limited to the following communication protocols: 1G (generation), 2G, 2.5G, 2.75G, 3G, 4G, 4.5G and 5G, New Radio (NR), future 6G, etc., and / or other currently known or future communication protocols.

[0068] In the embodiments of this application, the term "network device" refers, for example, to a device in a communication system that connects a terminal device to a communication network and provides services to that terminal device. Network devices may include, but are not limited to, the following devices: base station (BS), access point (AP), transmission reception point (TRP), broadcast transmitter, mobile management entity (MME), gateway, server, radio network controller (RNC), base station controller (BSC), etc.

[0069] Base stations can include, but are not limited to: NodeBs (or NBs), evolved NodeBs (eNodeBs or eNBs), and 5G base stations (gNBs), IAB hosts, etc. They can also include Remote Radio Heads (RRHs), Remote Radio Units (RRUs), relays, or low-power nodes (e.g., femeto, pico, etc.). The term "base station" can encompass some or all of their functions, and each base station can provide communication coverage to a specific geographic area. The term "cell" can refer to a base station and / or its coverage area, depending on the context in which the term is used.

[0070] In the embodiments of this application, the terms "User Equipment" (UE) or "Terminal Equipment" (TE) refer, for example, to a device that accesses a communication network and receives network services through a network device. A terminal device can be fixed or mobile, and may also be referred to as a mobile station (MS), terminal, subscriber station (SS), access terminal (AT), station, etc.

[0071] The terminal device may include, but is not limited to, the following devices: cellular phone, personal digital assistant (PDA), wireless modem, wireless communication device, handheld device, machine-type communication device, laptop computer, cordless phone, smartphone, smartwatch, digital camera, etc.

[0072] For example, in scenarios such as the Internet of Things (IoT), terminal devices can also be machines or devices for monitoring or measurement, such as including but not limited to: machine-type communication (MTC) terminals, vehicle communication terminals, device-to-device (D2D) terminals, machine-to-machine (M2M) terminals, and so on.

[0073] Furthermore, the terms "network side" or "network equipment side" refer to one side of the network, which can be a base station or include one or more network devices as described above. The terms "user side," "terminal side," or "terminal equipment side" refer to the side of the user or terminal, which can be a UE or include one or more terminal devices as described above. Unless otherwise specified, "equipment" can refer to either network equipment or terminal equipment.

[0074] The following examples illustrate the scenarios of embodiments of this application, but this application is not limited thereto.

[0075] Figure 1 is a schematic diagram of a communication system according to an embodiment of this application, illustrating the case of a terminal device and a network device as examples. As shown in Figure 1, the communication system 100 may include a network device 101 and terminal devices 102 and 103. For simplicity, Figure 1 only illustrates the case of two terminal devices and one network device, but the embodiments of this application are not limited to this.

[0076] In this embodiment of the application, network device 101 and terminal devices 102 and 103 can transmit existing services or services that can be implemented in the future. For example, these services may include, but are not limited to: enhanced mobile broadband (eMBB), massive machine-type communication (mMTC), and ultra-reliable and low-latency communication (URLLC), etc.

[0077] It is worth noting that Figure 1 shows that both terminal devices 102 and 103 are within the coverage area of ​​network device 101, but this application is not limited to this. Both terminal devices 102 and 103 may be outside the coverage area of ​​network device 101, or one terminal device 102 may be within the coverage area of ​​network device 101 while the other terminal device 103 may be outside the coverage area of ​​network device 101.

[0078] In the embodiments of this application, the signaling may be, for example, Radio Resource Control (RRC) signaling; for example, referred to as an RRC message, including MIB, system information, dedicated RRC messages; or referred to as an RRC information element. The signaling may also be, for example, Medium Access Control (MAC) signaling; or referred to as a MAC control element. However, this application is not limited to these.

[0079] In the following description, without confusion, the terms "PDCCH" and "Physical Downlink Control Channel" or "Downlink Control Information" are used interchangeably, as are the terms "PDSCH" and "Physical Downlink Data Channel" or "Downlink Data". Furthermore, transmitting or receiving a PDCCH can be understood as transmitting or receiving downlink control information carried by the PDCCH; transmitting or receiving a PDSCH can be understood as transmitting or receiving downlink data carried by the PDSCH.

[0080] The terms "PUCCH" and "Physical Uplink Control Channel" or "Uplink Control Information" are interchangeable, as are the terms "PUSCH" and "Physical Uplink Data Channel" or "Uplink Data." Furthermore, transmitting or receiving a PUCCH can be understood as transmitting or receiving downlink control information carried by the PUCCH; transmitting or receiving a PUSCH can be understood as transmitting or receiving downlink data carried by the PUSCH.

[0081] For ease of understanding, the following further explains LTM.

[0082] For Rel-18 LTM, the terminal device performs measurements based on SSB or CSI-RS, which enables downlink synchronization with candidate cells (including the target cell) to a certain extent. The terminal device can be triggered by a Physical Downlink Control Channel (PDCCH) order sent by the serving cell to send a Physical Random Access Channel (PRACH) to the candidate cell, thereby achieving uplink synchronization with the candidate cell. The serving cell instructs the terminal device, via a cell handover command (e.g., carried by the Media Access Control (MAC) Control Unit (CE)), to select which candidate cell to hand over to (the indicated candidate cell becomes the target cell), and indicates the beam used for uplink and downlink transmission on the target cell after the handover. For example, the beam refers to the transmission configuration indication state (TCI state). In LTM, the serving cell, candidate cell, and target cell all support a unified TCI state; therefore, the aforementioned indicated TCI state is a unified TCI state. The terminal device receives the cell handover command, which indicates the target cell and the TCI state applied on the target cell. Before receiving the cell handover command, the terminal device has already synchronized with the target cell. After handover to the target cell, it can perform uplink and downlink transmissions with the target cell according to the indicated TCI state. The source reference signal included in the TCI state IE can be either SSB or TRS.

[0083] A unified TCI state can be a joint TCI state or a separate TCI state. A joint TCI state is both a downlink TCI state and an uplink TCI state; a separate TCI state is either a downlink TCI state or an uplink TCI state. The serving cell can activate the candidate cell's TCI state for the terminal device before the cell handover command, and then indicate one (or a pair) of activated TCI states in the cell handover command; alternatively, the serving cell can also indicate one (or a pair) of inactive TCI states in the cell handover command, which is equivalent to the cell handover command directly indicating and activating the TCI state.

[0084] In LTM, the cell that a terminal device may hand over to is called a candidate cell, and the cell that the terminal device actually hands over to is called the target cell. A candidate cell can be a serving cell or a non-serving cell. The terminal device can be provided with candidate cell configuration, receive a cell switch command and a TCI state indication, hand over to the target cell, and apply the indicated TCI state on the target cell.

[0085] Figure 2 is a schematic diagram of cell handover in LTM according to an embodiment of this application. As shown in Figure 2, cells C0, C1, and C2 are serving cells. For example, cells C0, C1, and C2 are a group of cells in carrier aggregation, where cell C0 is the primary cell (Pcell), and cells C1 and C2 are secondary cells (Scells). For example, the serving cell is at least one of the following: a special cell (SpCell), an Scell, an active cell, or a deactivated cell. Cells C3, C4, C5, and C6 are non-serving cells. For example, cells C3, C4, C5, and C6 are a group of cells in carrier aggregation, where cell C3 is a Pcell, and cells C4, C5, and C6 are Scells. Both serving and non-serving cells can be used as candidate cells.

[0086] LTM supports handover from one serving cell to another, intra-frequency cells, or inter-frequency cells. For example, handover from serving cell C0 to serving cell C2 (i.e., serving cell C2 changes from S cell to P cell), cell C3 (intra-frequency cell), and cell C6 (inter-frequency cell).

[0087] Terminal equipment can switch to one or more target cells. For example, it can switch from a serving cell (cell C0, cell C1, cell C2) of a set of carrier aggregations to a non-serving cell (cell C3, cell C4, cell C5, cell C6) of a set of carrier aggregations.

[0088] Cell handover commands can indicate Timing Advance (TA), or, if a capable terminal device can obtain the TA itself based on measurements, the terminal device does not need to perform the RACH procedure after the cell handover command; this is called RACH-less LTM. Furthermore, Rel-18 also supports performing the RACH procedure after the cell handover command; this is called RACH-based LTM. If the cell handover command does not indicate a valid TA, and the terminal device is not capable of obtaining the TA itself based on measurements, then the terminal device needs to obtain the TA through the RACH procedure after the cell handover command. This RACH procedure can be Contention-Free Random Access (CFRA), i.e., contention-free random access, or Contention-Based Random Access (CBRA).

[0089] The following describes several LTM scenarios involved in the embodiments of this application.

[0090] Figure 3 is a schematic diagram of Random Access Channel-based LTM (RACH-based LTM). This random access is based on non-contention-based random access (CFRA).

[0091] As shown in Figure 3, the terminal device receives a Cell Switch Command (CSC) for LTM. The CSC does not indicate a valid TA (Target Access Message), meaning the indicated TA is hexadecimal FFF. The CSC also indicates CFRA (Circular Access Relay) resources, which may include a random access preamble, etc. The terminal device sends a Physical Random Access Channel (PRACH) to the candidate cell indicated by the CSC (also called the target cell), i.e., it sends a preamble. Then, the terminal device receives a Random Access Response (RAR) by receiving a PDSCH scheduled by Downlink Control Information (DCI). If the terminal device successfully receives the RAR, the random access process is considered successfully completed, i.e., the LTM cell switch is successful. The RAR uplink grant can schedule the terminal device to send a PUSCH to the candidate cell. Subsequently, the terminal device can also be scheduled by the DCI to send a PUSCH retransmission for that PUSCH. Taking Figure 3 as an example, the successful handover time of LTM cell is placed after the receiving RAR time. However, this application is not limited to this; the successful handover time of LTM cell and the receiving RAR time can also be the same time.

[0092] Figure 4 is another schematic diagram of LTM based on random access. Here, the random access is CFRA, and the same content as in Figure 3 will not be repeated. Unlike the CSC-triggered PRACH transmission in Figure 3, in Figure 4, the CSC does not indicate the TA, nor does it indicate the resources of the CFRA, and the terminal device does not estimate the TA itself. In this case, the terminal device can obtain the TA through CFRA triggered by a PDCCH order, such as DCI format 1_0, which can indicate the resources of the CFRA.

[0093] Figure 5 is another schematic diagram of LTM based on random access. In this case, the random access is CBRA. As shown in Figure 5, the terminal device receives a CSC for LTM. The CSC does not indicate TA or CFRA resources, and the terminal device does not estimate the TA itself. In this case, the terminal device can obtain the TA through CBRA and achieve uplink synchronization with the candidate cell through a 4-step RACH. More specifically, taking Figure 5 as an example, the terminal device sends PRACH (Msg1), receives RAR (Msg2), sends PUSCH (Msg3) according to the RAR UL grant, and receives Msg4 by receiving PDSCH scheduled by DCI. The terminal device can be scheduled by DCI to send a retransmission of Msg3 for Msg3. If the terminal device successfully completes the random access process, the LTM cell handover process is also considered successful. In Figure 5, the successful LTM cell handover time is placed after the time of receiving Msg4. This application is not limited to this; the successful LTM cell handover time and the time of receiving Msg4 can also be the same time.

[0094] Figure 6 is a schematic diagram of RACH-less LTM. In this diagram, the terminal device has already sent a PRACH to the candidate cell before receiving the CSC for LTM. Therefore, the CSC can directly indicate the TA to be used in the candidate cell for the terminal device. After receiving the CSC, the terminal device does not need to perform a random access procedure and has already obtained uplink synchronization. As shown in Figure 6, the first uplink transmission of the terminal device after the CSC is a configured grant PUSCH. Before the CSC, the terminal device is provided with Type 1 configured grant configuration by RRC signaling. Based on the configuration of this configured grant, the terminal device sends the first PUSCH after the CSC on the time-frequency resources configured by the RRC signaling. This PUSCH can carry an RRC Reconfiguration Complete message. When the terminal device determines that the first PUSCH has been successfully transmitted, the terminal device considers the LTM cell handover successful. Furthermore, the terminal device can retransmit the first PUSCH it sends. Since the first PUSCH is a configured grant PUSCH, its retransmission can be sent on the time-frequency resources indicated by the DCI or on the configured grant time-frequency resources configured by the RRC signaling. After sending the first PUSCH and / or retransmitting the first PUSCH, if the terminal device receives a DCI, and that DCI schedules a new PUSCH transmission on the same HARQ process used by the first PUSCH, or if the DCI schedules a PDSCH, then the terminal device considers the first PUSCH transmission successful, i.e., considers the LTM cell handover successful.

[0095] Figure 7 is another schematic diagram of LTM without random access; the same content as in Figure 6 will not be repeated. Unlike Figure 6, as shown in Figure 7, the first uplink transmission by the terminal device after CSC is a dynamic grant PUSCH, meaning the terminal device sends the first PUSCH after CSC on the time-frequency resources indicated by the DCI (Dictionary of Initial Transmission). Furthermore, the terminal device can retransmit the first PUSCH. Since the first PUSCH is a dynamic grant PUSCH, this retransmission can be sent on the time-frequency resources indicated by the DCI (Dictionary of Retransmission).

[0096] In the following embodiments, "CSI" can be replaced with "CSI report".

[0097] The inventors have discovered that, for terminal devices during the LTM process, a problem to be solved is how to send a CSI report, including at least one of PMI, CQI, RI, and CRI, after a cell handover command. Furthermore, there are still unresolved issues regarding how terminal devices should send CSI reports after a cell handover command, such as whether the CSI report can be multiplexed on a retransmitted Physical Uplink Shared Channel (PUSCH), whether the CSI report can be multiplexed on the Msg3 PUSCH in Contention-Based Random Access (CBRA), and how to obtain parameters used to determine the number of REs occupied by the CSI report. The following description addresses at least one of these problems in conjunction with embodiments.

[0098] First aspect of the embodiments

[0099] This application provides a report sending method, which is described from the perspective of the terminal device.

[0100] Figure 8 is a schematic diagram of a report sending method according to an embodiment of this application. As shown in Figure 8, the method includes:

[0101] 801, the terminal device receives a cell handover command for Layer 1 or Layer 2 mobility (LTM) triggering;

[0102] 802, send the first Physical Uplink Shared Channel (PUSCH), or send the first PUSCH and the second PUSCH, wherein the first PUSCH and / or the second PUSCH is no later than the first successfully sent PUSCH.

[0103] In this embodiment of the application, the first PUSCH carries a first channel state information (CSI) report, and the first PUSCH satisfies at least one of the following:

[0104] The first PUSCH is a configured grant PUSCH sent on the resources configured by Radio Resource Control (RRC) signaling;

[0105] The first PUSCH is the PUSCH scheduled by the Random Access Response Uplink Grant (RAR UL grant);

[0106] The first PUSCH is the PUSCH for downlink control information scheduling;

[0107] The first PUSCH is the PUSCH scheduled by the cell handover command;

[0108] And / or,

[0109] The second PUSCH carries a second CSI report, and the second PUSCH satisfies at least one of the following:

[0110] The second PUSCH is a configured grant PUSCH sent on resources configured by Radio Resource Control (RRC) signaling;

[0111] The second PUSCH is a PUSCH scheduled using downlink control information format 0_0 (DCI format 0_0);

[0112] The second PUSCH is a retransmission of the first PUSCH.

[0113] It is worth noting that Figure 8 above is only a schematic illustration of the embodiments of this application, but the application is not limited thereto. For example, other operations may be added or some operations may be removed. Those skilled in the art can make appropriate modifications based on the above content, and are not limited to the description in Figure 8 above.

[0114] According to embodiments of this application, the PUSCH sent by the terminal device for the first time after the cell handover command, and its retransmission, carry a CSI report. This PUSCH can be at least one of the following: a configuration grant PUSCH configured by RRC, a PUSCH scheduled by RAR UL grant, a PUSCH scheduled by downlink control information, or a PUSCH scheduled by the cell handover command. Therefore, there is no ambiguity in the assumptions made by the network device and the terminal device regarding the transmission and reception of the CSI report. The CSI report can be obtained by the network device more quickly and reliably after the handover, allowing the network device to select better MIMO transmission schemes and modulation and coding methods for uplink and downlink transmissions, which is beneficial for quickly achieving high throughput or high reliability transmission after the handover.

[0115] In some embodiments, the cell handover command may be carried by the MAC CE, which may indicate the candidate cell for handover and the TCI state applied on that cell. The first PUSCH and the second PUSCH are sent after the CSC. The CSC MAC CE may also include a Timing Advance Command (TAC) field, which the terminal device can use to determine the TA used by the first PUSCH and / or the second PUSCH sent after the CSC. If the TAC field value is not hexadecimal FFF, the TA is directly indicated by this field. If the TAC field value is FFF, the terminal device can obtain the TA by measuring the candidate cell indicated by the CSC (i.e., obtain the TA itself), or the terminal device can obtain the TA through a random access procedure after the CSC; wherein, the terminal device obtaining the TA itself is contingent upon the terminal device being capable of performing UE-based TA measurement.

[0116] The first PUSCH and the second PUSCH of the embodiments of this application will be described below.

[0117] Regarding the first push:

[0118] In some embodiments, the terminal device receives a CSC. Furthermore, the terminal device may receive a Radio Resource Control (RRC) signaling indicating a configured grant PUSCH sent by the network device before the CSC; and / or, receive a random access response uplink grant sent by the network device after the CSC; and / or, receive downlink control information sent by the network device after the CSC. The first PUSCH is a configured grant PUSCH sent on resources configured by the Radio Resource Control (RRC) signaling; and / or, the first PUSCH is a PUSCH scheduled by a random access response uplink grant (RAR UL grant); and / or, the first PUSCH is a PUSCH scheduled by downlink control information; and / or, the first PUSCH is a PUSCH scheduled by the cell handover command.

[0119] In some embodiments, FIG9 is a schematic diagram of the first PUSCH and the second PUSCH of the present application. As shown in FIG9, after the terminal device receives the cell handover command CSC, it sends the first PUSCH to the candidate cell indicated by the CSC. The first PUSCH is the first PUSCH sent by the terminal device to the candidate cell indicated by the cell handover command after receiving the cell handover command. In order to enable the candidate cell to obtain CSI as early as possible, the CSI report can be reused on the first PUSCH. The CSI report carried by the first PUSCH can be called the first CSI report.

[0120] For example, for RACH-based LTM, as shown in Figures 3 and 4, since the terminal device has not yet obtained uplink synchronization before random access is completed, the transmission of the first PUSCH cannot be earlier than the PUSCH scheduled by the RAR UL grant. The PUSCH scheduled by the RAR UL grant is the first PUSCH transmitted after the CSC. Therefore, for RACH-based LTM, the first PUSCH can be the PUSCH scheduled by the RAR UL grant.

[0121] For example, for RACH-less LTM, taking Figure 6 as an example, the first PUSCH can be sent on the configured grant resource configured by RRC signaling. That is, the terminal device can send the PUSCH to the candidate cell for the first time through the configured grant. The first PUSCH is a configuration grant PUSCH sent on the resource configured by RRC signaling. The RRC signaling can be RRC connection reconfiguration signaling previously received by the CSC, etc. The configured grant is a configured grant configured for RACH-less LTM, such as configured by ConfiguredGrantConfig including cg-LTM-Configuration. As another example, taking Figure 7 as an example, the first PUSCH can also be sent on the resource scheduled by DCI. That is, the terminal device sends the PUSCH to the candidate cell for the first time through the dynamic grant. The first PUSCH is a PUSCH scheduled by downlink control information. As yet another example, the first PUSCH can also be sent on the resource indicated by CSC MAC CE. That is, the first PUSCH is a PUSCH scheduled by cell handover command.

[0122] In the above examples, the configuration grant in the RRC signaling configuration, or the uplink grant in the random access response (RAR UL grant), or the downlink control information, or the cell handover command may include resource indication information related to the PUSCH. This resource indication information includes at least one of the following: periodic or aperiodic, frequency domain resource information, or time domain resource information. Based on this resource indication information, the location of the first PUSCH can be determined, and thus, the first PUSCH carrying the first CSI report can be sent at the corresponding resource location.

[0123] In some embodiments, the first PUSCH may carry only the first CSI report, or it may carry the first CSI report and other information. This other information may include an RRC Reconfiguration Complete message and / or an Uplink-Shared Channel (UL-SCH), or the first PUSCH may not carry a CSI report.

[0124] In some embodiments, the RAR UL grant, CSC, or DCI can indicate whether the first PUSCH carries a CSI report. For example, existing or reserved fields in the RAR UL grant, CSC, or DCI can be reused, or new fields can be added to the RAR UL grant, CSC, or DCI to indicate whether the first PUSCH carries a CSI report.

[0125] The following example illustrates how to determine if the first PUSCH carries the first CSI report.

[0126] In Example 1, when the first PUSCH is a random access response uplink grant scheduling PUSCH, for a non-contentionable random access procedure, the terminal device determines whether the first PUSCH carries the first CSI report based on the CSI request field in the RAR UL grant. That is, for a non-contentionable random access procedure, the first PUSCH may or may not carry the first CSI report. For a contentionable random access procedure, the terminal device determines that the CSI request field in the RAR UL grant is reserved. That is, a contentionable random access procedure does not support carrying the first CSI report in the PUSCH scheduled by the RAR UL grant.

[0127] For example, as shown in Figures 3 to 5, the first PUSCH sent by the terminal device can be a PUSCH scheduled by the RAR UL grant. For CFRA, as shown in Figures 3 and 4, the first PUSCH can carry a CSI report; for CBRA, as shown in Figure 5, the first PUSCH cannot carry a CSI report. For example, the RAR UL grant includes a CSI request field. For CFRA, the CSI request field indicates whether the first PUSCH carries a CSI report; for CBRA, the terminal device considers the CSI request field to be a reserved field (unused), and therefore will not carry a CSI report in the first PUSCH. For example, the CSI request field in CFRA has a bit width of 1 bit. A first value ("1") indicates that the first PUSCH carries a CSI report, and a second value ("0") indicates that the first PUSCH does not carry a CSI report, and vice versa. This embodiment of the application does not limit this.

[0128] In CBRA, multiple terminal devices may choose the same preamble to send, so that they can all receive the RAR UL grant and send their scheduled PUSCH according to the RAR UL grant. The reasons why CBRA does not support carrying CSI reports on PUSCHs scheduled by RAR UL grants include at least one of the following: First, terminal devices attempting to access candidate cells via CBRA may be terminal devices that have undergone LTM cell handover (LTM terminal devices) or terminal devices that have not undergone LTM cell handover (non-LTM terminal devices). Only LTM terminal devices can carry CSI reports on PUSCHs scheduled by RAR UL grants. After receiving the preamble, the network device cannot distinguish whether it comes from an LTM terminal device or a non-LTM terminal device, and therefore cannot determine whether to indicate in the RAR UL grant to carry CSI reports on that PUSCH. Second, assuming that each terminal device can carry CSI reports on PUSCHs scheduled by RAR UL grants, since the parameters related to CSI reports of different terminal devices (e.g., the number of REs occupied by the CSI report or the RNTI used for scrambling the CSI report) may be different, the network device, upon receiving the RAR UL grant, cannot distinguish whether it comes from an LTM terminal device or a non-LTM terminal device. After a PUSCH is scheduled by a grant, it's impossible to distinguish which end device the PUSCH belongs to. Therefore, it's impossible to know which end device's parameters (e.g., the number of REs in the CSI report or the RNTI used for scrambling the CSI report) should be used to demodulate the CSI report (and other information in the demodulated PUSCH). Therefore, by disabling CBRA from carrying CSI reports in PUSCHs scheduled by RAR UL grants, the above problems can be avoided.

[0129] In the above example, if the RAR UL grant is no later than the first time point, for CFRA, the terminal device determines whether the first PUSCH carries a CSI report, and / or, which CSI report the first PUSCH carries, based on the CSI request field in the RAR UL grant; for CBRA, the terminal device assumes the CSI request field in the RAR UL grant is reserved. If the RAR UL grant is later than the first time point, the terminal device assumes the CSI request field in the RAR UL grant is reserved for both CFRA and CBRA. The first time point can be the time of successful LTM cell handover, or the time of the first successful PUSCH transmission. In summary, the terminal device (e.g., an LTM terminal device) determines how to interpret the CSI request field in the RAR UL grant based on the first time point. Furthermore, the terminal device can also be configured to determine whether to interpret the CSI request field in the RAR UL grant based on the first time point.

[0130] In Example 2, when the first PUSCH is a random access response uplink grant scheduled PUSCH, the terminal device determines whether the first PUSCH carries a first CSI report based on the CSI request field in the RAR UL grant. Unlike Example 1, both CFRA and CBRA support carrying CSI reports on PUSCHs scheduled by RAR UL grants. An additional method can be introduced to enable CBRA to support carrying CSI reports on PUSCHs scheduled by RAR UL grants. This method will be explained later.

[0131] Regarding the second push:

[0132] In some embodiments, the PUSCH (first PUSCH) sent by the terminal device to the candidate cell for the first time may not be successfully received by the network device. Therefore, the terminal device can send a PUSCH retransmission, which can be called the second PUSCH. The first PUSCH may not be successfully transmitted. The PUSCH may be successfully transmitted for the first time only after one or more retransmissions. Therefore, the first PUSCH sent is not necessarily the first successfully transmitted PUSCH. Taking Figure 9 as an example, the first PUSCH and the second PUSCH are not later than the first successfully transmitted PUSCH. Either the first PUSCH or the second PUSCH can be the first successfully transmitted PUSCH. The above is only an example of one retransmission. This application is not limited to this. There may be multiple retransmissions before the first successfully transmitted PUSCH is achieved, or there may be no retransmission.

[0133] In some embodiments, the second PUSCH may also carry a CSI report, hereinafter referred to as the second CSI report. To report CSI as early as possible, the first PUSCH carries the first CSI report; however, considering that the first PUSCH may not necessarily transmit successfully, it is advisable to carry the second CSI report in the second PUSCH. How the first and second CSI reports are determined will be explained later.

[0134] For example, taking the terminal device sending the first PUSCH on the configured grant resource configured in RRC signaling as an example, the first PUSCH is the initial transmission of the configured grant. Afterwards, a second PUSCH is sent. The second PUSCH can be a retransmission sent on the configured grant resource configured in RRC signaling. The first PUSCH and the second PUSCH are located in configured grant resources of different periods. When the second PUSCH is sent on the configured grant resource configured in the RRC signaling, the second PUSCH can carry a second CSI report. This avoids handover delays caused by network devices missing configured grant PUSCHs. For example, a network device might miss a PUSCH sent on a certain configured grant resource. If the network device misses the first PUSCH, it will treat the second PUSCH as the first PUSCH sent by the terminal device and assume it carries a CSI report. However, if the terminal device only carries a CSI report on the first PUSCH and not the second, there will be ambiguity between the network device and the terminal device regarding whether the second PUSCH carries a CSI report. Since the CSI report is used as uplink control information... When CSI (Unique Information Reporting) is multiplexed into a PUSCH, the RE mapping when the PUSCH carries a CSI report differs from the RE mapping when the PUSCH does not carry a CSI report. Demodulation using a mismatched RE mapping will cause the second PUSCH and CSI report reception to fail, thus increasing the LTM handover interruption time and resulting in greater handover latency. Therefore, to avoid the above inconsistency, the terminal device can carry a CSI report in every PUSCH sent on the configured grant resource configured in the RRC signaling until the LTM cell handover is successful. After the LTM cell handover is successful, the terminal device will stop using the configured grant configured for RACH-less LTM.

[0135] For example, the second PUSCH can be scheduled by DCI. If the initial transmission (first PUSCH) is scheduled by RAR UL grant, the retransmission (second PUSCH) can be scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI. If the initial transmission (first PUSCH) is sent on the configured grant resource configured by RRC signaling, the retransmission (second PUSCH) can be scheduled by DCI format 0_0, DCI format 0_1, DCI format 0_2, or DCI format 0_3 with CRC scrambled by CS-RNTI. If the initial transmission (first PUSCH) is sent on the resource scheduled by DCI or the resource indicated by CSC MAC CE, the retransmission (second PUSCH) can be scheduled by DCI format 0_0, DCI format 0_1, DCI format 0_2, or DCI format 0_3 with CRC scrambled by C-RNTI or MCS-C-RNTI.

[0136] In the above example, DCI can dynamically indicate whether the second PUSCH carries a CSI report (and / or which CSI reports to carry). Depending on whether the CSI report carried by the first PUSCH is successfully received, the network device can indicate whether a CSI report needs to be carried in the retransmission when scheduling retransmission through DCI. For DCI format 0_1, DCI format 0_2, or DCI format 0_3, the CSI request field in DCI can be used to indicate whether the second PUSCH carries a CSI report. For DCI format 0_0, to indicate whether the second PUSCH carries a CSI report, a reserved field in DCI can be reused, or a new field can be added to DCI. When the bit value of this field is non-zero, it indicates that a CSI report is carried; when the bit value of this field is zero, it indicates that a CSI report is not carried, and vice versa. The embodiments of this application are not intended to limit this.

[0137] In other examples, regardless of whether the second PUSCH is a retransmission sent on the configured grant resource configured by RRC signaling or a retransmission scheduled by DCI, the second PUSCH always carries a CSI report. Whenever it is a retransmission of the first PUSCH, the PUSCH always carries a CSI report, and the terminal device can distinguish whether the sent PUSCH is a retransmission of the first PUSCH.

[0138] The following explains how to obtain the parameters used to determine the number of resource particles (REs) in the CSI report.

[0139] In some embodiments, the terminal device determines the number of resource particles (REs) occupied by the first CSI report or the second CSI report based on a first parameter, wherein the first parameter includes a first offset β and / or a first scaling factor α; the first parameter is indicated by a cell handover command or RAR UL grant or DCI or DCI format 0_0; and / or, the first parameter is the first parameter in a set of configured parameters, wherein the set of parameters includes one or more parameters.

[0140] In some embodiments, the CSI report can be multiplexed on the PUSCH as UCI, and the number of REs Q' occupied by UCI (also referred to as the number of modulation symbols per layer of UCI, or the number of REs used for UCI transmission) can be determined according to the first offset β and / or the first scaling factor α, for example as shown in formulas (1) to (3):

[0141] Wherein, offset β ( or or The scaling factor α is used to control the ratio between the PUSCH bit rate and the UCI bit rate, and the scaling factor α is used to control the upper limit of each modulation symbol in the UCI layer; the meanings of other parameters can be found in related technologies, and this application does not limit them, for example:

[0142] -K r It is the number of bits in the r-th code block of UL-SCH;

[0143] -C UL-SCH It is the number of code blocks in UL-SCH;

[0144] - It is the number of OFDM symbols in PUSCH (including DMRS);

[0145] - It is the number of REs available for UCI transmission in OFDM symbol 1; for OFDM symbols including DMRS, For OFDM symbols that do not include DMRS, It equals the number of subcarriers of PUSCH minus the number of subcarriers of PTRS;

[0146] -O ACK It is the number of HARQ-ACK bits;

[0147] -L ACK It is the number of CRC bits for HARQ-ACK;

[0148] -O CSI-1 It is the number of bits in CSI part 1;

[0149] -L CSI-1 This is the number of CRC bits in CSI Part 1;

[0150] -O CSI-2 It is the number of bits in CSI part 2;

[0151] -L CSI-2 It is the number of CRC bits in CSI part 2.

[0152] In some examples, the first parameter is the first parameter in a configured parameter set, which may contain one or more parameters. When the parameter set contains only one parameter, the number of REs for the CSI report is determined directly based on that parameter. When the parameter set contains multiple parameters, the number of REs is determined based on a specific parameter. The parameter set may be configured within ltm-CandidateConfig, or within LTM-Candidate and outside ltm-CandidateConfig, or within LTM-Config and outside LTM-Candidate. These are merely examples, and the embodiments of this application are not intended to limit the scope of the application.

[0153] For example, a terminal device can be provided with configuration information for multiple candidate cells (i.e., multiple ltm-CandidateConfigs), allowing it to quickly apply the configuration information of a candidate cell for communication after switching to that cell. The content of candidate cell configuration information in LTM scenarios is similar to that in non-LTM scenarios. For instance, candidate cell configuration information may include one or more betas (βs). When only one β is included, that β is used. When multiple βs are included, the beta_offset indicator field in the DCI can be used to indicate a specific β among the multiple βs during PUSCH scheduling by DCI, for use by CSI when multiplexing it onto the PUSCH. However, for PUSCHs scheduled by RAR UL grants, existing RAR UL grants do not include a field indicating the β.

[0154] The following explains how β is determined when CSI is multiplexed onto a PUSCH scheduled by a RAR UL grant.

[0155] The terminal device can be configured with a set of βs, which includes one or more βs. When a single β is included, that β is used. When multiple βs are included, the CSI report carried by the PUSCH of the RAR UL grant schedule can use a specific β from the set of βs (e.g., the first β).

[0156] Figure 10 is a schematic diagram of an LTM configuration (LTM-Config) according to an embodiment of this application. The β set can be configured within the RRC IE (Information Element) shown in Figure 10. For example, as shown in Figure 10, the terminal device is configured with an LTM-Config. An LTM-Config includes one or more LTM-Candidates, and an LTM-Candidate includes an ltm-CandidateConfig. The LTM-Config is used to provide all the configuration information required by LTM, the LTM-Candidate is used to provide the configuration information of a candidate cell, including the candidate cell configuration information used before and after CSC, and the ltm-CandidateConfig includes RRC Reconfiguration messages, which are mainly used to provide the candidate cell configuration information used after CSC. The β set can be configured, for example, in an RRC reconfiguration message within ltm-CandidateConfig; or, for example, the β set can be configured both within LTM-Candidate and outside ltm-CandidateConfig, meaning the IE configuring the β set is an Information Element (IE) at the same level as ltm-CandidateConfig; or, for example, the β set can be configured both within LTM-Config and outside LTM-Candidate, meaning the IE configuring the β set is an IE at the same level as LTM-Candidate.

[0157] For example, when the β set is configured in the RRC reconfiguration message within ltm-CandidateConfig, and when CSI is multiplexed on the PUSCH, the PUSCH scheduled by the RAR UL grant can use the first β in the β set. This β set can be determined according to betaOffsets shown in Table 1. As shown in Table 1, when betaOffsets is configured as dynamic, the β set includes N>1 βs; when betaOffsets is configured as semiStatic, it is equivalent to the β set including only 1 β. In this case, the PUSCH scheduled by the RAR UL grant uses this β, that is, the first β in the β set is this unique β.

[0158] Table 1:

[0159] In some examples, a field indicating a β can also be added to the RAR UL grant, and the PUSCH scheduled by the RAR UL grant uses the β indicated by this field. For example, a field in the RAR UL grant indicates a β in the β set. Similarly, a field indicating a β can also be added to the DCI format 0_0, and the PUSCH scheduled by the DCI format 0_0 can use the β indicated by this field.

[0160] The above explanation uses only a RAR UL grant scheduled PUSCH as an example. This application is not limited to this; CSC scheduled PUSCH can also be determined using the above method and β can be used. Furthermore, the above method can also be used for configured grant PUSCH and / or DCI scheduled PUSCH sent on resources configured in RRC signaling.

[0161] The above example illustrates the determination of the first offset β. This application is not limited to this; similar methods can also be used to determine the first scaling factor α in the first parameter.

[0162] In some embodiments, the terminal device may also send a third PUSCH, which is later than the first successfully sent PUSCH; the third PUSCH carries a third CSI report, wherein the third PUSCH is a configured grant PUSCH sent on a resource configured by RRC signaling, or a PUSCH scheduled by DCI.

[0163] In the above embodiments, after successfully sending the first PUSCH, that is, the first successfully sent PUSCH, the terminal device can continue to send a third PUSCH carrying a CSI report. The third PUSCH can be a configured grant PUSCH or a dynamic grant PUSCH.

[0164] In some embodiments, the terminal device determines the number of REs for the third CSI report based on the second parameter, wherein the second parameter includes a second offset β and / or a second scaling factor α; the second parameter and the first parameter belong to the same parameter set, or belong to different parameter sets.

[0165] In other words, when a CSI is multiplexed onto a PUSCH, if the PUSCH (first or second) is no later than the first successfully transmitted PUSCH, the first parameter is used to determine the number of REs used by the first or second CSI report; if the PUSCH (third) is later than the first successfully transmitted PUSCH, the second parameter is used to determine the number of REs used by the third CSI report. The first and second parameters can come from the same parameter set, or from two independent parameter sets.

[0166] When the first parameter and the second parameter belong to the same parameter set, for example, when the β set is configured in the RRC reconfiguration message within ltm-CandidateConfig and CSI (or UCI) is multiplexed on the PUSCH, the first PUSCH uses the first β in the β set, wherein the first PUSCH can be a PUSCH scheduled by RAR UL grant, and / or, the third PUSCH uses the β indicated by DCI in the β set, wherein the third PUSCH can be a PUSCH scheduled by DCI format 0_1 ​​or DCI format 0_2 or DCI format 0_3, and / or, the third PUSCH uses the first β in the β set, wherein the third PUSCH can be a PUSCH scheduled by DCI format 0_0.

[0167] When the first parameter and the second parameter belong to different parameter sets, taking the first β set and the second β set as examples, the first β set and the second β set can be configured in the same information element or in different information elements. For example, the first β set and the second β set are configured in the RRC reconfiguration message within ltm-CandidateConfig. The first β set is determined according to betaOffsets configured as dynamic in Table 1, and the second β set is determined according to CG-UCI-OnPUSCH configured as semiStatic in Table 2. When CSI (or UCI) is multiplexed on a PUSCH, the first PUSCH uses the first β in the first β set, which can be a PUSCH scheduled by RAR UL grant. The third PUSCH uses the β uniquely contained in the second β set, which can be a Type 1 configured grant PUSCH.

[0168] Table 2:

[0169] For example, the first β set can be configured within LTM-Candidate and outside ltm-CandidateConfig, or within LTM-Config and outside LTM-Candidate. The second β set can be configured in the RRC reconfiguration message within ltm-CandidateConfig. In this case, the first PUSCH and / or retransmission for the first PUSCH can use the β in the first β set, and the third PUSCH can use the β in the second β set.

[0170] The above example illustrates the determination of the second offset β. This application is not limited to this; similar methods can also be used to determine the second scaling factor α in the second parameter.

[0171] In some embodiments, the first parameters for different types of first PUSCH or second PUSCH belong to the same parameter set, or to different parameter sets, wherein the different types of first PUSCH or second PUSCH include at least two of the following PUSCH:

[0172] The configured grant PUSCH is sent on the resource configured in the RRC signaling.

[0173] RAR UL grant schedule for PUSCH;

[0174] PUSCH scheduled by DCI;

[0175] PUSCH for cell handover command scheduling.

[0176] When CSI is reused on the first PUSCH or the second PUSCH, the β used by the different types of the first PUSCH or the second PUSCH can come from the same β set, or from two independent β sets.

[0177] For example, the third and fourth β sets are configured in the RRC reconfiguration message within ltm-CandidateConfig. The third β set is determined based on UCI-OnPUSCH in Table 1, and the fourth β set is determined based on CG-UCI-OnPUSCH configured as semiStatic in Table 2. When the first or second PUSCH is a PUSCH scheduled by RAR UL grant, a PUSCH scheduled by DCI, or a PUSCH scheduled by a cell handover command, the β in the third β set can be used; when the first or second PUSCH is a Type 1 configured grant PUSCH sent on resources configured by RRC signaling, the β in the fourth β set can be used.

[0178] In some embodiments, specifically for Example 2 above, to enable CBRA to support RAR UL grant scheduling, the PUSCH carries a CSI report. The terminal device determines the number of REs occupied by the first CSI report based on a third parameter, wherein the third parameter includes a third offset β and / or a third scaling factor α, and the third parameter is a cell-specific parameter.

[0179] In the above embodiments, when configuring β and α for determining the number of CSI report REs for terminal devices, the network device configures β and α as cell-specific parameters. That is, within the candidate cell or target cell, all terminal devices carrying CSI reports on the PUSCH scheduled by the RAR UL grant use the same β and the same α. The network device can ensure this during configuration. Therefore, in CBRA, after receiving the PUSCH scheduled by the RAR UL grant, the network device can still successfully demodulate the CSI report and other information in the PUSCH based on the common β and α parameters. β and α can be configured according to any of the aforementioned methods. Thus, both CFRA and CBRA support carrying CSI reports on the PUSCH scheduled by the RAR UL grant.

[0180] The following explains the first CSI report and / or the second CSI report.

[0181] In some embodiments, the first CSI report and / or the second CSI report include a Channel Quality Indicator (CQI) and / or a Precoding Matrix Indicator (PMI) and / or a Rank Indicator (RI) and / or a CSI-RS Resource Indicator (CRI). The terminal device multiplexes the CSI on the PUSCH for transmission, i.e., carries the CSI report in the PUSCH. The CSI report carried by the first PUSCH (the first CSI report) includes the CSI obtained based on a first set of measurement reference signals, and the CSI report carried by the second PUSCH (the second CSI report) includes the CSI obtained based on a second set of measurement reference signals. The first set of measurement reference signals and the second set of measurement reference signals may be the same or different. The measurement reference signals may be CSI-RS or SSB, and the CSI-RS may be periodic CSI-RS, semi-persistent CSI-RS, or aperiodic CSI-RS. For example, the terminal device may perform new measurements before sending the second PUSCH, thus carrying an updated CSI report on the second PUSCH; or, the terminal device may not update the CSI report, but carry a retransmission of the previous CSI report on the second PUSCH.

[0182] In some embodiments, taking the measurement reference signal as an example, the terminal device may also receive a channel state information reference signal (CSI-RS) according to a RAR UL grant or cell handover command or DCI or DCI format 0_0, wherein the first CSI report and / or the second CSI report are determined based on the measurement of the CSI-RS.

[0183] For example, the RAR UL grant, the cell handover command, or the DCI format 0_0 includes time-domain resource information indicating the reception of the CSI-RS, which is an aperiodic CSI-RS. The terminal device can obtain the CSI to be reported based on the measurement of the aperiodic CSI-RS; that is, the measurement reference signal associated with the CSI report is an aperiodic CSI-RS. Taking the RAR UL grant as an example, when the RAR UL grant schedules PUSCH, in addition to instructing the terminal device to send a CSI report, the RAR UL grant can also indicate to the terminal device the aperiodic CSI-RS that needs to be measured. For example, the RAR UL grant indicates a time-domain offset, and the terminal device determines in which time slot (or symbol) to receive and measure the aperiodic CSI-RS based on the time-domain offset.

[0184] The above explanation uses the PUSCH scheduled by RAR UL grant as an example. This application is not limited to this. The PUSCH scheduled by CSC, the PUSCH scheduled by DCI, and the PUSCH scheduled by DCI format 0_0 can use a similar method to determine the CSI report. The third CSI report can also be determined by referring to a similar method, which will not be elaborated here.

[0185] In some embodiments, the first CSI report and / or the second CSI report and / or the third CSI report are determined based on at least one of the following:

[0186] The cell handover command or the RAR UL grant or the DCI or the DCI format 0_0 indicates the CSI report configuration (CSI-ReportConfig);

[0187] The cell handover command, the RAR UL grant, the DCI, or the DCI format 0_0 indicates a CSI aperiodic trigger state (CSI-AperiodicTriggerState).

[0188] The CSI report configuration (CSI-ReportConfig) with the minimum configuration identifier (CSI-ReportConfigId) in the configured CSI report configuration set, wherein the CSI report configuration set includes one or more CSI report configurations (CSI-ReportConfig);

[0189] The first CSI-AperiodicTriggerState in the configured set of CSI-AperiodicTriggerStates, wherein the set of CSI-AperiodicTriggerStates includes one or more CSI-AperiodicTriggerStates.

[0190] In some embodiments, the CSI report configuration set is configured within ltm-CandidateConfig, or the CSI report configuration set is configured within LTM-Candidate and outside ltm-CandidateConfig. The CSI aperiodic trigger state set is configured within ltm-CandidateConfig, or the CSI aperiodic trigger state set is configured within LTM-Candidate and outside ltm-CandidateConfig; this is merely an example and is not intended to be limiting. "CSI report configuration" can be replaced with "CSI report configuration information".

[0191] For example, a CSI report can be determined based on the CSI report configuration information (CSI-ReportConfig). CSI-ReportConfig determines the specific content of the CSI report, such as which codebook the CSI was generated from, and / or which reports from PMI, CQI, RI, and CRI were included. CSI-ReportConfig is identified by the CSI report configuration information ID (CSI-ReportConfigId). Assuming the first, second, or third CSI report is an aperiodic CSI report, the terminal device can be configured with M (M≥1) trigger states (CSI-AperiodicTriggerState) via the RRC reconfiguration message within ltm-CandidateConfig. One trigger state can be associated with one or more CSI-ReportConfigs. For PUSCHs scheduled using DCI format 0_1, DCI format 0_2, or DCI format 0_3, the CSI request field in the DCI can be wider than 1 bit. Therefore, one trigger state can be indicated among M trigger states (a CSI request field of 0 indicates no CSI report is triggered), allowing the end device to know which CSI reports are carried on the PUSCH. However, for PUSCHs scheduled using RAR UL grants, the existing RAR UL grant only includes a 1-bit CSI request field, making it impossible for the end device to determine which of the M trigger states it is based on this field.

[0192] The following section uses the PUSCH scheduled by RAR UL grant as an example to explain how terminal devices determine which CSI reports to carry.

[0193] For example, for a PUSCH scheduled by RAR UL grant, the CSI report it carries can be determined based on a specific CSI-ReportConfig configured within ltm-CandidateConfig. For instance, if the RRC reconfiguration message within ltm-CandidateConfig configures one or more CSI-ReportConfigs, when only one CSI-ReportConfig is configured, the report is determined based on that single CSI-ReportConfig. When multiple CSI-ReportConfigs are configured, the CSI report carried by the PUSCH scheduled by RAR UL grant is determined based on the CSI-ReportConfig with the smallest CSI-ReportConfigId.

[0194] For example, for a PUSCH scheduled by a RAR UL grant, the CSI report it carries is determined based on a specific trigger state configured in ltm-CandidateConfig. For instance, if the RRC reconfiguration message in ltm-CandidateConfig is configured with one or more trigger states, the CSI report is determined based on that single trigger state when only one trigger state is configured, and if multiple trigger states are configured, the CSI report is determined based on one or more CSI-ReportConfigs associated with the first trigger state.

[0195] For example, to determine the CSI report carried by the PUSCH scheduled for a RAR UL grant, a dedicated CSI-ReportConfig or trigger state can be configured for it, instead of relying on the CSI-ReportConfig or trigger state configured within the ltm-CandidateConfig. For instance, one or more CSI-ReportConfigs or trigger states can be configured both within the LTM-Candidate and outside the ltm-CandidateConfig. When only one trigger state or CSI-ReportConfig is configured, the determination is based on that single trigger state or CSI-ReportConfig. When multiple trigger states or multiple CSI-ReportConfigs are configured, the determination is based on one or more CSI-ReportConfigs associated with the first trigger state, or on the CSI-ReportConfig with the smallest CSI-ReportConfigId.

[0196] For example, a new field can be added to a RAR UL grant to explicitly indicate a CSI-ReportConfig or trigger status. For instance, a field in a RAR UL grant might indicate a CSI-ReportConfig (or trigger status) within a set of CSI-ReportConfig (or trigger status). A field set to 0 indicates that a CSI report is not triggered.

[0197] The above explanation uses a PUSCH scheduled by RAR UL grant as an example. This application is not limited to this. PUSCHs scheduled by CSC, DCI format 0_0, or DCI also have similar problems. For example, existing CSC and DCI format 0_0 do not include the CSI request field, and the above method can also be used to solve this problem.

[0198] It is worth noting that the above figures are merely illustrative of embodiments of this application, and the application is not limited thereto. For example, the execution order between various operations can be appropriately adjusted, and other operations can be added or some operations can be removed. Those skilled in the art can make appropriate modifications based on the above description, and are not limited to the description in the above figures.

[0199] The above embodiments are merely illustrative examples of the embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined. The embodiments of this application are illustrated using two reports as an example, but can be extended to cases with more than two reports, which will not be elaborated further.

[0200] In the embodiments of this application, the PUSCH sent by the terminal device for the first time after the cell handover command and its retransmission carry a CSI report. The PUSCH can be at least one of the configured grant PUSCH of RRC, the PUSCH scheduled by DCI, the PUSCH scheduled by RAR UL grant, or the PUSCH scheduled by the cell handover command. Therefore, there will be no ambiguity in the assumptions of the network device and the terminal device regarding the transmission and reception of the CSI report. The CSI report can be obtained by the network device faster and more reliably after the handover. Thus, the network device can select a better Multiple-Input Multiple-Output transmission scheme and modulation and coding method for uplink and downlink transmission, which is beneficial to quickly achieve high throughput or high reliability transmission after cell handover.

[0201] Second aspect of the embodiments

[0202] This application provides a report sending method, described from the perspective of a terminal device. Content identical to that in the first aspect of the embodiment will not be repeated.

[0203] Figure 11 is a schematic diagram of a report sending method according to an embodiment of this application. As shown in Figure 11, the method includes:

[0204] 1101, the terminal device receives a cell handover command for Layer 1 or Layer 2 mobility (LTM) triggering;

[0205] 1102, The terminal device sends a first Physical Uplink Shared Channel (PUSCH) and a second PUSCH, the first PUSCH and the second PUSCH being no later than the first successfully transmitted PUSCH.

[0206] In this embodiment of the application, the first PUSCH carries a CSI report, while the second PUSCH does not carry a CSI report;

[0207] Both the first PUSCH and the second PUSCH are configured grant PUSCHs sent on resources configured by Radio Resource Control (RRC) signaling, and / or the second PUSCH is a retransmission of the first PUSCH.

[0208] The implementation of operation 1101 can be referred to embodiment 801 of the first aspect, which will not be repeated here.

[0209] In some embodiments, the terminal device determines the timing advance (TA) for the first PUSCH and / or the second PUSCH based on the timing advance command (TAC) field in the cell handover command. For details, please refer to the embodiments of the first aspect, which will not be repeated here.

[0210] In some embodiments, the method for determining the CSI report and the method for determining the number of REs can refer to the embodiments of the first aspect.

[0211] For example, after receiving a CSC, the terminal device sends a first PUSCH and a second PUSCH to the candidate cell indicated by the CSC. The first PUSCH is the first PUSCH sent by the terminal device to the candidate cell after the CSC, and the second PUSCH is a retransmission of the first PUSCH. The implementation of the first PUSCH can refer to the embodiment of the first aspect. In this case, only the first PUSCH can carry a CSI report, and the second PUSCH cannot carry a CSI report. This simplifies the design and reduces the impact on existing standards. Even if the CSI report carried by the first PUSCH is not correctly demodulated, the network device can continue to instruct the terminal device to send CSI reports after completing the first successful PUSCH transmission.

[0212] For example, although the second PUSCH is a retransmission of the first PUSCH, the first PUSCH carries a CSI report only if both the first and second PUSCHs are configured grant PUSCHs sent on resources configured by RRC signaling, while the second PUSCH cannot carry a CSI report. For other cases of the first and second PUSCHs, the first PUSCH carries a CSI report, and the second PUSCH may or may not carry a CSI report. Whether or not a CSI report is carried depends on the DCI indicating the scheduling of the second PUSCH. For example, if the DCI scheduling the second PUSCH does not include a CSI request field, the second PUSCH does not carry a CSI report; if the DCI scheduling the second PUSCH includes a CSI request field, the CSI request field indicates whether the second PUSCH carries a CSI report.

[0213] It is worth noting that Figure 11 above is only an illustrative description of the embodiments of this application, but this application is not limited thereto. For example, the execution order between various operations can be appropriately adjusted, and other operations can be added or some operations can be removed. Those skilled in the art can make appropriate modifications based on the above content, and are not limited to the description in Figure 11 above.

[0214] The above embodiments are merely illustrative examples of embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined.

[0215] In this embodiment, the terminal device carries a CSI report on the first PUSCH sent after the cell handover command, but does not carry a CSI report on retransmissions of the first PUSCH. The PUSCH can be at least one of the following: a configured grant PUSCH from RRC, a DCI-scheduled PUSCH, a RAR UL grant-scheduled PUSCH, or a PUSCH scheduled by the cell handover command. This simplifies the design and reduces the impact on existing standards. If the CSI report carried on the first PUSCH is not correctly demodulated, the network device can instruct the terminal device to send a CSI report after completing the first successful PUSCH transmission.

[0216] Third aspect of the embodiments

[0217] This application provides a report receiving method, described from the perspective of a network device. The embodiments of the third aspect can be combined with the embodiments of the first or second aspect, and the content identical to that of the first or second aspect will not be repeated.

[0218] Figure 12 is a schematic diagram of a report receiving method according to an embodiment of this application. As shown in Figure 12, the method includes:

[0219] 1201, the network device sends a cell handover command for Layer 1 or Layer 2 triggered mobility (LTM);

[0220] 1202, the network device receives a first Physical Uplink Shared Channel (PUSCH), or receives a first PUSCH and a second PUSCH, wherein the first PUSCH and the second PUSCH are no later than the first successfully transmitted PUSCH.

[0221] In this embodiment of the application, the first PUSCH carries a first channel state information (CSI) report, and the first PUSCH satisfies at least one of the following:

[0222] The first PUSCH is a configured grant PUSCH sent on the resources configured by Radio Resource Control (RRC) signaling;

[0223] The first PUSCH is the PUSCH scheduled by the Random Access Response Uplink Grant (RAR UL grant);

[0224] The first PUSCH is the PUSCH for downlink control information scheduling;

[0225] The first PUSCH is the PUSCH scheduled by the cell handover command;

[0226] And / or,

[0227] The second PUSCH carries a second CSI report, and the second PUSCH satisfies at least one of the following:

[0228] The second PUSCH is a configured grant PUSCH sent on resources configured by Radio Resource Control (RRC) signaling;

[0229] The second PUSCH is a PUSCH scheduled using downlink control information format 0_0 (DCI format 0_0);

[0230] The second PUSCH is a retransmission of the first PUSCH.

[0231] The implementation methods of operations 1201-1202 can be referred to embodiments 801-802 of the first aspect, which will not be repeated here.

[0232] Figure 13 is another schematic diagram of the report receiving method according to an embodiment of this application. As shown in Figure 13, the method includes:

[0233] 1301, the network device sends a cell handover command for Layer 1 or Layer 2 triggered mobility (LTM);

[0234] 1302, the network device receives a first Physical Uplink Shared Channel (PUSCH) and a second PUSCH, the first PUSCH and the second PUSCH being no later than the first successfully transmitted PUSCH.

[0235] In this embodiment, the first PUSCH carries a CSI report, while the second PUSCH does not carry a CSI report; both the first PUSCH and the second PUSCH are configured grant PUSCHs sent on resources configured by Radio Resource Control (RRC) signaling, and / or the second PUSCH is a retransmission of the first PUSCH.

[0236] The implementation methods of operations 1301-1302 can be referred to embodiments 1101-1102 of the second aspect, which will not be repeated here.

[0237] In 1301 and 1302, "receiving PUSCH" by a network device indicates that the terminal device is attempting to receive or has begun receiving PUSCH, or is detecting PUSCH; it does not necessarily mean that the PUSCH has been successfully received. In other words, "receiving" in 1301 and 1302 refers to the process of receiving, not to the result of receiving the PUSCH; the result includes both receiving and not receiving the PUSCH.

[0238] In some embodiments, the methods in Figures 12 and 13 may further include (not shown): the network device sending at least one of the following to the terminal device: sending a Radio Resource Control (RRC) signaling before the CSC, the RRC signaling indicating a configured grant PUSCH; and / or sending a random access response uplink grant after the CSC; and / or sending downlink control information after the CSC.

[0239] It is worth noting that Figures 12 and 13 above are merely illustrative of embodiments of this application, but this application is not limited thereto. For example, the execution order between various operations can be appropriately adjusted, and other operations can be added or some operations can be removed. Those skilled in the art can make appropriate modifications based on the above description, and are not limited to the descriptions in Figures 12 and 13 above.

[0240] The above embodiments are merely illustrative examples of embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined.

[0241] In some embodiments of this application, the PUSCH sent by the terminal device for the first time after the cell handover command and its retransmission carry a CSI report. The PUSCH can be at least one of the configured grant PUSCH of RRC, the PUSCH scheduled by DCI, the PUSCH scheduled by RAR UL grant, or the PUSCH scheduled by the cell handover command. Thus, there is no ambiguity in the assumptions of the network device and the terminal device regarding the transmission and reception of the CSI report. The CSI report can be obtained by the network device faster and more reliably after the handover. Therefore, the network device can select a better Multiple-Input Multiple-Output transmission scheme and modulation and coding method for uplink and downlink transmission, which is beneficial to quickly achieve high throughput or high reliability transmission after cell handover.

[0242] In some embodiments of this application, the terminal device does not carry a CSI report in the retransmission of the first PUSCH after a cell handover command. This simplifies the design and reduces the impact on existing standards. If the CSI report carried in the first PUSCH is not correctly demodulated, the network device can instruct the terminal device to send a CSI report after completing the first successful PUSCH transmission.

[0243] Fourth aspect of the embodiment

[0244] This application provides a report sending device. This device may be, for example, a terminal device, or one or more components or parts configured on a terminal device; details identical to those in the first or second aspect of the embodiment will not be repeated.

[0245] Figure 14 is a schematic diagram of a report sending apparatus according to an embodiment of this application. As shown in Figure 14, the report sending apparatus 1400 includes a receiver 1401 and a transmitter 1402.

[0246] In some implementations, receiver 1401 receives a cell handover command for Layer 1 or Layer 2 triggered mobility (LTM); transmitter 1402 transmits a first Physical Uplink Shared Channel (PUSCH), or transmits a first PUSCH and a second PUSCH; the first PUSCH and / or the second PUSCH is no later than the first successfully transmitted PUSCH; wherein the first PUSCH carries a first Channel State Information (CSI) report, and the first PUSCH satisfies at least one of the following:

[0247] The first PUSCH is a configured grant PUSCH sent on the resources configured by Radio Resource Control (RRC) signaling;

[0248] The first PUSCH is the PUSCH scheduled by the Random Access Response Uplink Grant (RAR UL grant);

[0249] The first PUSCH is the PUSCH for downlink control information scheduling;

[0250] The first PUSCH is the PUSCH scheduled by the cell handover command;

[0251] And / or,

[0252] The second PUSCH carries a second CSI report, and the second PUSCH satisfies at least one of the following:

[0253] The second PUSCH is a configured grant PUSCH sent on resources configured by Radio Resource Control (RRC) signaling;

[0254] The second PUSCH is a PUSCH scheduled using downlink control information format 0_0 (DCI format 0_0);

[0255] The second PUSCH is a retransmission of the first PUSCH.

[0256] In some embodiments, the apparatus 1400 further includes a processor 1403 that determines timing advance (TA) for the first PUSCH and / or the second PUSCH based on the timing advance command (TAC) field in the cell handover command.

[0257] The implementation of the processor 1403 can be referred to the embodiments of the first aspect, and will not be repeated here.

[0258] In some implementations, receiver 1401 receives a cell handover command for Layer 1 or Layer 2 triggered mobility (LTM); transmitter 1402 transmits a first Physical Uplink Shared Channel (PUSCH) and a second PUSCH; the first PUSCH and / or the second PUSCH is no later than the first successfully transmitted PUSCH; wherein the first PUSCH carries a CSI report, and the second PUSCH does not carry a CSI report; both the first PUSCH and the second PUSCH are configured grant PUSCHs transmitted on resources configured by Radio Resource Control (RRC) signaling, and / or the second PUSCH is a retransmission of the first PUSCH.

[0259] Regarding the implementation of receiver 1401 and transmitter 1402, please refer to the embodiments of the first and second aspects, which will not be repeated here.

[0260] It is worth noting that the above description only covers the components or modules relevant to this application, but this application is not limited thereto. The report sending device 1400 may also include other components or modules, and for details regarding these components or modules, please refer to related technologies.

[0261] Furthermore, for simplicity, Figure 14 only illustrates the connection relationships or signal flow between the various components or modules, but those skilled in the art should understand that various related technologies such as bus connections can be used. The aforementioned components or modules can be implemented using hardware facilities such as processors, memory, transmitters, and receivers; this application does not limit this implementation.

[0262] In some embodiments of this application, the PUSCH sent by the terminal device for the first time after the cell handover command and its retransmission carry a CSI report. The PUSCH can be at least one of the configured grant PUSCH of RRC, the PUSCH scheduled by DCI, the PUSCH scheduled by RAR UL grant, or the PUSCH scheduled by the cell handover command. Thus, there is no ambiguity in the assumptions of the network device and the terminal device regarding the transmission and reception of the CSI report. The CSI report can be obtained by the network device faster and more reliably after the handover. Therefore, the network device can select a better Multiple-Input Multiple-Output transmission scheme and modulation and coding method for uplink and downlink transmission, which is beneficial to quickly achieve high throughput or high reliability transmission after cell handover.

[0263] In some embodiments of this application, the terminal device does not carry a CSI report in the retransmission of the first PUSCH after a cell handover command. This simplifies the design and reduces the impact on existing standards. If the CSI report carried in the first PUSCH is not correctly demodulated, the network device can instruct the terminal device to send a CSI report after completing the first successful PUSCH transmission.

[0264] Fifth aspect of the embodiment

[0265] This application provides a report receiving device. This device may be, for example, a network device, or one or more components or parts configured within a network device; details identical to those in the embodiments of the first to third aspects will not be repeated.

[0266] Figure 15 is a schematic diagram of a report receiving device according to an embodiment of this application. As shown in Figure 15, the report receiving device 1500 includes a transmitter 1501 and a receiver 1502.

[0267] In some implementations, a transmitter 1501 transmits a cell handover command for Layer 1 or Layer 2 triggered mobility (LTM); a receiver 1502 receives a first Physical Uplink Shared Channel (PUSCH), or receives a first PUSCH and a second PUSCH; the first PUSCH and / or the second PUSCH is not later than the first successfully received PUSCH; wherein the first PUSCH carries a first Channel State Information (CSI) report, and the first PUSCH satisfies at least one of the following:

[0268] The first PUSCH is a configured grant PUSCH sent on the resources configured by Radio Resource Control (RRC) signaling;

[0269] The first PUSCH is the PUSCH scheduled by the Random Access Response Uplink Grant (RAR UL grant);

[0270] The first PUSCH is the PUSCH for downlink control information scheduling;

[0271] The first PUSCH is the PUSCH scheduled by the cell handover command;

[0272] And / or,

[0273] The second PUSCH carries a second CSI report, and the second PUSCH satisfies at least one of the following:

[0274] The second PUSCH is a configured grant PUSCH sent on resources configured by Radio Resource Control (RRC) signaling;

[0275] The second PUSCH is a PUSCH scheduled using downlink control information format 0_0 (DCI format 0_0);

[0276] The second PUSCH is a retransmission of the first PUSCH.

[0277] In some implementations, a transmitter 1501 transmits a cell handover command for Layer 1 or Layer 2 triggered mobility (LTM); a receiver 1502 receives a first Physical Uplink Shared Channel (PUSCH) and a second PUSCH; the first PUSCH and / or the second PUSCH is no later than the first successfully received PUSCH; wherein the first PUSCH carries a CSI report, and the second PUSCH does not carry a CSI report; both the first PUSCH and the second PUSCH are configured grant PUSCHs transmitted on resources configured by Radio Resource Control (RRC) signaling, and / or the second PUSCH is a retransmission of the first PUSCH.

[0278] For implementation details of transmitters 1501 and 1502, please refer to the embodiments of the first and second aspects.

[0279] It is worth noting that the above description only covers the components or modules relevant to this application, but this application is not limited thereto. The report receiving device 1500 may also include other components or modules, and for details regarding these components or modules, please refer to related technologies.

[0280] Furthermore, for simplicity, Figure 15 only illustrates the connection relationships or signal flow between the various components or modules, but those skilled in the art should understand that various related technologies such as bus connections can be used. The aforementioned components or modules can be implemented using hardware facilities such as processors, memory, transmitters, and receivers; this application does not limit this implementation.

[0281] In some embodiments of this application, the PUSCH sent by the terminal device for the first time after the cell handover command and its retransmission carry a CSI report. The PUSCH can be at least one of the configured grant PUSCH of RRC, the PUSCH scheduled by DCI, the PUSCH scheduled by RAR UL grant, or the PUSCH scheduled by the cell handover command. Thus, there is no ambiguity in the assumptions of the network device and the terminal device regarding the transmission and reception of the CSI report. The CSI report can be obtained by the network device faster and more reliably after the handover. Therefore, the network device can select a better Multiple-Input Multiple-Output transmission scheme and modulation and coding method for uplink and downlink transmission, which is beneficial to quickly achieve high throughput or high reliability transmission after cell handover.

[0282] In some embodiments of this application, the terminal device does not carry a CSI report in the retransmission of the first PUSCH after a cell handover command. This simplifies the design and reduces the impact on existing standards. If the CSI report carried in the first PUSCH is not correctly demodulated, the network device can instruct the terminal device to send a CSI report after completing the first successful PUSCH transmission.

[0283] Implementation of the sixth aspect

[0284] This application also provides a communication system, including network equipment and terminal equipment.

[0285] In the embodiments of this application, the terminal device, as the sending end of the report, may include the apparatus shown in FIG1400 of the fourth aspect embodiment, and is configured to perform the method of the first or second aspect embodiment. Since the method has been described in detail in the first and second aspect embodiments, its contents are incorporated herein and will not be repeated.

[0286] In the embodiments of this application, the network device, as the receiving end of the report, may include the apparatus shown in FIG1500 of the fifth aspect embodiment, which is configured to perform the method of the third aspect embodiment. Since the method has been described in detail in the embodiments of the first, second and third aspects, the contents of which are incorporated herein and will not be repeated.

[0287] In addition, the terminal device and the network device can also perform their respective regular operations, and the network device can also perform operations corresponding to the operations of the terminal device, such as the network device receiving information / signals from the terminal device, and / or the network device sending information / signals to the terminal device, the details of which are omitted here.

[0288] This application also provides a terminal device, which may be a UE, but this application is not limited to this and may also be other terminal devices.

[0289] Figure 16 is a schematic diagram of a terminal device according to an embodiment of this application. As shown in Figure 16, the terminal device 1600 may include a processor 1601 and a memory 1602; the memory 1602 stores data and programs and is coupled to the processor 1601. It is worth noting that this figure is exemplary; other types of structures may also be used to supplement or replace this structure to implement telecommunications functions or other functions.

[0290] In some embodiments, the functionality of the apparatus 1400 of the fourth aspect embodiment can be integrated into the processor 1601, wherein the processor 1601 can be configured to execute a program to implement the methods described in the embodiments of the first or second aspect, the contents of which are incorporated herein and will not be repeated here.

[0291] In other embodiments, the apparatus 1400 of the fourth aspect embodiment may be configured separately from the processor 1601. For example, the apparatus 1400 of the fourth aspect embodiment may be configured as a chip connected to the processor 1601, and the functions of the apparatus 1400 of the fourth aspect embodiment may be implemented through the control of the processor 1601.

[0292] As shown in Figure 16, the terminal device 1600 may further include: a communication module 1603, an input unit 1604, a display 1605, and a power supply 1606. The functions of these components are similar to those in the prior art and will not be described in detail here. It is worth noting that the terminal device 1600 does not necessarily include all the components shown in Figure 16; these components are not essential. Furthermore, the terminal device 1600 may also include components not shown in Figure 16, which can be referred to in related technologies.

[0293] This application also provides a network device, which may be, for example, a base station, but this application is not limited to this and may also be other network devices.

[0294] Figure 17 is a schematic diagram of the network device according to an embodiment of this application. As shown in Figure 17, the network device 1700 may include a processor 1701 and a memory 1702; the memory 1702 is coupled to the processor 1701. The memory 1702 can store various data; in addition, it also stores information processing programs, and executes the programs under the control of the processor 1701.

[0295] In some embodiments, the functionality of the apparatus 1500 of the fifth aspect embodiment can be integrated into the processor 1701, wherein the processor 1701 can be configured to execute a program to implement the method as described in the third aspect embodiment, the contents of which are incorporated herein and will not be repeated here.

[0296] In other embodiments, the apparatus 1500 of the fifth aspect embodiment may be configured separately from the processor 1701. For example, the apparatus 1500 of the fifth aspect embodiment may be configured as a chip connected to the processor 1701, and the functions of the apparatus 1500 of the fifth aspect embodiment may be implemented through the control of the processor 1701.

[0297] In addition, as shown in Figure 17, network device 1700 may also include transceivers 1703 and 1704. The functions of these components are similar to those in the prior art and will not be described again here. It is worth noting that network device 1700 does not necessarily need to include all the components shown in Figure 17; furthermore, network device 1700 may also include components not shown in Figure 17, which can be referred to in the prior art.

[0298] This application also provides a computer program, wherein when the program is executed in a terminal device, the program causes the terminal device to perform the method described in the embodiments of the first or second aspect.

[0299] This application also provides a storage medium storing a computer program, wherein the computer program causes a terminal device to perform the methods described in the embodiments of the first or second aspect.

[0300] This application also provides a computer program, wherein when the program is executed in a network device, the program causes the network device to perform the method described in the third aspect of the embodiments.

[0301] This application also provides a storage medium storing a computer program, wherein the computer program causes a network device to perform the methods described in the third aspect of the embodiments.

[0302] The apparatus and methods described above in this application can be implemented in hardware or in combination with software. This application relates to a computer-readable program that, when executed by a logic component, enables the logic component to implement the apparatus or components described above, or to implement the various methods or steps described above. This application also relates to storage media for storing the above programs, such as hard disks, magnetic disks, optical disks, DVDs, flash memory, etc.

[0303] The methods / apparatus described in conjunction with the embodiments of this application can be directly embodied in hardware, software modules executed by a processor, or a combination of both. For example, one or more and / or combinations of one or more functional block diagrams shown in the figures can correspond to various software modules in a computer program flow, or to various hardware modules. These software modules can correspond to the various steps shown in the figures, respectively. These hardware modules can be implemented, for example, using a field-programmable gate array (FPGA) to embed these software modules.

[0304] The software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. A storage medium can be coupled to the processor, enabling the processor to read information from and write information to the storage medium; or the storage medium can be an integral part of the processor. The processor and storage medium can reside in an ASIC. The software module can be stored in the memory of a mobile terminal or in a memory card that can be inserted into the mobile terminal. For example, if the device (such as a mobile terminal) uses a high-capacity MEGA-SIM card or a high-capacity flash memory device, the software module can be stored in the MEGA-SIM card or the high-capacity flash memory device.

[0305] One or more and / or one or more combinations of functional blocks described in the accompanying drawings can be implemented as a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or any suitable combination thereof for performing the functions described herein. One or more and / or one or more combinations of functional blocks described in the accompanying drawings can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in communication with a DSP, or any other such configuration.

[0306] The present application has been described above with reference to specific embodiments. However, those skilled in the art should understand that these descriptions are exemplary and not intended to limit the scope of protection of the present application. Those skilled in the art can make various modifications and variations to the present application based on its spirit and principles, and these modifications and variations are also within the scope of the present application.

[0307] The following notes are also included in relation to this application:

[0308] 1. A report sending device configured in a network device, the device comprising:

[0309] A transmitter that sends cell handover commands for Layer 1 or Layer 2 triggered mobility (LTM);

[0310] The receiver receives a first Physical Uplink Shared Channel (PUSCH) and a second PUSCH; the first PUSCH and the second PUSCH are no later than the first successfully transmitted PUSCH;

[0311] The first PUSCH carries a CSI report, while the second PUSCH does not carry a CSI report.

[0312] Both the first PUSCH and the second PUSCH are configured grant PUSCHs sent on resources configured by Radio Resource Control (RRC) signaling, and / or the second PUSCH is a retransmission of the first PUSCH.

Claims

1. A report sending device, configured in a terminal device, the device comprising: The receiver receives cell handover commands for mobility (LTM) triggered by Layer 1 or Layer 2. The transmitter transmits a first Physical Uplink Shared Channel (PUSCH), or transmits a first PUSCH and a second PUSCH, wherein the first PUSCH and / or the second PUSCH is no later than the first successfully transmitted PUSCH. The first PUSCH carries a first channel state information (CSI) report, and the first PUSCH satisfies at least one of the following: The first PUSCH is a configured grant PUSCH sent on the resources configured by Radio Resource Control (RRC) signaling; The first PUSCH is the PUSCH scheduled by the Random Access Response Uplink Grant (RAR UL grant); The first PUSCH is the PUSCH for downlink control information scheduling; The first PUSCH is the PUSCH scheduled by the cell handover command; And / or, The second PUSCH carries a second CSI report, and the second PUSCH satisfies at least one of the following: The second PUSCH is a configured grant PUSCH sent on resources configured by Radio Resource Control (RRC) signaling; The second PUSCH is a PUSCH scheduled using downlink control information format 0_0 (DCI format 0_0); The second PUSCH is a retransmission of the first PUSCH.

2. The apparatus according to claim 1, wherein, The device further includes: The processor determines the timing advance (TA) for the first PUSCH and / or the second PUSCH based on the timing advance command (TAC) field in the cell handover command.

3. The apparatus according to claim 1, wherein, The device also includes a processor; In the case where the first PUSCH is the PUSCH for random access response uplink grant scheduling. For a non-contention-based random access procedure, the processor determines whether the first PUSCH carries the first CSI report based on the CSI request field in the RAR UL grant. In a contention-based random access procedure, the processor determines that the CSI request field in the RAR UL grant is reserved.

4. The apparatus according to claim 1, wherein, The device also includes a processor; In the case where the first PUSCH is the PUSCH for random access response uplink grant scheduling. The processor determines whether the first PUSCH carries the first CSI report based on the CSI request field in the RAR UL grant.

5. The apparatus according to claim 1, wherein, The device also includes a processor; The processor determines the number of resource particles (REs) occupied by the first CSI report or the second CSI report according to a first parameter, wherein the first parameter includes a first offset β and / or a first scaling factor α; The first parameter is indicated by the cell handover command, the RAR UL grant, the DCI, or the DCI format 0_0; and / or, The first parameter is the first parameter in the set of configured parameters, wherein the set of parameters includes one or more parameters.

6. The apparatus according to claim 5, wherein, The parameter set is configured within ltm-CandidateConfig, or the parameter set is configured within LTM-Candidate and outside ltm-CandidateConfig, or the parameter set is configured within LTM-Config and outside LTM-Candidate.

7. The apparatus according to claim 5, wherein, The transmitter also sends a third PUSCH; the third PUSCH is later than the first successfully transmitted PUSCH. The third PUSCH carries a third CSI report, wherein the third PUSCH is a configured grant PUSCH sent on a resource configured by RRC signaling, or a PUSCH scheduled by DCI.

8. The apparatus according to claim 7, wherein, The processor determines the number of REs occupied by the third CSI report according to the second parameter, wherein the second parameter includes a second offset β and / or a second scaling factor α; The second parameter and the first parameter belong to the same parameter set, or they belong to different parameter sets.

9. The apparatus according to claim 5, wherein, The first parameters for different types of first or second PUSCH belong to the same parameter set, or to different parameter sets, wherein the different types of first or second PUSCH include at least two of the following PUSCH: The configured grant PUSCH is sent on the resource configured in the RRC signaling. RAR UL grant schedule for PUSCH; PUSCH scheduled by DCI; The PUSCH for scheduling the cell handover command.

10. The apparatus according to claim 4, wherein, The processor determines the number of REs in the first CSI report based on a third parameter, wherein the third parameter includes a third offset β and / or a third scaling factor α, and the third parameter is a cell-specific parameter.

11. The apparatus according to claim 1, wherein, The first CSI report and / or the second CSI report are determined based on at least one of the following: The cell handover command or the RAR UL grant or the DCI or the DCI format 0_0 indicates the CSI report configuration (CSI-ReportConfig); The cell handover command, the RAR UL grant, the DCI, or the DCI format 0_0 indicates the CSI aperiodic trigger state (CSI-AperiodicTriggerState); The CSI report configuration (CSI-ReportConfig) with the minimum configuration identifier (CSI-ReportConfigId) in the configured CSI report configuration set, wherein the CSI report configuration set includes one or more CSI report configurations (CSI-ReportConfig); The first CSI-AperiodicTriggerState in the configured set of CSI-AperiodicTriggerStates, wherein the set of CSI-AperiodicTriggerStates includes one or more CSI-AperiodicTriggerStates.

12. The apparatus according to claim 11, wherein, The CSI report configuration set is configured within ltm-CandidateConfig, or the CSI report configuration set is configured within LTM-Candidate and outside ltm-CandidateConfig; The CSI aperiodic trigger state set is configured within ltm-CandidateConfig, or the CSI aperiodic trigger state set is configured within LTM-Candidate and outside ltm-CandidateConfig.

13. The apparatus according to claim 1, wherein, The receiver also receives a Channel State Information Reference Signal (CSI-RS) based on the RAR UL grant, the cell handover command, the DCI, or the DCI format 0_0, wherein the first CSI report and / or the second CSI report are determined based on measurements of the CSI-RS.

14. The apparatus according to claim 1 or 7, wherein, The first CSI report and / or the second CSI report and / or the third CSI report include a channel quality indicator (CQI) and / or a precoding matrix indicator (PMI) and / or a rank indicator (RI) and / or a CSI-RS resource indicator (CRI).

15. The apparatus according to claim 1, wherein, The first PUSCH is the first PUSCH sent by the transmitter to the candidate cell indicated by the cell handover command after the receiver receives the cell handover command.

16. A report sending device configured in a terminal device, the device comprising: The receiver receives cell handover commands for mobility (LTM) triggered by Layer 1 or Layer 2. A transmitter that transmits a first Physical Uplink Shared Channel (PUSCH) and a second PUSCH; the first PUSCH and the second PUSCH are no later than the first successfully transmitted PUSCH; The first PUSCH carries a CSI report, while the second PUSCH does not carry a CSI report. Both the first PUSCH and the second PUSCH are configured grant PUSCHs sent on resources configured by Radio Resource Control (RRC) signaling, and / or the second PUSCH is a retransmission of the first PUSCH.

17. The apparatus according to claim 16, wherein, The device further includes: The processor determines the timing advance (TA) for the first PUSCH and / or the second PUSCH based on the timing advance command (TAC) field in the cell handover command.

18. The apparatus according to claim 16, wherein, The CSI report includes a Channel Quality Indicator (CQI) and / or a Precoding Matrix Indicator (PMI) and / or a Rank Indicator (RI) and / or a CSI-RS Resource Indicator (CRI).

19. The apparatus according to claim 16, wherein, The first PUSCH is the first PUSCH sent by the transmitter to the candidate cell indicated by the cell handover command after the receiver receives the cell handover command.

20. A report receiving device configured in a network device, the device comprising: A transmitter that sends cell handover commands for Layer 1 or Layer 2 triggered mobility (LTM); The receiver receives a first Physical Uplink Shared Channel (PUSCH), or receives a first PUSCH and a second PUSCH; the first PUSCH and / or the second PUSCH is no later than the first successfully received PUSCH. The first PUSCH carries a first channel state information (CSI) report, and the first PUSCH satisfies at least one of the following: The first PUSCH is a configured grant PUSCH sent on the resources configured by Radio Resource Control (RRC) signaling; The first PUSCH is the PUSCH scheduled by the Random Access Response Uplink Grant (RAR UL grant); The first PUSCH is the PUSCH for downlink control information scheduling; The first PUSCH is the PUSCH scheduled by the cell handover command; And / or, The second PUSCH carries a second CSI report, and the second PUSCH satisfies at least one of the following: The second PUSCH is a configured grant PUSCH sent on resources configured by Radio Resource Control (RRC) signaling; The second PUSCH is a PUSCH scheduled using downlink control information format 0_0 (DCI format 0_0); The second PUSCH is a retransmission of the first PUSCH.

Images