Low layer triggered mobility ad hoc networks

Abstract

Systems, methods, and apparatus for wireless communication are described. One example method includes: a wireless device transmitting failure report information or suboptimal success mobility report information regarding mobility robustness optimization for Layer 1 or Layer 2 triggered mobility (LTM). Another example method includes: a wireless device transmitting a list of subsequent LTM trajectory information, wherein the subsequent LTM trajectory information is used to update LTM mobility history information. The failure report information, suboptimal success mobility report information, and subsequent LTM trajectory information, among other advantages, are used to improve the quality of LTM.

Description

Technical Field

[0001] This patent document generally relates to wireless communication. Background Technology

[0002] Mobile communication technologies are propelling the world toward an increasingly interconnected and networked society. Compared to existing wireless networks, next-generation systems and wireless communication technologies will need to support a wider range of use case characteristics and provide more complex, granular access requirements and flexibility.

[0003] Long Term Evolution (LTE) is a wireless communication standard for mobile devices and data terminals developed by the 3rd Generation Partnership Project (3GPP). LTE Advanced (LTE-A) is a wireless communication standard that enhances this LTE standard. Fifth-generation wireless systems (known as 5G) advance the LTE and LTE-A wireless standards and are designed to support higher data rates, massive connectivity, ultra-low latency, high reliability, and other emerging service requirements. Summary of the Invention

[0004] This patent document discloses a method for improving Low Layer Triggered Mobility (LTM) quality. The network may not always be able to provide the user equipment (UE) with an optimal LTM configuration. The UE can report suboptimal LTM cell handover processes and / or failure reports to the network to improve LTM cell handover or handover performance.

[0005] The first example wireless communication method includes: a wireless device sending a failure report message regarding mobility robustness optimization for Layer 1 or Layer 2 triggered mobility (LTM).

[0006] The second example wireless communication method includes: updating suboptimal successful mobility report information regarding mobility robustness optimization for Layer 1 or Layer 2 triggered mobility (LTM) based on the condition being met by a wireless device. The method further includes: transmitting the suboptimal successful mobility report information by the wireless device.

[0007] The third example wireless communication method includes: a list of subsequent Layer 1 or Layer 2 triggered mobility (LTM) trajectory information transmitted by a wireless device, wherein the subsequent LTM trajectory information is used to update LTM mobility history information.

[0008] The fourth example wireless communication method includes: receiving, by a distributed unit (DU) of a network device, at least one of the following information about a Layer 1 or Layer 2 triggered mobility (LTM) ad hoc network: failure report information; suboptimal successful mobility report information; or subsequent LTM trajectory information.

[0009] The fifth example wireless communication method includes: receiving by a network device at least one of the following information about a Layer 1 or Layer 2 triggered mobility (LTM) ad hoc network: failure report information; suboptimal successful mobility report information; or subsequent LTM trajectory information.

[0010] Note that, where this patent document discloses a method for sending information from a first device to a second device, it should be understood that a method for the second device to receive such information from the first device is also disclosed. Similarly, where a method for the first device to receive a message from a second device is disclosed, it should be understood that the message is sent from the second device to the first device.

[0011] In yet another example embodiment, an apparatus configured or operable to perform the methods described above is disclosed. The apparatus includes at least one processor configured to implement the methods described above.

[0012] In yet another example embodiment, the above method is implemented in the form of processor-executable code and stored in a non-transitory computer-readable storage medium. When executed by a processor, the code stored in the computer-readable storage medium causes the processor to implement the method described in this patent document.

[0013] The above and other aspects, and their implementations, are described in more detail in the accompanying drawings, specification, and claims. Attached Figure Description

[0014] Figures 1 to 8 An example scenario is shown for improving user equipment (UE) reporting of lower-layer triggered mobility (LTM).

[0015] Figure 9 An example network interface is shown.

[0016] Figure 10 This is a sample flowchart for sending failure report information.

[0017] Figure 11 This is a sample flowchart for sending suboptimal success mobility report information.

[0018] Figure 12 This is a sample flowchart for sending LTM trajectory information.

[0019] Figure 13 This is an example flowchart of how a network device's distributed unit (DU) receives LTM information.

[0020] Figure 14This is a sample flowchart of how network devices receive LTM information.

[0021] Figure 15 An example block diagram of a hardware platform is shown, which may be part of a network device or a wireless device.

[0022] Figure 16 Example wireless communications, including base stations (BS) and user equipment (UE), are shown based on some implementations of the disclosed technology. Detailed Implementation

[0023] The example headings in the following sections are provided for ease of understanding of the disclosed subject matter and do not limit the scope of the claimed subject matter in any way. Therefore, one or more features of one example section may be combined with one or more features of another example section. Furthermore, the term "5G" is used for clarity, but the technologies disclosed in this document are not limited to 5G technology and can be used in wireless systems implementing other protocols.

[0024] I. Introduction This patent document discloses a method for reporting suboptimal low-layer triggered mobility (LTM) cell handover processes and / or failure reports to the network. Among other advantages, the disclosed method improves the quality of LTM cell handover and handover.

[0025] 3GPP Rel-18 introduced support for LTM (L1 / L2 triggered mobility: a cell handover process triggered by the network based on L1 measurements via MAC CE (Medium Access Control Element)) to further enhance UE mobility, avoid full L2 (and L1) resets, reduce latency / overhead / disruptions, and provide a mobility experience similar to beam-switching mobility.

[0026] However, the current 3GPP SON / MDT (Self-Organizing Network and Minimization of Drive Testing) technology does not yet cover LTM. Specifically, Mobility Robustness Optimization (MRO) in SON needs to be enhanced to better support LTM, enabling the network to better detect failures, suboptimal successful LTMs, or poor implementations during the LTM process.

[0027] This patent document addresses the following issues: - Identify potential problems (e.g., failures during LTM, suboptimal successful LTM, poor implementation, inappropriate LTM candidate configurations, or inappropriate cell handover command decisions). This is the first step in identifying SON enhancements for LTM, which bring new elements to traditional mobility processes, such as RACH-free LTM with early synchronization and beam-level operation.

[0028] - Define the basic information that the UE needs to provide to the network to help the network make better LTM decisions in LTM configuration / timing, etc.

[0029] - Define key interface enhancements for the network to allow the network to support MRO enhancements for LTM, such as enhancing the F1AP interface between gNB-CU and gNB-DU, and enhancing the XnAP interface between two network nodes.

[0030] MRO (Mobile Operations Recovery) is a 3GPP technology dating back to the LTE era, which identifies several key scenarios, such as premature handover (HO), late HO, and incorrect cell handover. In these scenarios, 3GPP has defined information that the UE can trigger to record and upload to the network upon network request. This includes UE measurements, the time from triggering the HO to the occurrence of HO failure or radio link failure (RLF), the cell the UE reconnects to to re-establish the RRC connection, and the last HO type (CHO, DAPS (Dual Active Protocol Stack), etc.). Based on this information, the network can identify which scenario (including HO timing) the failed or suboptimal mobility occurred in, and which HO configuration / decision can be optimized.

[0031] Before delving into any enhancements to MRO for LTM, it is necessary to be familiar with how LTM works. An exemplary LTM procedure is provided below to help those skilled in the art understand potential issues that may arise during the LTM process: 1. The gNB can decide to configure LTM and initiate LTM preparation based on the MeasurementReport message sent by the UE to the gNB. However, LTM may not always be necessary. For example, in some cases, traditional L3 mobility, including CHO (conditional HO), may be triggered before LTM is executed.

[0032] 2. gNB initiates LTM by reconfiguring the UE (including LTM candidate configurations).

[0033] 3. The UE stores the LTM candidate configuration and waits for further network triggering (i.e., cell handover command).

[0034] 4. The UE can perform early DL / UL synchronization with the candidate cell before LTM is executed. Through UL synchronization, the UE can obtain TA (Timing Advance). UE synchronization can be configured as UE-based TA measurement or network-based TA measurement. In network-based TA measurement, the UE performs early TA acquisition with the candidate cell according to a network request before receiving the cell handover command. This is accomplished via CFRA triggered by a PDCCH command from the source cell, after which the UE sends a preamble to the indicated candidate cell. The TA value of the candidate cell is indicated in the cell handover command. This can also present problems, such as: early DL / UL synchronization may not always occur before LTM is triggered, leading to a longer LTM cell handover process and a potentially higher risk of failure; the TA value obtained by the UE at this stage may be inaccurate or not updated in a timely manner, also leading to failure.

[0035] 5. The UE performs L1 (layer 1) measurements and sends L1 measurement reports for the configured candidate cells to the gNB.

[0036] 6. The gNB decides to perform a cell handover to switch the UE to the target cell and triggers the handover by sending a MAC CE, which includes the candidate configuration index of the target cell and the beam information to which the UE will switch. The UE uses either RACH-based LTM (i.e., no random access procedure, the TA value is known in advance by the UE) or RACH-based LTM (i.e., the UE obtains the TA value only through the random access procedure) to switch to the target cell and apply the configuration indicated by the candidate configuration index. Possible problems include: incorrect LTM timing, such as triggering LTM too early / too late; problems in the RACH-based cell handover process (incorrect cell or beam information, inappropriate TA value); or problems in the random access process (e.g., a suboptimal CFRA configuration for RACH-based LTM), which can lead to LTM cell handover failure or RLF. LTM cell handover failure can also be classified as a handover failure.

[0037] 7. If the UE does not have a valid TA for the target cell, the UE performs a random access procedure for the target cell. Possible issues include: LTM cell handover failure due to inappropriate cell and / or beam information in the cell handover command, and RACH failure due to suboptimal RACH configuration.

[0038] 8. The UE completes the LTM cell handover process by sending an RRCReconfigurationComplete message to the target cell.

[0039] For subsequent LTMs, steps 4 through 8 can be executed multiple times using the LTM candidate configurations provided in step 2. For subsequent LTMs, the network may need to record the trajectory of those subsequent LTMs in order to provide optimized subsequent LTM configurations in the future.

[0040] The following will be organized based on possible LTM failure / suboptimal scenarios: failure scenarios, suboptimal LTM scenarios, LTM historical trajectory information, and network interfaces. In the following embodiments, the reported information may be a list, and the entries in the list include the information described in the following sections.

[0041] II. Example 1 Example 1 describes premature LTM cell handover.

[0042] In one example, the LTM cell handover decision might be made too early: the UE is in cell 1 / beam 1-1, and is being handed over to cell 2 / beam 2-1 by the LTM cell, and there might be issues such as... Figure 1 The following situations are shown.

[0043] Case 1-a: In Figure 1 If an LTM cell handover failure occurs in step 2, for example, in a no-RACH cell handover (no-RACH failure), the UE cannot receive any scheduling on the target cell / beam, or cannot determine whether the network has successfully received its first UL data (i.e., cell 2 / beam 2-1), or in a RACH-based LTM (RACH failure), the UE cannot complete the random access procedure, and the network-configured timer (e.g., T304) expires (this timer starts when the network triggers the LTM cell handover procedure). The UE performs a cell selection procedure and then re-establishes a connection at the source cell / beam (i.e., cell 1 / beam 1-1), as follows. Figure 1 As shown in step 3.

[0044] The following are some definitions that are frequently used in this patent document.

[0045] No RACH failure. The UE is unable to receive any scheduling on the target cell / beam, or cannot determine whether the network has successfully received its first UL data within a certain network configuration period (e.g., before T304 expires).

[0046] RACH failed. The UE was unable to complete the random access procedure based on the network configuration within a certain network configuration period (e.g., before T304 expires).

[0047] LTM cell handover failure. LTM cell handover failure may be due to RACH failure or no RACH failure.

[0048] Case 1-b: Even if LTM cell handover is successfully performed (whether based on RACH or without RACH), the connection between the UE and the target cell / beam is not stable, such as... Figure 1 As shown in step 2, the UE quickly experiences a radio link failure (RLF). The UE performs a cell selection procedure and then re-establishes a connection at the source cell / beam (i.e., cell 1 / beam 1-1), as follows. Figure 1 As shown in step 3.

[0049] When the above failures occur (LTM cell handover failure or RLF), the UE updates its failure report information to the network and transmits it to the network upon network request. LTM cell handover failure can be either a RACH-less LTM failure or a RACH-based LTM failure.

[0050] In the above scenario, the UE reports the following information to the network to indicate the failure information and associated details, thereby helping the network identify potential problems (e.g., this could be premature LTM cell handover, the channel conditions at the target location are actually worse than those at the source location; the UE reconnects to the network by applying the LTM recovery procedure instead of RRC reconstruction, i.e., cell 1): - The duration from the last LTM cell handover triggered to the occurrence of a failure, which can be an LTM cell handover failure (no RACH failure or RACH failure) or an RLF. The network can compare this duration with a local variable T1 that can be configured by OAM (Operations, Administration and Maintenance). If the duration is shorter than T1, and the UE subsequently selects the original cell and / or beam, the network can identify this as a premature LTM cell handover.

[0051] - L1 (Layer 1) measurement results. The UE can provide the network with the latest L1 measurements of LTM candidate cells to help the network assess the connectivity status when an LTM cell handover command is triggered.

[0052] - An indication of the situation that occurred, such as details or reasons for an LTM cell handover failure (no RACH failure or RACH failure) or an RLF failure. The UE can report whether a no RACH failure, RACH failure, or RLF occurred, along with information related to these failures (see a separate section for no RACH failures) to help the network identify the root cause of the problem. The above indications can also be identified as the reported cause value.

[0053] - RACH-related information for LTM cell handover, such as CFRA-related information and RACH resources.

[0054] - Source cell and beam information. This is used to help the network identify the source cell and beam information.

[0055] - Failed cell information and beam information, used to identify which cell / beam the RLF occurred in.

[0056] - Cell and beam information in the cell handover command. This helps the network identify the source of the cell and beam information indicated in the cell handover command.

[0057] - Cell and beam information indicating that the UE successfully re-established the RRC connection. Based on this information, the network can check whether the UE re-established the RRC connection at the original or source cell / beam.

[0058] - LTM cell recovery information. After the cell selection process, if the source cell (cell 1) is an LTM candidate cell, and if the network is configured for the UE to attempt LTM, the UE attempts to perform LTM once. In this case, LTM recovery can be performed.

[0059] - LTM recovery beam information. The UE may additionally provide LTM recovery beam information at the cell, such as cell 1 / beam 1-1.

[0060] - LTM candidate cell configuration. This indicates the list of candidate cells in the LTM candidate configuration, and may also include the complete configuration of each candidate configuration (including the TCI status list).

[0061] In another example, the LTM cell handover decision may have triggered the handover prematurely, resulting in an LTM cell handover within the same cell but with a different beam. The UE was previously in cell 1 / beam 1-1 and was handed over to cell 1 / beam 1-2 by the LTM cell. This could lead to the following sub-situations: Case 1-c: Even if the LTM cell handover is successfully performed, the connection between the UE and the target beam is unstable, and beam failure soon occurs for the UE. The UE performs beam failure recovery (BFR) and then successfully completes beam failure recovery for cell 1 at the original beam (i.e., beam 1-1).

[0062] Case 1-d: LTM cell handover fails. The UE then performs a cell selection procedure and subsequently re-establishes a connection at the source cell / beam (i.e., cell 1 / beam 1-1).

[0063] In case 1-c, no explicit failure occurs because BFR is successfully executed. However, to help the network detect problems (i.e., premature LTM handover to another beam within the same cell), the UE can report this event to the network under the following conditions: - LTM cell handover was successfully executed.

[0064] - A beam failure occurred after the LTM cell handover process, and the BFR was successfully executed.

[0065] - In addition, the UE will only report the above events if they occur shortly after the LTM cell handover is triggered (e.g., the time from the LTM cell handover being triggered to the occurrence of the first beam failure is less than the network-configured threshold T2).

[0066] In this situation, the UE can report the following information to the network in the report indicating a suboptimal successful LTM cell handover process: - The reason / trigger for this report.

[0067] - The duration from the last LTM cell handover triggered to the first beam failure occurring. The network can use this value to assess the target beam quality of the UE.

[0068] - Indications of what has happened, such as beam failure occurring shortly after an LTM cell handover process, to help the network identify the root cause of the problem.

[0069] - Source cell and beam information. This is used to help the network identify the source cell and beam information.

[0070] - Cell and beam information in the cell handover command. This helps the network identify the source of the cell and beam information indicated in the cell handover command.

[0071] - Successfully performed UE beam failure recovery cell and beam information.

[0072] - L1 measurement results. The UE can provide the network with the latest L1 measurements of the LTM candidate cell before the LTM cell handover is triggered, in order to help the network assess the connectivity status when the LTM cell handover command is triggered.

[0073] For case 1-d, the UE can report the same information in the failure report as for cases 1-a and 1-b.

[0074] III. Example 2 Example 2 describes an LTM cell handover where the cell is correct but the beam is incorrect (or suboptimal).

[0075] In one example, the LTM cell handover decision is triggered by the network, and the UE is handed over to the correct cell, but the beam is incorrect (or suboptimal, which may result in a successful LTM cell handover but an unstable connection with the target beam): The UE is in cell 1 / beam 1-1 and is ordered to hand over to cell 2 / beam 2-1 via LTM, and there are several sub-cases: Case 2-a: In Figure 2 In step 2, LTM cell handover failed. The UE performed a cell selection procedure, selected cell 2, and then re-established the connection at cell 2 / beam 2-2, as follows. Figure 2 As shown in step 3.

[0076] When the above failure occurs (LTM cell handover failure), the UE updates the failure report information and sends it to the network upon network request. LTM cell handover failure can be either a no-RACH LTM failure or a RACH-based LTM failure.

[0077] In the above scenario, the UE reports the following information to the network to indicate the failure information and its details, thereby helping the network identify potential problems (e.g., the target cell information in the LTM cell handover command is appropriate because the UE ultimately selected cell 2, but the beam information indicated in the LTM cell handover command is inappropriate because the UE failed to hand over the LTM cell to beam 2-1, but ultimately selected another beam in the same cell, namely beam 2-2; the UE can also reconnect to the network by applying the LTM recovery procedure instead of RRC reconstruction): - The duration from the last LTM cell handover triggered to the occurrence of a failure, which can be an LTM cell handover failure (no RACH failure or RACH failure). The network can compare this duration with a local variable T1 that can be configured by OAM (Operation, Administration and Maintenance). If this duration is too short and the UE ultimately connects to the network through the configured cell (i.e., cell 2) but with a different beam (i.e., beam 2-2 in the above case), the network can identify this as a case where the cell is correct but the beam is incorrect.

[0078] - L1 measurement results. The UE can provide the network with the latest L1 measurements of LTM candidate cells to help the network assess the connectivity status when an LTM cell handover command is triggered.

[0079] - An indication of the situation that occurred, such as details or reasons for an LTM cell handover failure (no RACH failure or RACH failure). The UE can report whether a no RACH failure or a RACH failure occurred, along with information related to the failure (see a separate section for no RACH failure) to help the network identify the root cause of the problem. The above indication can also be identified as the reported cause value.

[0080] - RACH-related information for LTM cell handover, such as CFRA-related information and RACH resources.

[0081] - Source cell and beam information. This is used to help the network identify the source cell and beam information.

[0082] - Cell and beam information in the cell handover command. This helps the network identify the source of the cell and beam information indicated in the cell handover command.

[0083] - UE successfully re-established RRC connection cell and beam information.

[0084] - LTM cell recovery information. After the cell selection process, if the source cell (cell 2) is an LTM candidate cell, and if the network is configured for the UE to attempt LTM, the UE attempts to perform LTM once. In this case, the LTM recovery cell is the source cell (cell 2).

[0085] - LTM recovery beam information. The UE may additionally provide LTM recovery beam information at the cell, such as cell 2 / beam 2-2.

[0086] - LTM candidate cell configuration. This indicates the list of candidate cells in the LTM candidate configuration, and may also include the complete configuration of each candidate configuration (including the TCI status list).

[0087] Case 2-b: Even if LTM cell handover is successfully performed, the connection between the UE and the target cell / target beam is not stable, such as... Figure 3 As shown in step 2, a beam failure quickly occurs for the UE. The UE performs a BFR procedure, and then the BFR succeeds at cell 2 / beam 2-2, as shown below. Figure 3 As shown in step 3.

[0088] In case 2-b, since the BFR is successfully executed, no explicit failure occurs. However, to help the network detect problems (i.e., the correct cell but suboptimal beam selection in the LTM cell handover command), the UE can report this event to the network either conditionally or unconditionally: - LTM cell handover was successfully executed.

[0089] - A beam failure occurred after the LTM cell handover process, and the BFR was successfully executed.

[0090] - In addition, the UE will only report the above events if they occur shortly after the LTM cell handover is triggered (e.g., the time from the LTM cell handover being triggered to the occurrence of the first beam failure is less than the network-configured threshold T2).

[0091] In this situation, the UE can report the following information to the network in the report indicating a suboptimal successful LTM cell handover process: - The triggering conditions (reasons) for this report.

[0092] - The duration from the last LTM cell handover triggered to the occurrence of the first beam failure. The network can use this value to evaluate the UE's target beam quality. The network can compare this duration with the local variable T3, which can be configured by OAM (Operation, Administration and Maintenance). If this duration is too short and after a successful BFR, the UE connects to the network through the configured cell (i.e., cell 2) but with a different beam (i.e., beam 2-2 in the above case), the network can identify this as a case where the cell is correct but the beam is incorrect.

[0093] - Indications of what has happened, such as beam failure occurring shortly after an LTM cell handover process, to help the network identify the root cause of the problem.

[0094] - Source cell and beam information. This is used to help the network identify the source cell and beam information.

[0095] - Cell and beam information in the cell handover command. This helps the network identify the source of the cell and beam information indicated in the cell handover command.

[0096] - Successfully performed UE beam failure recovery cell and beam information.

[0097] - L1 measurement results. The UE can provide the network with the latest L1 measurements of the LTM candidate cell before the LTM cell handover is triggered, in order to help the network assess the connectivity status when the LTM cell handover command is triggered.

[0098] IV. Example 3 Example 3 describes an LTM cell handover with a cell error.

[0099] In one example, the LTM cell handover decision may fail to hand the UE to the correct cell: the UE is in cell 1 / beam 1-1, and is being handed over by the LTM cell to cell 2 / beam 2-1, with the following sub-cases: Case 3-a: In Figure 4 In step 2, LTM cell handover failed. The UE performed a cell selection procedure and then re-established a connection in another cell that is neither cell 1 nor cell 2 (e.g., cell 3 / beam 3-2), as shown below. Figure 4 As shown in step 3.

[0100] Case 3-b: Even if LTM is successfully executed, the connection between the UE and the target cell is unstable, and a radio link failure soon occurs for the UE in cell 2. The UE performs a cell selection procedure and then re-establishes the connection in another cell that is neither cell 1 nor cell 2 (e.g., cell 3 / beam 3-2). Case 3-b is shown in... Figure 5 middle.

[0101] When the above failures (LTM cell handover failure or RLF) occur, the UE updates the failure report information and sends it to the network when requested by the network.

[0102] In the above scenario, the UE reports the following information to the network to help the network identify potential problems (e.g., this may be an incorrect LTM cell handover, where there is actually a better cell, cell 3, as the target cell for the LTM cell handover instead of cell 2): - The duration from the last LTM cell handover triggered to the occurrence of a failure, which can be an LTM cell handover failure (no RACH failure or RACH failure) or an RLF. The network can compare this duration with a local variable T1 that can be configured by OAM (Operation, Administration and Maintenance). If the duration is shorter than T1 and the UE establishes a connection in another cell (i.e., cell 3) that is neither cell 2 nor cell 1, the network can identify this as an LTM cell handover with a cell error.

[0103] - L1 measurement results. The UE can provide the network with the latest L1 measurements of the LTM candidate cell before the LTM cell handover is triggered, in order to help the network assess the connectivity status when the LTM cell handover command is triggered.

[0104] - An indication of the situation that occurred, such as details or reasons for an LTM cell handover failure (no RACH failure or RACH failure) or an RLF failure. The UE can report whether a no RACH failure, RACH failure, or RLF occurred, along with information related to these failures (see a separate section for no RACH failures) to help the network identify the root cause of the problem. The above indications can also be identified as the reported cause value.

[0105] - RACH-related information for LTM cell handover, such as CFRA-related information and RACH resources.

[0106] - Source cell and beam information. This is used to help the network identify the source cell and beam information.

[0107] - Failed cell information and beam information, used to identify which cell / beam the RLF occurred in.

[0108] - Cell and beam information in the cell handover command. This helps the network identify the source of the cell and beam information indicated in the cell handover command.

[0109] - UE successfully re-established RRC connection cell and beam information.

[0110] - LTM cell recovery information. After the cell selection process, if cell 3 is an LTM candidate cell, and if the network is configured for the UE to attempt LTM after RLF, the UE attempts to perform LTM once. In this case, LTM cell recovery can be performed.

[0111] - LTM recovery beam information. The UE may additionally provide LTM recovery beam information at the cell, such as cell 3 / beam 3-2.

[0112] - LTM candidate cell configuration. This indicates the list of candidate cells in the LTM candidate configuration, and may also include the complete configuration of each candidate configuration (including the TCI status list).

[0113] V. Example 4 Example 4 describes a late LTM cell handover.

[0114] In one example, the network configured LTM-related settings for the UE, such as a candidate LTM configuration. The network did not trigger LTM, and beam failure occurred. The following sub-cases may exist.

[0115] Scenario 4-a: The UE connects to the network via cell 1, beam 1-1. The UE is configured with an LTM configuration for potential LTM mobility. However, a beam failure occurs before the network triggers any LTM mobility. The UE successfully performs beam failure recovery and reconnects to the network via another beam from the source cell (e.g., cell 1 / beam 1-3). In this case, there is no explicit failure (e.g., no HO failure, no LTM failure, no RLF). However, the fact that a beam failure occurs and the UE eventually recovers its beam in another beam (i.e., cell 1 / beam 1-3) suggests that if the network had already configured LTM (and if beam 1-3 was already in an LTM candidate configuration), the UE would have required the network to trigger LTM earlier or perform a beam handover earlier. Scenario 4-1 is shown in... Figure 6 middle.

[0116] In case 4-a, no explicit failure occurs because BFR is successfully executed. However, to help the network detect problems (i.e., late LTM handover to another beam within the same cell), the UE can report such an event to the network under the following conditions: - LTM is configured but not triggered.

[0117] - Beam failure occurred before LTM cell handover was triggered, but BFR was executed successfully.

[0118] In this situation, the UE can report the following information to the network in the report indicating the suboptimal LTM procedure: - The triggering conditions (reasons) for this report.

[0119] - Indications of what has happened, such as BFR succeeding after beam failure and LTM being configured but not triggered, to help the network identify the root cause of the problem.

[0120] - Successfully performed UE beam failure recovery cell and beam information.

[0121] - L1 measurement results. The UE can provide the network with the latest L1 measurements of the LTM candidate cell before the LTM cell handover is triggered, in order to help the network assess the connectivity status when the LTM cell handover command is triggered.

[0122] - LTM candidate cell configuration. This indicates the list of candidate cells in the LTM candidate configuration, and may also include the complete configuration of each candidate configuration (including the TCI status list).

[0123] Case 4-b: In another example, the UE connects to the network via cell 1 / beam 1-1. Although LTM is configured as in step 1, LTM is never triggered. An RLF then occurs (as in step 2), and the UE reselects another cell, cell 2 / beam 2-2 (as in step 3). Case 4-b is shown in... Figure 7 middle.

[0124] When the aforementioned failure occurs (i.e., RLF), the UE updates the failure report information and sends it to the network upon network request.

[0125] In the above scenario, the UE reports the following information to the network to indicate the failure information and its details, thereby helping the network identify potential problems (e.g., this could be a late LTM cell handover, where the channel conditions at the source are actually worse than one of the candidate cells; if the network is enabled, the UE can also reconnect to the network by applying the LTM recovery procedure instead of RRC reconstruction, i.e., cell 2): - The duration from when the last LTM cell handover is triggered to when a failure occurs, which can be an RLF. The network can compare this duration with a local variable T1 that can be configured by OAM (Operation, Administration and Maintenance). If the duration is longer than T1, the network can identify that this is an overdue LTM cell handover.

[0126] - L1 measurement results. The UE can provide the network with the latest L1 measurements of LTM candidate cells to help the network assess the connectivity status when an LTM cell handover command is triggered.

[0127] - Failed cell information and beam information, used to identify which cell / beam the RLF occurred in.

[0128] - UE successfully re-established RRC connection cell and beam information.

[0129] - LTM cell recovery information. After the cell selection process, if the source cell (cell 1) is an LTM candidate cell, and if the network is configured for the UE to attempt LTM, the UE attempts to perform LTM once. In this case, LTM recovery can be performed.

[0130] - LTM recovery beam information. The UE may additionally provide LTM recovery beam information at the cell, such as cell 1 / beam 1-1.

[0131] - LTM candidate cell configuration. This indicates the list of candidate cells in the LTM candidate configuration, and may also include the complete configuration of each candidate configuration (including the TCI status list).

[0132] Case 4-c: In another example, LTM has been configured for the UE but has never been triggered. Normal Layer 3 mobility is triggered by the network (via a handover command in an RRC message) or by a condition configured for the UE (i.e., a Conditional HO, Conditional HO). A normal HO or Conditional HO can be executed successfully or fail. A normal HO is a HO triggered by a handover command in an RRC reconfiguration message. Case 4-c is shown in... Figure 8 middle.

[0133] If successful, no explicit failure occurs. To help the network detect problems (i.e., premature LTM handover to another beam within the same cell), the UE can report such events to the network under the following conditions: - LTM has been configured, but another type of switch (normal HO or CHO) has been performed; or CHO has been configured, but another type of switch (LTM or normal HO) has been performed.

[0134] In this situation, the UE can report the following information to the network in the report instructing the suboptimal HO procedure: - The triggering conditions (reasons) for this report.

[0135] - The type of switch actually performed. In the above case, this type is normal HO, CHO, or LTM.

[0136] - The configured switching type. In the above case, the type is LTM or CHO (to cover cases where both are configured but normal mobility or LTM is triggered).

[0137] - L1 measurement results of LTM candidate cells. The UE can provide the network with the latest L1 measurements of LTM candidate cells before LTM cell handover is triggered, to help the network assess the connectivity status when the LTM cell handover command is triggered.

[0138] If failure occurs, when the above failures (handover failure or RLF) occur, the UE updates the failure report information and sends it to the network when requested by the network.

[0139] In the above scenario, the UE reports the following information to the network to indicate the failure information and its details, thereby helping the network identify potential problems (e.g., resource inefficiency in the case of triggering a normal HO even though LTM is configured): - The type of switch actually performed. In the above case, this type is normal HO, CHO, or LTM.

[0140] - The configured switching type. In the above case, the type is LTM or CHO (to cover cases where both are configured but normal mobility or LTM is triggered).

[0141] VI. Example 5 Example 5 describes other items in the UE report.

[0142] 5.1 Duration between the latest LTM configuration and LTM trigger The network may want to understand the efficiency of the LTM configuration. One aspect is the duration between the latest LTM configuration and LTM triggering. A longer duration means that resources will be pre-allocated to the UE for a longer period, thus consuming more resources in the candidate cell.

[0143] This duration can be indicated to the network in a report indicating a suboptimal successful LTM cell handover process or a failure report.

[0144] 5.2 Successful beam does not match pre-configuration There are cases where candidate configurations from the network are suboptimal, for example, the optimal cell / beam is not part of the LTM candidate configuration, which causes candidate configurations from the network to fail or become suboptimal.

[0145] Case 5.2.a: In one example, the UE undergoes RACH-based LTM. In RACH-based LTM, the UE selects an appropriate beam to randomly access a target cell. RACH-based LTM is successfully executed. However, the UE discovers that the selected beam is not included in the candidate configurations for that cell.

[0146] Case 5.2.b: In another example, the UE experiences LTM without RACH and fails. The UE eventually performs LTM recovery or RRC reconstruction in the selected cell with the selected beam, chosen by the UE. However, the UE discovers that the selected cell / beam is not included in the candidate configurations for that cell.

[0147] Case 5.2.c: In another example, the UE undergoes an LTM cell handover, which is successful. Beam failure soon occurs, but BFR is successfully executed. However, the UE discovers that the selected beam is not included in the candidate configurations for that cell.

[0148] Case 5.2.d: In another example, the UE experiences LTM without RACH and succeeds. An RLF occurs shortly afterward. The UE eventually performs LTM recovery or RRC reconstruction in the selected cell by the selected beam (selected by the UE). However, the UE discovers that the selected beam is not included in the candidate configuration for that cell (which is one of the candidate cells).

[0149] For the suboptimal successful LTM in cases 5.2.a and 5.2.c, it is under the following conditions: - In RACH-based LTM, the selected beam of the cell is not included in the candidate configurations for that cell, or - After a successful LTM cell handover, the selected beam of the cell in the BFR is not part of the candidate configuration for that cell.

[0150] The UE is triggered to report a suboptimal successful LTM cell handover. The report should include at least the LTM candidate configuration, the cell and beam information of the successfully performed LTM, or the inconsistency directly indicated by the UE.

[0151] For cases 5.2.b and 5.2.d, the UE reports the cell / beam selected after an LTM cell handover failure or RLF, as well as the LTM candidate configuration.

[0152] 5.3 Suboptimal LTM Reporting Triggered by T304 Threshold LTM cell handover processes can take too long and result in suboptimal LTM. The longer the completion time, the greater the risk of LTM failure. Meanwhile, LTM should be faster than traditional Layer 3 mobility; for example, LTM should provide lower latency / disruption and a seamless experience. The network may want to collect information about such suboptimal LTM processes, such as the RACH type of LTM (no RACH or RACH-based), how the UE obtains TA information from the network, and whether early DL / UL synchronization is completed during LTM cell handover when the process takes too long.

[0153] In one example, the UE is configured with a threshold R1. If the ratio between the elapsed time value of timer T304 during the LTM procedure and the configured value of timer T304 configured by the network is greater than the configured threshold R1, the UE updates the report of information associated with the LTM procedure and reports it to the network upon network request. This report includes at least one of the following: - The trigger condition (reason) for this report is that the ratio between the elapsed time value of the LTM process's timer T304 and the configured value of the network-configured timer T304 is greater than the configured threshold R1.

[0154] - RACH type of LTM (no RACH or RACH-based).

[0155] - RACH configuration, such as CFRA configuration and RACH resources.

[0156] - The method by which the UE obtains the TA value of its target, such as UE-based or network-based.

[0157] - Was early DL synchronization completed during LTM cell handover?

[0158] - Whether early UL synchronization was completed during LTM cell handover (i.e., whether the TA value is available for the target cell).

[0159] 5.4 Cell handover command does not match candidate configuration In one example, the UE might receive a cell handover command that includes target cell and beam information; however, the information in this cell handover command does not match any candidate configuration. For instance, the cell handover command might indicate cell 2 / beam 2-1, but cell 2 is not part of a candidate configuration. Or, in another case, beam 2-1 is not part of a candidate configuration.

[0160] The UE can report this situation to the network in the failure report information, that is, indicate that the UE received a cell handover command that includes target cell and beam information that does not match any candidate configuration, so that the network can be aware of this abnormal LTM configuration and trigger it.

[0161] 5.5 The UE reports RACH information to the network. In one example, the UE reports RACH-related information to the network during RACH-based LTM to indicate to the network that there may be RACH-related issues that could lead to LTM cell handover failure.

[0162] - RACH type, CFRA or CBRA.

[0163] - Random access preamble used for CFRA.

[0164] - SS / PBCH index, used to determine the RACH timing for PRACH transmissions for CFRA resources.

[0165] - PRACH mask index, which indicates the RACH timing associated with the SS / PBCH indicated by the "SS / PBCH index", the RACH timing being used for PRACH transmission of CFRA resources.

[0166] - Indicator: Whether to use SUL (Supplementary Uplink) or NUL (Normal Uplink) as the UL carrier to transmit PRACH that competes for free random access resources.

[0167] 5.6 TA-related information For failed LTM cell handovers, the failure may be due to a problem occurring during RACH-less LTM. The detailed cause of the failure may be related to the UL synchronization process. To help the network identify the problem, the UE can report early UL synchronization-related information to the network, including at least one of the following: - How the UE obtains the TA value, i.e., the method by which the UE obtains the TA value of its target, such as based on the UE or based on the network.

[0168] - The exact TA value of the target cell, which is encoded in an index to be reported to the network.

[0169] - Early UL synchronization configuration, which includes frequency information, parameter set, and BWP information of the measured candidate cells.

[0170] For the LTM process and for the TA value acquired by the UE itself (i.e., based on the UE's early UL synchronization), the UE maintains this TA without keeping a validity timer for checking the validity of the TA value. Therefore, the TA value maintained by the UE may become outdated and inapplicable to subsequent LTM cell handovers. However, the network may not be aware of this situation and may still trigger an LTM cell handover before the UE is able to update the TA value. Therefore, it is advantageous for the UE to report the duration for which it has maintained the TA (from the time the UE acquires the TA value in the latest early UL synchronization to the time the UE receives the cell handover command from the network).

[0171] In one example, the duration from when the UE obtains the TA value in the latest early UL synchronization to when the UE receives the cell handover command from the network is indicated to the network in the corresponding failure report information.

[0172] 5.7 Subsequent LTM Recordings The network may need to record an LTM trajectory for a subsequent LTM process to better understand UE mobility and subsequent LTM configuration, such as making better subsequent LTM configuration decisions in the future to minimize user plane outages or to strike a balance between overhead and user plane outages.

[0173] In one example, by enabling the network configuration that allows the UE to record its subsequent LTM trajectories, the UE updates its subsequent LTM trajectories and reports them to the network upon network request. The trajectory is a list of the following: - Cell x, beam xi, time spent in the combination of cell and beam, UE location, and L1 measurement during LTM cell handover.

[0174] - Cell y, beam yj, time spent in the combination of cell and beam, UE location, and L1 measurement during LTM cell handover.

[0175] - … - Cell z, beam zk, time spent in the combination of cell and beam, UE location, and L1 measurement during LTM cell handover.

[0176] This list has a maximum length and maintains a trajectory of UE mobility history for subsequent LTM processes.

[0177] In some embodiments, the trajectory includes an indication that the record comes from a subsequent LTM process.

[0178] In another example, the UE may additionally include an indication in the list above: whether the LTM is a successful LTM based on a cell handover command from the network or the result of an LTM recovery.

[0179] If it is the result of LTM recovery, the UE also records the cell / beam information from the cell handover command from the network.

[0180] VII. Example 6 Example 6 describes a subsequent LTM. In one example, the UE indicates to the network that the failure report or suboptimal success report is related to a subsequent LTM. Based on this indication, the network can request a report from the UE in case the report might be overwritten on the UE side due to frequent updates of subsequent LTM reports.

[0181] VIII. Example 7 Example 7 describes the network interface.

[0182] Figure 9 The example network interface is shown. SON-related information reported by the UE to the network for the LTM procedure should be transmitted between the gNB-CU and gNB-DU so that the gNB-DU can understand LTM mobility-related optimizations. For example, the lower-layer configuration of the candidate configuration is determined by gNB-DU2, to which the target cell belongs. Meanwhile, cell handover decisions and commands originate from the source gNB-DU1.

[0183] In the case of inter-gNB LTM procedures (i.e., the target cell in the candidate cells during the LTM procedure may belong to another gNB), the information reported by the UE should be transmitted from gNB-CU2 (controlling other cells) to gNB-CU1 (controlling the source cell) so that the source cell can optimize the LTM procedure.

[0184] Information regarding the UE report for LTM's SON is transmitted between the two gNBs.

[0185] Information regarding the SON of LTM is transmitted from gNB-CU to gNB-DU in the UE report.

[0186] Figure 10 This is an example flowchart for sending failure report information. Operation 1002 includes: sending failure report information by a wireless device regarding mobility robustness optimization for Layer 1 or Layer 2 triggered mobility (LTM). In some embodiments, the method may be implemented according to Embodiments 1 to 7. In some embodiments, further steps of performing the method may be based on better system performance than conventional protocols.

[0187] In some embodiments, the failure reporting information includes at least one of the following: an indication of subsequent LTM; a first duration from when the last LTM cell handover was triggered to when the LTM cell handover failed or a radio link failure (RLF) occurred; a second duration between the latest LTM configuration and the LTM trigger; a third duration from when the LTM cell handover was triggered to when the first beam failure occurred; source cell or beam information; failed cell or beam information identifying the cell or beam where the radio link failure (RLF) occurred or ended; cell or beam information in the cell handover command; cell or beam information where the radio device successfully re-established the radio resource control (RRC) connection; LTM recovery cell or beam information if LTM recovery was performed after the cell selection process; LTM candidate cell or beam configurations, which include a transmission configuration indication for each candidate configuration. The following are listed as indicators (TCI): Status list; Handover (HO) type performed by the radio device, including at least one of Normal HO, Conditional HO (CHO), or LTM; Configured HO type, including at least one of LTM or COH configured by the network device; Indication regarding a cell handover command received by the radio device, including target cell or beam information that does not match any candidate configuration; Layer 1 measurement results; Indication of the reason for LTM cell handover failure; Random Access Channel (RACH) related information for LTM cell handover; or LTM related information without RACH.

[0188] In some embodiments, the LTM cell handover failure includes at least one of RACH failure or no RACH failure.

[0189] In some embodiments, the RACH-related information for the LTM cell handover includes at least one of the following: RACH type, which includes at least one of contention-free random access (CFRA) or contention-based random access (CBRA); random access preamble for CFRA; synchronization signal / physical broadcast channel (SS / PBCH) index for determining the RACH occasion (RO) for physical random access channel (PRACH) transmission for CFRA resources; PRACH mask index, which indicates the RO associated with the SS / PBCH indicated by the SS / PBCH index for PRACH transmission for CFRA resources; or an indication of whether supplementary uplink (SUL) or normal uplink (NUL) is used as the uplink (UL) carrier to transmit the PRACH for CFRA resources.

[0190] In some embodiments, the RACH-free LTM-related information includes at least one of the following: how the radio device obtains the timing advance (TA) value of the target; the TA value of the target cell; the early uplink (UL) synchronization configuration, which includes at least one of the frequency information, parameter set, or bandwidth part (BWP) information of the measured candidate cell; or, if the TA value is measured by a radio device-based method, the duration for which the radio device has maintained the TA value.

[0191] In some embodiments, the network device compares the first duration with a local variable T1 configured by Operation, Administration and Maintenance (OAM) and determines that the LTM cell handover is premature based on the following: the first duration is less than T1; and after the first duration, the radio device selects the original cell or beam.

[0192] In some embodiments, the network device compares the first duration with a local variable T1 configured by Operation, Administration and Maintenance (OAM) and determines that the LTM cell handover is a case of a cell correct beam error based on the following: the first duration is less than T1; an LTM cell handover failure occurs; after the LTM cell handover failure, the radio device selects a cell from the cell handover command of the network device; and the beam selected by the radio device does not match the beam indicated in the cell handover command.

[0193] In some embodiments, the network device compares the first duration with a local variable T1 configured by Operation, Administration and Maintenance (OAM) and determines that the LTM cell handover is a cell error based on the following: the first duration is less than T1; and after the LTM cell handover fails, the radio device selects a cell that is neither the cell in the cell handover command from the network device nor the source cell.

[0194] In some embodiments, the network device compares the first duration with a local variable T1 configured by Operation, Administration and Maintenance (OAM) and determines that the LTM cell handover is too late based on the following: the first duration is greater than T1; and after the LTM cell handover fails, the radio device selects a cell that is not the source cell.

[0195] In some embodiments, the local variable T1 is a threshold specifically configured for LTM.

[0196] Figure 11 This is an example flowchart for sending suboptimal successful mobility report information. Operation 1102 includes: the wireless device updating the suboptimal successful mobility report information regarding mobility robustness optimization for Layer 1 or Layer 2 triggered mobility (LTM) based on the condition being met. Operation 1104 includes: the wireless device sending the suboptimal successful mobility report information. In some embodiments, this method can be implemented according to embodiments 1 to 7. In some embodiments, further steps of performing this method can be based on better system performance than conventional protocols.

[0197] In some embodiments, the condition includes at least one of the following: LTM cell handover is successfully performed; a beam failure occurs after the LTM cell handover process and beam failure recovery (BFR) is successfully performed; the duration from when the last LTM cell handover is triggered to when the first beam failure occurs is less than a threshold T2 configured by the network device; LTM is configured but not triggered; a beam failure occurs before the LTM cell handover is triggered and BFR is successfully performed; LTM is configured but another handover (HO) type is performed, which includes a normal HO or a conditional HO. At least one of HO (CHO); CHO is configured but another HO type is executed, which includes LTM or normal HO; in LTM based on random access channel (RACH), the selected beam of the cell is not included in the candidate configuration of the cell; in BFR after a successful LTM cell handover, the selected beam of the cell is not included in the candidate configuration of the cell; or if the ratio between the elapsed time value of timer T304 of the LTM procedure and the value of timer T304 configured by the network device for the radio device is greater than the configured threshold R1.

[0198] In some embodiments, the suboptimal successful mobility report information includes at least one of the following: the duration from when the LTM cell handover is triggered to when the first beam failure occurs; an indication that a beam failure occurred shortly after the LTM cell handover process and beam failure recovery (BFR) was successful; an indication that a BFR was successful after a beam failure, wherein LTM is configured and not triggered; the conditions for triggering the report; source cell or beam information; cell or beam information in the cell handover command; cell or beam information of the radio device where the BFR was successfully executed; layer 1 measurement results; LTM candidate cell or beam configuration, which includes a Transmission Configuration Indicator (TCI) status list for each candidate configuration; the handover (HO) type performed by the radio device, wherein the HO type includes at least one of normal HO, conditional HO (CHO), or LTM; the configured HO type, which includes at least one of LTM or COH; and the LTM random access channel (RACH) type, which includes no RACH. LTM or RACH-based LTM; RACH configuration, including at least one of Contention-Free Random Access (CFRA) or Contention-Based Random Access (CBRA); RACH resources; how the radio device obtains the timing advance (TA) value of the target, wherein the acquisition is based on the radio device or the network; whether the LTM cell handover process for the target cell has completed early downlink (DL) synchronization; whether the LTM cell handover process for the target cell has completed early uplink (UL) synchronization; or whether the TA value is available for the target cell.

[0199] In some embodiments, the network device compares the duration with a local variable T3 configured by Operation, Administration and Maintenance (OAM) and determines that the LTM cell handover is a case of correct cell beam error based on the following: the duration is less than T3; and after a successful BFR, the radio device connects to the network device via the cell configured in the cell handover command but with a beam different from that cell handover command.

[0200] In some embodiments, the suboptimal successful mobility report information is sent upon receiving a request from a network device.

[0201] Figure 12 This is an example flowchart for sending LTM trajectory information. Operation 1202 includes: sending a list of subsequent Layer 1 or Layer 2 triggered mobility (LTM) trajectory information by a wireless device, wherein the subsequent LTM trajectory information is used to update LTM mobility history information. In some embodiments, the method can be implemented according to embodiments 1 to 7. In some embodiments, further steps of performing the method can be based on better system performance than conventional protocols.

[0202] In some embodiments, the wireless device is configured with subsequent LTM by a network device.

[0203] In some embodiments, the list of subsequent LTM trajectory information is sent upon receiving a request from a network device.

[0204] In some embodiments, the subsequent LTM trajectory information includes at least one of the following: an indication that the subsequent LTM trajectory information is for subsequent LTM; cell or beam information; time spent in the combination of cell and beam; location information of the wireless device; an indication of whether a successful LTM is based on LTM recovery or on a cell handover command from the network device, wherein if a successful LTM is based on LTM recovery, the wireless device records the cell or beam information in the cell handover command from the network device; or a Layer 1 measurement during LTM cell handover.

[0205] Figure 13 This is an example flowchart for receiving LTM information by a distributed unit (DU) of a network device. Operation 1302 includes: the distributed unit (DU) of the network device receiving at least one of the following information regarding a Layer 1 or Layer 2 triggered mobility (LTM) ad hoc network: failure report information; suboptimal successful mobility report information; or subsequent LTM trajectory information. In some embodiments, the method may be implemented according to embodiments 1 to 7. In some embodiments, further steps of performing the method may be based on better system performance than conventional protocols.

[0206] In some embodiments, at least one of the information is received from the centralized unit (CU) of the network device.

[0207] Figure 14 This is an example flowchart for receiving LTM information by a network device. Operation 1402 includes: the network device receiving at least one of the following information regarding a Layer 1 or Layer 2 triggered mobility (LTM) ad hoc network: failure report information; suboptimal successful mobility report information; or subsequent LTM trajectory information. In some embodiments, the method may be implemented according to embodiments 1 to 7. In some embodiments, further steps of performing the method may be based on better system performance than conventional protocols.

[0208] In some embodiments, at least one of the information is received from another network device.

[0209] In some embodiments, the received failure report information includes at least one of the following: an indication of subsequent LTM; a first duration from when the last LTM cell handover was triggered to when the LTM cell handover failed or a radio link failure (RLF) occurred; a second duration between the latest LTM configuration and the LTM trigger; source cell or beam information; a third duration from when the LTM cell handover was triggered to when the first beam failure occurred; failed cell or beam information, used to identify the cell or beam where the radio link failure (RLF) occurred or ended; cell or beam information in the cell handover command; cell or beam information where the radio device successfully re-established the radio resource control (RRC) connection; and if LTM recovery was performed after the cell selection process, LTM recovery... Cell or beam information; LTM candidate cell or beam configuration, which includes a Transmission Configuration Indicator (TCI) status list for each candidate configuration; handover (HO) type performed by the radio device, wherein the handover type includes at least one of normal HO, conditional HO (CHO), or LTM; configured HO type, which includes at least one of LTM or COH configured by the network device; indication of the radio device receiving a cell handover command, which includes target cell or beam information that does not match any candidate configuration; Layer 1 measurement results; indication of the reason for LTM cell handover failure; random access channel (RACH) related information for LTM cell handover; or LTM related information without RACH.

[0210] In some embodiments, the received suboptimal successful mobility report information includes at least one of the following: the duration from when the LTM cell handover is triggered to when the first beam failure occurs; an indication that a beam failure occurred shortly after the LTM cell handover process and beam failure recovery (BFR) was successful; an indication that a BFR was successful after a beam failure, wherein LTM is configured and not triggered; the conditions for triggering the report; source cell or beam information; cell or beam information in the cell handover command; cell or beam information of the radio device that successfully performed the BFR; layer 1 measurement results; LTM candidate cell or beam configuration, which includes a Transmission Configuration Indicator (TCI) status list for each candidate configuration; the handover (HO) type performed by the radio device, wherein the HO type includes at least one of normal HO, conditional HO (CHO), or LTM; the configured HO type, which includes at least one of LTM or COH; and the LTM random access channel (RACH) type, which includes no RACH. LTM or RACH-based LTM; RACH configuration, including at least one of Contention-Free Random Access (CFRA) configuration or Contention-Based Random Access (CBRA) configuration; RACH resources; how the radio device obtains the timing advance (TA) value of the target, wherein the acquisition is based on the radio device or the network; whether the LTM cell handover process for the target cell has completed early downlink (DL) synchronization; whether the LTM cell handover process for the target cell has completed early uplink (UL) synchronization; or whether the TA value is available for the target cell.

[0211] In some embodiments, the received subsequent LTM trajectory information includes at least one of the following: an indication that the subsequent LTM trajectory information is for subsequent LTM; cell or beam information; time spent in the combination of cell and beam; location information of the wireless device; an indication of whether a successful LTM is based on LTM recovery or on a cell handover command from the network device, wherein if a successful LTM is based on LTM recovery, the wireless device records the cell or beam information in the cell handover command from the network device; or a Layer 1 measurement during LTM cell handover.

[0212] Figure 15An example block diagram of a hardware platform 1500 is shown. This hardware platform may be part of a network device (e.g., a base station (BS), transmission and reception point (TRP), or radio access network (RAN)) or a wireless device (e.g., a user equipment (UE)). The hardware platform 1500 includes at least one processor 1510 and a memory 1505 thereon storing instructions. When the instructions are executed by the processor 1510, the hardware platform 1500 is configured to perform... Figures 1 to 14 The operations described in the various embodiments described in this patent document are as follows: Transmitter 1515 sends information or data to another device. For example, a network device transmitter may send a message to a user equipment. Receiver 1520 receives information or data sent by another device. For example, a user equipment may receive a message from a network device. For example, the UE, wireless device, or network device described in this document may be implemented using hardware platform 1500.

[0213] The implementation described above will be applied to wireless communication. Figure 16 An example of a wireless communication system (e.g., a 5G or NR (new radio, new NR) cellular network) including a base station 1620 and one or more user equipments (UEs) 1611, 1612, and 1613 is shown. In some embodiments, the UE accesses the BS (e.g., the network) using a communication link to the network (sometimes referred to as the uplink direction, as shown by dashed arrows 1631, 1632, and 1633), which then enables subsequent communication from the BS to the UE (e.g., shown in the direction from the network to the UE, sometimes referred to as the downlink direction, as shown by arrows 1641, 1642, and 1643). In some embodiments, the BS sends information to the UE (sometimes referred to as the downlink direction, as shown by arrows 1641, 1642, and 1643), which then enables subsequent communication from the UE to the BS (e.g., shown in the direction from the UE to the BS, sometimes referred to as the uplink direction, as shown by dashed arrows 1631, 1632, and 1633). The UE can be, for example, a smartphone, tablet, mobile computer, machine-to-machine (M2M) device, Internet of Things (IoT) device, etc. The UE described in this document can communicatively couple to... Figure 16 The base station 1620 is depicted in the image.

[0214] Those skilled in the art will understand that the method disclosed in this patent document, among other advantages, improves the quality of LTM cell handover and handover. The disclosed method includes reporting suboptimal low-layer triggered mobility (LTM) cell handover processes and / or failure reporting information to the network.

[0215] Some embodiments described herein are described in the general context of methods or processes that may be implemented in one embodiment by a computer program product embodied in a computer-readable medium, including computer-executable instructions, such as program code, that are executed by a computer in a networked environment. The computer-readable medium may include removable and non-removable storage devices, including but not limited to read-only memory (ROM), random access memory (RAM), compact disc (CD), digital versatile disc (DVD), etc. Therefore, the computer-readable medium may include non-transitory storage media. Typically, program modules may include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. Computer- or processor-executable instructions, associated data structures, and program modules represent examples of program code for performing the method steps disclosed herein. Specific sequences of these executable instructions or associated data structures represent examples of corresponding actions for implementing the functionality described in these steps or processes.

[0216] Some of the disclosed embodiments can be implemented as devices or modules using hardware circuitry, software, or a combination thereof. For example, a hardware circuitry implementation may include discrete analog and / or digital components integrated, for example, as part of a printed circuit board. Alternatively or additionally, the disclosed components or modules may be implemented as application-specific integrated circuits (ASICs) and / or field-programmable gate arrays (FPGAs). Some implementations may additionally or alternatively include a digital signal processor (DSP), a special-purpose microprocessor whose architecture is optimized for the operational requirements of digital signal processing associated with the functions disclosed herein. Similarly, individual components or sub-components within each module may be implemented in software, hardware, or firmware. Any connectivity methods and media known in the art can be used to provide connectivity between modules and / or components within modules, including but not limited to communication via the Internet, wired or wireless networks using suitable protocols.

[0217] Although this document contains numerous details, these should not be construed as limiting the scope of the claimed or potentially claimed invention, but rather as descriptions of features specific to particular embodiments. Certain features described in this document within the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as functioning in a certain combination, and even initially claimed to be so, one or more features from a claimed combination may be removed from that combination in certain circumstances, and the claimed combination may involve sub-combinations or variations thereof. Similarly, although operations are depicted in a specific order in the drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or to perform all shown operations to achieve the desired result.

[0218] Only some implementations and examples are described, and other implementations, enhancements and variations may be made based on what is described and shown in this patent document.

Claims

1. A wireless communication method, comprising: The wireless device sends a failure report message regarding mobility robustness optimization for Layer 1 or Layer 2 triggered mobility (LTM).

2. The method according to claim 1, wherein, The failure report information includes at least one of the following: Subsequent LTM instructions; The first duration from when the last LTM cell handover is triggered until when an LTM cell handover failure or radio link failure (RLF) occurs; The second duration between the latest LTM configuration and LTM trigger; The third duration from when LTM cell handover is triggered to when the first beam failure occurs; Source cell or beam information; Failed cell or beam information is used to identify the cell or beam in which a radio link failure (RLF) occurs or ends; Cell or beam information in the cell handover command; The wireless device successfully re-established the cell or beam information of the Radio Resource Control (RRC) connection; If LTM recovery is performed after the cell selection process, LTM recovery cell or beam information is restored. LTM candidate cell or beam configuration, the LTM candidate cell or beam configuration including a Transmission Configuration Indicator (TCI) status list for each candidate configuration; The handover (HO) type performed by the wireless device, wherein the handover type includes at least one of normal HO, conditional HO (CHO) or LTM; The configured HO type includes at least one of LTM or CHO configured by the network device; Regarding the indication that the wireless device has received a cell handover command, the cell handover command includes target cell or beam information that does not match any candidate configuration; Layer 1 measurement results; Indication of the reason for LTM cell handover failure; Information related to the Random Access Channel (RACH) during LTM cell handover; or No information available for RACH LTM.

3. The method according to claim 2, wherein, The LTM cell handover failure includes at least one of RACH failure or no RACH failure.

4. The method according to claim 2 or 3, wherein, The RACH-related information for the LTM cell handover includes at least one of the following: RACH type, wherein the RACH type includes at least one of Contention-Free Random Access (CFRA) or Contention-Based Random Access (CBRA); Random access preamble used for CFRA; Synchronization Signal / Physical Broadcast Channel (SS / PBCH) index, used to determine the RACH timing (RO) for Physical Random Access Channel (PRACH) transmission for CFRA resources. PRACH mask index, which indicates the RO associated with the SS / PBCH indicated by the SS / PBCH index for PRACH transmission of CFRA resources; or Instructions regarding whether to use Supplemental Uplink (SUL) or Normal Uplink (NUL) as the uplink (UL) carrier to transmit CFRA resources via PRACH.

5. The method according to any one of claims 2 to 4, wherein, The information related to RACH-free LTM includes at least one of the following: How the wireless device obtains the timing advance (TA) value of the target; The TA value of the target cell; Early uplink (UL) synchronization configuration, which includes at least one of the measured candidate cell frequency information, parameter set, or bandwidth portion (BWP) information; or If the TA value is measured using a wireless device-based method, the wireless device has maintained the TA value for a certain period of time.

6. The method according to any one of claims 2 to 5, wherein, The network device compares the first duration with a local variable T1 configured by Operation, Administration and Maintenance (OAM) and determines that the LTM cell handover is premature based on the following: The first duration is less than T1; and After the first duration, the wireless device selects the original cell or beam.

7. The method according to any one of claims 2 to 5, wherein, The network device compares the first duration with a local variable T1 configured by Operation, Administration and Maintenance (OAM) and determines whether the LTM cell handover is a case of correct cell beam error based on the following: The first duration is less than T1; LTM cell handover failure occurred; After the LTM cell handover fails, the radio device selects a cell from the cell handover command from the network device; and The beam selected by the wireless device does not match the beam indicated in the cell handover command.

8. The method according to any one of claims 2 to 5, wherein, The network device compares the first duration with a local variable T1 configured by Operation, Administration and Maintenance (OAM) and determines whether the LTM cell handover is a cell error based on the following: The first duration is less than T1; and After an LTM cell handover fails, the radio device selects a cell that is neither the cell in the cell handover command from the network device nor the source cell.

9. The method according to any one of claims 2 to 5, wherein, The network device compares the first duration with a local variable T1 configured by Operation, Administration and Maintenance (OAM) and determines that the LTM cell handover is too late based on the following: The first duration is greater than T1; and After an LTM cell handover fails, the radio device selects a cell that is not the source cell.

10. The method according to any one of claims 6 to 9, wherein, The local variable T1 is a threshold specifically configured for LTM.

11. A wireless communication method, comprising: The wireless device updates the suboptimal successful mobility report information regarding mobility robustness optimization for Layer 1 or Layer 2 triggered mobility (LTM) based on the condition being met. as well as The wireless device sends the suboptimal success mobility report information.

12. The method according to claim 11, wherein, The conditions include at least one of the following: LTM cell handover was successfully executed; A beam failure occurred after the LTM cell handover process, and beam failure recovery (BFR) was successfully performed. The time from when the last LTM cell handover is triggered to when the first beam failure occurs is less than the threshold T2 configured by the network device; LTM is configured but not triggered; A beam failure occurs before LTM cell handover is triggered and BFR is successfully executed; LTM is configured but another switching (HO) type is performed, the HO type including at least one of normal HO or conditional HO (CHO); A CHO is configured, but another HO type is executed, including LTM or normal HO. In LTM based on Random Access Channel (RACH), the selected beam of the cell is not included in the candidate configuration of the cell; After a successful LTM cell handover, the selected beam of the cell is not included in the candidate configuration of the cell in the BFR. or If the ratio between the elapsed time value of timer T304 in the LTM process and the value of timer T304 configured by the network device for the wireless device is greater than the configured threshold R1.

13. The method according to claim 11 or 12, wherein, The suboptimal successful mobility report information includes at least one of the following: The duration from when LTM cell handover is triggered to when the first beam failure occurs; Indication regarding a beam failure that occurs shortly after an LTM cell handover process and a successful beam failure recovery (BFR); Regarding the indication of successful BFR after beam failure, where LTM is configured but not triggered; Conditions that trigger the report; Source cell or beam information; Cell or beam information in the cell handover command; Successfully executed the cell or beam information of the BFR of the wireless device; Layer 1 measurement results; LTM candidate cell or beam configuration, the LTM candidate cell or beam configuration including a Transmission Configuration Indicator (TCI) status list for each candidate configuration; The handover (HO) type performed by the wireless device, wherein the HO type includes at least one of normal HO, conditional HO (CHO) or LTM; The configured HO type includes at least one of LTM or CHO; The random access channel (RACH) type of LTM, which includes LTM without RACH or LTM based on RACH; RACH configuration, the RACH configuration including at least one of contention-free random access (CFRA) configuration or contention-based random access (CBRA) configuration; RACH resources; How the wireless device obtains the timing advance (TA) value of the target, wherein the obtaining is based on the wireless device or on the network; Whether the LTM cell handover process for the target cell has completed early downlink (DL) synchronization; Did the LTM cell handover process for the target cell complete early uplink (UL) synchronization? Can the TA value be used in the target cell? 14. The method according to claim 13, wherein, The network device compares the duration with the local variable T3 configured by Operation, Administration and Maintenance (OAM) and determines whether the LTM cell handover is a case of correct cell beam error based on the following: The duration is less than T3; and After a successful BFR, the wireless device connects to the network device via the cell configured in the cell handover command, but with a different beam than the cell handover command.

15. The method according to any one of claims 11 to 14, wherein, The suboptimal successful mobility report information is sent upon receiving a request from a network device.

16. A wireless communication method, comprising: A list of subsequent Layer 1 or Layer 2 triggered mobility (LTM) trajectory information sent by a wireless device, wherein the subsequent LTM trajectory information is used to update LTM mobility history information.

17. The method according to claim 16, wherein, The wireless device was configured with subsequent LTM by the network device.

18. The method according to claim 16 or 17, wherein, The list of subsequent LTM trajectory information is sent upon receiving a request from a network device.

19. The method according to any one of claims 16 to 18, wherein, The subsequent LTM trajectory information includes at least one of the following: This is used to indicate that the subsequent LTM trajectory information is an indication for subsequent LTM; Cell or beam information; The time spent in combining cells and beams; The location information of the wireless device; Regarding the indication of whether a successful LTM is based on LTM recovery or on a cell handover command from the network device, if the successful LTM is based on LTM recovery, the wireless device records the cell or beam information from the cell handover command from the network device; or Layer 1 measurements during LTM cell handover.

20. A wireless communication method, comprising: The distributed unit (DU) of the network device receives at least one of the following information regarding a Layer 1 or Layer 2 triggered mobility (LTM) ad hoc network: Failure report information; Suboptimal successful mobility report information; or Subsequent LTM trajectory information.

21. The method according to claim 21, wherein, At least one of the information is received from the centralized unit (CU) of the network device.

22. A wireless communication method, comprising: The network device receives at least one of the following information regarding a Layer 1 or Layer 2 triggered mobility (LTM) ad hoc network: Failure report information; Suboptimal successful mobility report information; or Subsequent LTM trajectory information.

23. The method according to claim 22, wherein, At least one of the information is received from another network device.

24. The method according to any one of claims 20 to 23, wherein, The failure report information includes at least one of the following: Subsequent LTM instructions; The first duration from when the last LTM cell handover is triggered until when an LTM cell handover failure or radio link failure (RLF) occurs; The second duration between the latest LTM configuration and LTM trigger; The third duration from when LTM cell handover is triggered to when the first beam failure occurs; Source cell or beam information; Failed cell or beam information is used to identify the cell or beam in which a radio link failure (RLF) occurs or ends; Cell or beam information in the cell handover command; The wireless device successfully re-established the cell or beam information for the Radio Resource Control (RRC) connection; If LTM recovery is performed after the cell selection process, LTM recovery cell or beam information is restored. LTM candidate cell or beam configuration, the LTM candidate cell or beam configuration including a Transmission Configuration Indicator (TCI) status list for each candidate configuration; A handover (HO) type performed by a wireless device, wherein the handover type includes at least one of normal HO, conditional HO (CHO), or LTM; The configured HO type includes at least one of LTM or CHO configured by the network device; The indication that the wireless device has received a cell handover command, the cell handover command including target cell or beam information that does not match any candidate configuration; Layer 1 measurement results; Indication of the reason for LTM cell handover failure; Information related to the Random Access Channel (RACH) during LTM cell handover; or No information available for RACH LTM.

25. The method according to any one of claims 20 to 24, wherein, The suboptimal successful mobility report information includes at least one of the following: The duration from when LTM cell handover is triggered to when the first beam failure occurs; Indication regarding a beam failure that occurs shortly after an LTM cell handover process and a successful beam failure recovery (BFR); Regarding the indication of successful BFR after beam failure, where LTM is configured but not triggered; Conditions that trigger the report; Source cell or beam information; Cell or beam information in the cell handover command; Successfully executed the cell or beam information of the wireless device's BFR; Layer 1 measurement results; LTM candidate cell or beam configuration, the LTM candidate cell or beam configuration including a Transmission Configuration Indicator (TCI) status list for each candidate configuration; A handover (HO) type performed by a wireless device, wherein the HO type includes at least one of normal HO, conditional HO (CHO), or LTM; The configured HO type includes at least one of LTM or CHO; The random access channel (RACH) type of LTM, which includes LTM without RACH or LTM based on RACH; RACH configuration, the RACH configuration including at least one of contention-free random access (CFRA) configuration or contention-based random access (CBRA) configuration; RACH resources; How a wireless device obtains the timing advance (TA) value of a target, wherein the obtaining is based on the wireless device or on a network; Whether the LTM cell handover process for the target cell has completed early downlink (DL) synchronization; Did the LTM cell handover process for the target cell complete early uplink (UL) synchronization? Can the TA value be used in the target cell? 26. The method according to any one of claims 20 to 25, wherein, The subsequent LTM trajectory information includes at least one of the following: This is used to indicate that the subsequent LTM trajectory information is an indication for subsequent LTM; Cell or beam information; The time spent in combining cells and beams; Location information of wireless devices; Regarding the indication of whether a successful LTM is based on LTM recovery or on a cell handover command from the network device, if the successful LTM is based on LTM recovery, the wireless device records the cell or beam information from the cell handover command from the network device; or Layer 1 measurements during LTM cell handover.

27. A wireless communication device, comprising a processor, wherein, The processor is configured to implement the method according to any one of claims 1 to 26.

28. A computer-readable program storage medium having code stored thereon, which, when executed by a processor, causes the processor to perform the method according to any one of claims 1 to 26.

Images