Self-organizing networks for lower-layer triggered mobility

Abstract

Systems, methods, and apparatus for wireless communication are described. An example method includes transmitting, by a wireless device, a failure report information or a sub-optimal success mobility report information on a mobility robustness optimization for a layer 1 or layer 2 triggered mobility (LTM). Another example method includes transmitting, by a wireless device, a list of subsequent LTM track information, where the subsequent LTM track information is used to update a LTM mobility history information. The failure report information, the sub-optimal success mobility report information, and the subsequent LTM track information are used to, among other benefits, improve the quality of LTM.

Description

SELF-ORGANIZING NETWORKS FOR LOWER-LAYER TRIGGERED MOBILITYTECHNICAL FIELD

[0001] This patent document is directed generally to wireless communications.BACKGROUND

[0002] Mobile telecommunication technologies are moving the world toward an increasingly connected and networked society. In comparison with the existing wireless networks, next-generation systems and wireless communication techniques will need to support a much wider range of use-case characteristics and provide a more complex and sophisticated range of access requirements and flexibilities.

[0003] Long-Term Evolution (LTE) is a standard for wireless communication for mobile devices and data terminals developed by 3rd Generation Partnership Project (3GPP) . LTE Advanced (LTE-A) is a wireless communication standard that enhances the LTE standard. The 5th generation of wireless system, known as 5G, advances the LTE and LTE-A wireless standards and is committed to supporting higher data rates, large number of connections, ultra-low latency, high reliability, and other emerging business needs.SUMMARY

[0004] This patent document discloses methods to improve the quality of lower-layer triggered mobility (LTM) . The network might not always be able to provide the most optimal LTM configurations to a user equipment (UE) . The UE can report sub-optimal LTM cell switch procedures and / or failure report information to the network to improve the LTM cell switch or handover.

[0005] A first example wireless communication method includes transmitting, by a wireless device, a failure report information on a mobility robustness optimization for a layer 1 or layer 2 triggered mobility (LTM) .

[0006] A second example wireless communication method includes updating, by a wireless device and based on a condition being met, a sub-optimal success mobility report information on a mobility robustness optimization for a layer 1 or layer 2 triggered mobility (LTM) . The method further includes transmitting, by the wireless device, the sub-optimal success mobility report information.

[0007] A third example wireless communication method includes transmitting, by a wireless device, a list of subsequent layer 1 or layer 2 triggered mobility (LTM) track information, where the subsequent LTM track information is used to update a LTM mobility history information.

[0008] A fourth example wireless communication method includes receiving, by a distributed unit (DU) of a network device, at least one of the following information on a self-organizing network for a layer 1 or layer 2 triggered mobility (LTM) : a failure report information; a sub-optimal success mobility report information; or a subsequent LTM track information.

[0009] A fifth example wireless communication method includes receiving, by a network device, at least one of the following information on a self-organizing network for a layer 1 or layer 2 triggered mobility (LTM) : a failure report information; a sub-optimal success mobility report information; or a subsequent LTM track information.

[0010] Note that where the patent document discloses a method of transmitting an information by a first device to a second device, it will be understood that a method of receiving the information by the second device from the first device is also disclosed. Similarly, where a method of receiving a message by a first device from a second device is disclosed, it will be understood that the message is transmitted by the second device to the first device.

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

[0012] In yet another example embodiment, the above-described methods are embodied in the form of processor-executable code and stored in a non-transitory computer-readable storage medium. The code included in the computer readable storage medium when executed by a processor, causes the processor to implement the methods described in this patent document.

[0013] The above and other aspects and their implementations are described in greater detail in the drawings, the descriptions, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIGs. 1-8 illustrate example scenarios of user equipment (UE) reporting to improve lower-layer triggered mobility (LTM) .

[0015] FIG. 9 illustrates an example network interface.

[0016] FIG. 10 is an example flowchart for transmitting a failure report information.

[0017] FIG. 11 is an example flowchart for transmitting a sub-optimal success mobility report information.

[0018] FIG. 12 is an example flowchart for transmitting a LTM track information.

[0019] FIG. 13 is an example flowchart for receiving a LTM information by a distributed unit (DU) of a network device.

[0020] FIG. 14 is an example flowchart for receiving a LTM information by a network device.

[0021] FIG. 15 illustrates an example block diagram of a hardware platform that may be a part of a network device or a wireless device.

[0022] FIG. 16 illustrates example wireless communication including a Base Station (BS) and User Equipments (UEs) based on some implementations of the disclosed technology.DETAILED DESCRIPTION

[0023] The example headings for the various sections below are used to facilitate the understanding of the disclosed subject matter and do not limit the scope of the claimed subject matter in any way. Accordingly, one or more features of one example section can be combined with one or more features of another example section. Furthermore, 5G terminology is used for the sake of clarity of explanation, but the techniques disclosed in the present document are not limited to 5G technology only and may be used in wireless systems that implemented other protocols.

[0024] I. Introduction

[0025] The present patent document discloses reporting sub-optimal lower-layer triggered mobility (LTM) cell switch procedures and / or failure report information to the network. The disclosed methods, among other benefits, improve the quality of LTM cell switch and handover.

[0026] The support of LTM (L1 / L2 Triggered Mobility: a cell switch procedure that the network triggers via MAC CE based on L1 measurements) was introduced in 3GPP Rel-18, to further enhance the UE mobility, to avoid complete L2 (and L1) resets, and to reduce latency / overhead / interruption, and to provide a similar mobility experience like beam switch mobility.

[0027] However, current 3GPP SON / MDT (Self-Organizing Network and Minimization of Drive Testing) technique does not cover LTM yet. Specifically, the MRO (Mobility Robustness Optimization) in SON needs enhancement to better support LTM, by which network is able to be better aware of the failure, sub-optimal successful LTM, or bad implementation happened for the LTM procedure.

[0028] In this patent document, the following issues are addressed:

[0029] - Recognize the possible issues (e.g., failure, sub-optimal successful LTM, bad implementation happened for LTM procedure, inappropriate LTM candidate configuration, or inappropriate cell switch command decision, etc. ) . This is the first step to identify the SON enhancements for LTM which brings certain  new things to legacy mobility procedure, e.g., RACH-less LTM with early synchronization, and beam level operation.

[0030] - Define the essential information that is needed to be provided to network from UE, to help network facilitate better LTM decisions in LTM configuration / timing, etc.

[0031] - Define the key interface enhancement to network, to allow network to support the MRO enhancement for LTM, e.g., enhance F1AP interface between gNB-CU and gNB-DU, and enhance XnAP interface between two network nodes.

[0032] MRO is a 3GPP technique that dates back to LTE era, in which a few key scenarios were identified, e.g., too early HO (hand-over) , too late HO and wrong cell HO. In these scenarios 3GPP had defined information the UE can be triggered to record and upload to network upon network request, e.g., UE measurement result, time since HO was triggered to HO failure or RLF (radio link failure) happened, the cell UE connected to re-establish the RRC connection, or the last HO type (CHO, DAPS etc. ) . Network, based on such information, may be able to recognize which scenario the failure or sub-optimal successful mobility had happened (including HO timing) , and which HO configuration / decision could be optimized.

[0033] Before digging into any enhancement to the MRO for LTM, one needs to be familiar with how LTM works. An exemplary LTM procedure is provided as follows, to facilitate the person of ordinary skill in the art to understand the possible issues in an LTM procedure:

[0034] 1. The gNB may decide to configure LTM and initiates LTM preparation, based on UE’s MeasurementReport message to the gNB. However, LTM might not always be necessary, e.g., in some cases legacy L3 mobility, including CHO (conditional HO) might be triggered before LTM is executed.

[0035] 2. The gNB initiates LTM by reconfiguration to UE including the LTM candidate configurations.

[0036] 3. The UE stores the LTM candidate configurations and waits for further network trigger (i.e., cell switch command) .

[0037] 4. The UE may perform early DL / UL synchronization with the candidate cell (s) before LTM is executed. By UL synchronization, UE is able to get the TA (Timing Advance) . UE synchronization can be configured as UE-based TA measurement or network based. In network-based TA measurement, UE performs early TA acquisition with the candidate cell (s) as requested by the network before receiving the cell switch command. This is done via CFRA triggered by a PDCCH order from the source cell, following which the UE sends preamble towards the indicated candidate cell. The TA value of the candidate cell is indicated in the cell switch command. There are possibly issues as well, for example: early DL / UL sync might not always happen before LTM is triggered which results in longer LTM cell switch procedure and potentially higher risks of failure;  the TA value UE obtained during this phase might be accurate, or not timely updated, which results in failure as well.

[0038] 5. The UE performs L1 (layer 1) measurements and transmits L1 measurement reports to the configured candidate cell (s) to the gNB.

[0039] 6. The gNB decides to execute cell switch the UE to a target cell and triggers cell switch by transmitting a MAC CE including the candidate configuration index of the target cell and the beam information the UE is switched to. The UE switches to the target cell and applies the configuration indicated by candidate configuration index using RACH-less based LTM (i.e., there is no random access procedure, TA value is known to UE beforehand) or RACH based LTM (i.e., UE only gets the TA value through random access procedure) . Possible issues: wrong LTM timing, e.g., too early / too late LTM triggered, issues in RACH-less cell switch procedure (wrong cell or beam information, inappropriate TA value) , or issues in random access procedure, e.g., sub-optimal CFRA configuration for RACH based LTM, that results in LTM cell switch failure, or RLF. The LTM cell switch failure could also be categorized as handover failure.

[0040] 7. The UE performs the random access procedure towards the target cell, if UE does not have valid TA of the target cell. Possible issues: LTM cell switch could fail due to, inappropriate cell and / or beam information in the cell switch command, and also RACH failure due to the sub-optimal RACH configuration.

[0041] 8. The UE completes the LTM cell switch procedure by sending RRCReconfigurationComplete message to target cell.

[0042] The steps 4-8 can be performed multiple times for subsequent LTM using the LTM candidate configuration (s) provided in step 2. While for subsequent LTM, network might need to record the track of the subsequent LTM, therefore to provide an optimized subsequent LTM configuration in the future.

[0043] The following will be organized based on the possible LTM failure / sub-optimal scenarios: failure case, sub-optimal LTM case, LTM history track information, and network interface. In the following embodiments, the reported information can be a list, and the items in the list include the information described in the following sections.

[0044] II. Embodiment 1

[0045] Embodiment 1 describes too early LTM cell switch.

[0046] In one example, a LTM cell switch decision might be made too early: a UE was in cell1 / beam1-1 is LTM cell switched to cell2 / beam 2-1, and there might be following cases as shown in FIG. 1.

[0047] Case 1-a. The LTM cell switch failure happens in FIG. 1 step 2, e.g., UE is not able to receive any scheduling on the target cell / beam or is not able to determine that the network has successfully received its first UL data or not (i.e., cell2 / beam2-1) for a RACH-less cell switch (RACH-less failure) or UE was not able to finish the random access procedure for a RACH-based LTM (RACH failure) , and a network-configured timer, e.g., T304 expires (which starts upon an LTM cell switch procedure is triggered by network) . UE executes the cell selection procedure, and afterwards re-establish the connection at the source cell / beam, i.e., cell1 / beam1-1, as shown in FIG. 1 step 3.

[0048] A few definitions frequently used in this patent document are provided below:

[0049] RACH-less failure. UE is not able to receive any scheduling on the target cell / beam or, is not able to determine that the network has successfully received its first UL data or not, for a certain network-configured period (e.g., before T304 expires) .

[0050] RACH failure: UE is not able to finish the random access procedure based on network configuration for a certain network-configured period (e.g., before T304 expires) .

[0051] LTM cell switch failure. An LTM cell switch failure could be due to RACH-less failure or a RACH failure.

[0052] Case 1-b. Even the LTM cell switch is successfully executed (either RACH based or RACH-less based) , the connection between UE and the target cell / beam is not stable, radio link failure (RLF) soon happens to UE as shown in FIG. 1 step 2. UE executes the cell selection procedure, and afterwards re-establish the connection at the source cell / beam, i.e., cell1 / beam1-1 as shown in FIG. 1 step 3.

[0053] When the above failure happens (LTM cell switch failure or RLF) , UE updates the failure report information to network and transfers it to network upon network request. LTM cell switch failure could be RACH-less LTM failure or RACH-based LTM failure.

[0054] In the above scenarios, UE reports the following information to network to indicate the failure information and associated details to facilitate network to recognize the potential issues (e.g., it might be a too early LTM cell switch, the channel condition at target is actually worse than the source; UE reconnects to network, i.e., cell1, by applying LTM recovery procedure instead of RRC re-establishment) :

[0055] - The duration from last LTM cell switched is triggered to the failure happens, the failure could be LTM cell switch failure (RACH-less failure or RACH failure) or the RLF. Network might compare this duration to a local variable T1 which may be configured by OAM (Operations, Administration and Maintenance) , if such duration is shorter than T1, and UE afterwards select to the original cell and / or beam, network might recognize this is a too early LTM cell switch.

[0056] - L1 (layer 1) measurements results. UE may provide the latest L1 measurements of the LTM candidate cells to network, to help network to evaluate the connection condition upon the LTM cell switch command was triggered.

[0057] - Indication of what happens, e.g., details or cause to LTM cell switch failure (RACH-less failure, or RACH failure) or RLF failure. UE might report whether it is RACH-less failure, RACH failure or RLF happened, and information related to above failures (for RACH-less failure, see a separate section) to help network to identify the root cause of the problem. The above indication could also be identified as the cause value of the report.

[0058] - RACH related information for the LTM cell switch, e.g., CFRA related information, RACH resources.

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

[0060] - Failed cell information and beam information, to identify in which cell / beam the RLF happened.

[0061] - Cell and beam information in the cell switch command. This is used to help network to identify the cell and beam information source indicated in the cell switch command.

[0062] - Cell and beam information UE successfully re-establish RRC connection at. based on this information , network can check whether UE re-establish RRC connection at the original or source cell / beam.

[0063] - LTM recovery cell information. LTM recovery might be executed after the cell selection procedure, if the source cell (cell1) is an LTM candidate cell and if network configured the UE to try LTM then the UE attempts LTM execution once, in this case, the LTM recovery can be carried out.

[0064] - LTM recovery beam information. UE might additionally provide the beam information at the LTM recovery cell, e.g., cell 1 / beam1-1.

[0065] - LTM candidate cell configuration. This is to indicate the candidate cell list in the LTM candidate configuration, it might further include the full configuration (including the TCI state list) of each candidate configuration.

[0066] In another example, an LTM cell switch decision might trigger the switch too early for a LTM cell switch to the same cell but different beam, a UE was in cell1 / beam1-1 is LTM cell switched to cell1 / beam 1-2, , there might be following sub-cases:

[0067] Case 1-c. Even the LTM cell switch is successfully executed, the connection between UE and the target beam is not stable, beam failure soon happens to UE. UE executes the beam failure recovery (BFR) procedure, and afterwards beam failure recovery for cell1 is successful with at the original beam, i.e., beam1-1.

[0068] Case 1-d. The LTM cell switch failed. UE then executes the cell selection procedure, and afterwards re-establish the connection at the source cell / beam, i.e., cell1 / beam1-1.

[0069] In case 1-c, since BFR is successfully executed, there is no explicit failure happening. however to facilitate network to spot the issues (i.e., too early LTM switch to another beam in the same cell) , UE might be able to report such event to network under the following conditions:

[0070] - LTM cell switch is successfully executed.

[0071] - Beam failure happens and BFR is successfully executed after LTM cell switch procedure.

[0072] - And additionally, UE reports only if above event happens shortly after LTM cell switch is triggered, e.g., the duration from LTM cell switched is triggered to the first beam failure happens is shorter than a configured threshold T2 from network.

[0073] UE in this case might report the following information to network in a report indicating a sub-optimal successful LTM cell switch procedure:

[0074] - The cause / trigger of such report.

[0075] - The duration from last LTM cell switched is triggered to the first beam failure happens. Network might, based on this value, evaluate the target beam quality for the UE.

[0076] - Indication of what happens, e.g., beam failure shortly after the LTM cell switch procedure, to help network to identify the root cause of the problem.

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

[0078] - Cell and beam information in the cell switch command. This is used to help network to identify the cell and beam information source indicated in the cell switch command.

[0079] - Cell and beam information in which UE’s beam failure recovery is successfully executed.

[0080] - L1 measurements results. UE may provide the latest L1 measurements of the LTM candidate cells to network before the LTM cell switch is triggered, to help network to evaluate the connection condition upon the LTM cell switch command was triggered.

[0081] For case1-d, UE might report the same information as case 1-aand 1-b in the failure report.

[0082] III. Embodiment 2

[0083] Embodiment 2 describes a right cell wrong (or sub-optimal) beam LTM cell switch.

[0084] In one example, an LTM cell switch decision is triggered by network, and the UE is switched to the right cell but wrong beam (or sub-optimal beam that could result in successful LTM cell switch but not stable connection at target beam) : a UE was in cell1 / beam1-1 is commanded to LTM cell switched to cell2 / beam 2-1, and there are a few sub-cases:

[0085] Case 2-a. The LTM cell switch failed in FIG. 2 step 2. UE executes the cell selection procedure, selects to cell 2, and afterwards re-establish the connection at the cell2 / beam2-2, as shown in FIG. 2 step 3.

[0086] When the above failure happens (LTM cell switch failure) , UE updates the failure report information to network and transmits it to network upon network request. LTM cell switch failure could be RACH-less LTM failure or RACH-based LTM failure.

[0087] In the above scenarios, UE reports the following information to network to indicate the failure information, and its details to facilitate network to recognize the potential issues (e.g., the target cell info in LTM cell switch command is appropriate as the UE eventually selects to cell 2 but the indicated beam information in the LTM cell switch command is not, as UE fails to be LTM cell switched to beam 2-1 but eventually UE selects to anther beam, i.e., beam 2-2, in the same cell; UE could also reconnects to network by applying LTM recovery procedure instead of RRC re-establishment) :

[0088] - The duration from last LTM cell switched is triggered to the failure happens, the failure could be LTM cell switch failure (RACH-less failure or RACH failure) . Network might compare this duration to a local variable T1 which may be configured by OAM (Operations, Administration and Maintenance) , If such duration is too short and UE eventually connects to network through the configured cell (i.e., cell 2) but a different beam (i.e., beam 2-2 in above case) , network might recognize this as a right cell wrong beam case.

[0089] - L1 measurements results. UE may provide the latest L1 measurements of the LTM candidate cells to network, to help network to evaluate the connection condition upon the LTM cell switch command was triggered.

[0090] - Indication of what happens, e.g., details or cause to LTM cell switch failure (RACH-less failure, or RACH failure) . UE might report whether it is RACH-less failure or RACH failure, and information related to above failures (for RACH-less failure, see a separate section) to help network to identify the root cause of the problem. The above indication could also be identified as the cause value of the report.

[0091] - RACH related information for the LTM cell switch, e.g., CFRA related information, RACH resources.

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

[0093] - Cell and beam information in the cell switch command. This is used to help network to identify the cell and beam information source indicated in the cell switch command.

[0094] - Cell and beam information UE successful re-establish RRC connection at.

[0095] - LTM recovery cell information. LTM recovery might be executed after the cell selection procedure, if the source cell (cell2) is an LTM candidate cell and if network configured the UE to try LTM then the UE attempts LTM execution once, in this case, the LTM recovery cell is the source cell (cell2) .

[0096] - LTM recovery beam information. UE might additionally provide the beam information at the LTM recovery cell, e.g., cell 2 / beam2-2.

[0097] - LTM candidate cell configuration. This is to indicate the candidate cell list in the LTM candidate configuration, it might further include the full configuration (including the TCI state list) of each candidate configuration.

[0098] Case 2-b. Even the LTM cell switch is successfully executed, the connection between UE and the target cell / target beam is not stable, beam failure soon happens to UE as shown in FIG. 3 step 2. UE executes the BFR procedure, and afterwards the BFR is successful at cell2 / beam2-2, as shown in FIG. 3 step 3.

[0099] In case 2-b, since BFR is successfully executed, there is no explicit failure happening. however to facilitate network to spot the issues (i.e., right cell but sub-optimal beam selection in the LTM cell switch command) , UE might be able to report such event to network under or without the following conditions:

[0100] - LTM cell switch is successfully executed.

[0101] - Beam failure happens and BFR is successful executed after LTM cell switch procedure.

[0102] - And additionally, UE reports only if above event happens shortly after LTM cell switch is triggered, e.g., the duration from LTM cell switched is triggered to the first beam failure happens is shorter than a configured threshold T2 from network.

[0103] UE in this case might report the following information to network in a report indicating a sub-optimal successful LTM cell switch procedure:

[0104] - The trigger condition (cause) of such report.

[0105] - The duration from last LTM cell switched is triggered to the first beam failure happens. Network might, based on this value, evaluate the target beam quality for the UE. Network might compare this duration to a local variable T3 which may be configured by OAM (Operations, Administration and Maintenance) , If such duration is too short and after BFR is successful, UE connects to network through the configured cell (i.e., cell 2) but a different beam (i.e., beam 2-2 in above case) , network might recognize this as a right cell wrong beam case.

[0106] - Indication of what happens, e.g., beam failure shortly after the LTM cell switch procedure, to help network to identify the root cause of the problem.

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

[0108] - Cell and beam information in the cell switch command. This is used to help network to identify the cell and beam information source indicated in the cell switch command.

[0109] - Cell and beam information in which UE’s beam failure recovery is successfully executed.

[0110] - L1 measurements results. UE may provide the latest L1 measurements of the LTM candidate cells to network before the LTM cell switch is triggered, to help network to evaluate the connection condition upon the LTM cell switch command was triggered.

[0111] IV. Embodiment 3

[0112] Embodiment 3 describes a wrong cell LTM cell switch.

[0113] In one example, an LTM cell switch decision might not be able to switch the UE to the right cell: a UE was in cell1 / beam1-1 is LTM cell switched to cell2 / beam 2-1, and in the following sub-cases:

[0114] Case 3-a. The LTM cell switch failed in FIG. 4 step 2. UE executes the cell selection procedure, and afterwards re-establish the connection at another cell that is not either cell1 or cell2, e.g., cell3 / beam3-2, as shown in FIG. 4 step 3.

[0115] Case 3-b. Even the LTM is successfully executed, the connection between UE and the target cell is not stable, radio link failure soon happens to UE in cell2. UE executes the cell selection procedure, and afterwards re-establish the connection at another cell that is not either cell1 or cell2, e.g., cell3 / beam3-2. Case 3-b is shown in FIG. 5.

[0116] When the above failure happens (LTM cell switch failure or RLF) , UE updates the failure report information to network and transmits it to network upon network request.

[0117] In the above scenarios, UE reports the following information to network to, to facilitate network to recognize the potential issues (e.g., it might be a wrong cell LTM cell switch, there is actually a better cell, i.e., cell3, as the target cell of LTM cell switch, instead of cell2) :

[0118] - The duration from last LTM cell switched is triggered to the failure happens, the failure could be LTM cell switch failure (RACH-less failure or RACH failure) or the RLF. Network might compare this duration to a local variable T1 which may be configured by OAM (Operations, Administration and Maintenance) , if such duration is shorter than T1 and UE establishes the connection at another cell that is either not cell 2 or cell1, i.e., cell3, network might recognize this is a wrong cell LTM cell switch.

[0119] - L1 measurements results. UE may provide the latest L1 measurements of the LTM candidate cells to network before the LTM cell switch is triggered, to help network to evaluate the connection condition upon the LTM cell switch command was triggered.

[0120] - Indication of what happens, e.g., details or cause to LTM cell switch failure (RACH-less failure, or RACH failure) or RLF failure. UE might report whether it is RACH-less failure, RACH failure or RLF happened, and information related to above failures (for RACH-less failure, see a separate section) to help network to identify the root cause of the problem. The above indication could also be identified as the cause value of the report.

[0121] - RACH related information for the LTM cell switch, e.g., CFRA related information, RACH resources.

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

[0123] - Failed cell information and beam information, to identify in which cell / beam the RLF happened.

[0124] - Cell and beam information in the cell switch command. This is used to help network to identify the cell and beam information source indicated in the cell switch command.

[0125] - Cell and beam information UE successful re-establish RRC connection at.

[0126] - LTM recovery cell information. LTM recovery might be executed after the cell selection procedure, if the cell3 is an LTM candidate cell and if network configured the UE to try LTM after RLF then the UE attempts LTM execution once, in this case, the LTM recovery cell can be carried out.

[0127] - LTM recovery beam information. UE might additionally provide the beam information at the LTM recovery cell, e.g., cell 3 / beam 3-2.

[0128] - LTM candidate cell configuration. This is to indicate the candidate cell list in the LTM candidate configuration, it might further include the full configuration (including the TCI state list) of each candidate configuration.

[0129] V. Embodiment 4

[0130] Embodiment 4 describes a too late LTM cell switch.

[0131] In one example, the network configures UE with LTM related configurations, e.g., candidate LTM configurations. Network does not trigger the LTM, and beam failure happens. There might be following sub-cases.

[0132] Case 4-a. UE was connected to network through cell 1, beam 1-1. Meanwhile, UE is configured with LTM configuration for potential LTM mobility. However, beam failure happens before network triggers any LTM mobility. Beam failure recovery is carried out by UE successfully, and UE re-connects to network through another beam in 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, or no RLF) . However the beam failure happens and eventually UE recover its beam at another beam, i.e., cell1 / beam1-3, this indicates that UE needs the LTM triggered earlier or beam switch earlier from network, if LTM is already configured from network (and if beam 1-3 is already in the LTM candidate configuration) . Case 4-1 is shown in FIG. 6.

[0133] In case 4-a, since BFR is successfully executed, there is no explicit failure happening. however to facilitate network to spot the issues (i.e., too late LTM switch to another beam in the same cell) , UE might be able to report such event to network under the following conditions:

[0134] - LTM is configured and not triggered.

[0135] - beam failure happens but BFR is successfully executed before LTM cell switch is triggered.

[0136] UE in this case might report the following information to network in a report indicating a sub-optimal LTM procedure:

[0137] - The trigger condition (cause) of such report.

[0138] - Indication of what happens, e.g., BFR is successful following beam failure happens, with LTM configured but not triggered, to help network to identify the root cause of the problem.

[0139] - Cell and beam information in which UE’s beam failure recovery is successfully executed.

[0140] - L1 measurements results. UE may provide the latest L1 measurements of the LTM candidate cells to network before the LTM cell switch is triggered, to help network to evaluate the connection condition upon the LTM cell switch command was triggered.

[0141] - LTM candidate cell configuration. This is to indicate the candidate cell list in the LTM candidate configuration, it might further include the full configuration (including the TCI state list) of each candidate configuration.

[0142] Case 4-b. In another example, UE connects to network through cell1 / beam1-1. An LTM, although configured as in step1, however, is never triggered. An RLF happens afterwards (as in step 2) and UE re-selects anther cell, i.e., cell2 / beam 2-2 (as in step 3) . Case 4-b is shown in FIG. 7.

[0143] When the above failure happens (i.e., RLF) , UE updates the failure report information to network and transmits it to network upon network request.

[0144] In the above scenarios, UE reports the following information to network to indicate the failure information, and its details to facilitate network to recognize the potential issues (e.g., it might be a too late LTM cell switch, the channel condition at source is actually worse than one of the candidate cell; UE could also reconnects to network, i.e., cell2, by applying LTM recovery procedure instead of RRC re-establishment if enabled by network) :

[0145] - The duration from last LTM cell switched is triggered to the failure happens, the failure could be the RLF. Network might compare this duration to a local variable T1 which may be configured by OAM (Operations, Administration and Maintenance) , if such duration is longer than T1, network might recognize this is a too late LTM cell switch.

[0146] - L1 measurements results. UE may provide the latest L1 measurements of the LTM candidate cells to network, to help network to evaluate the connection condition upon the LTM cell switch command was triggered.

[0147] - Failed cell information and beam information, to identify in which cell / beam the RLF happened.

[0148] - Cell and beam information UE successful re-establish RRC connection at.

[0149] - LTM recovery cell information. LTM recovery might be executed after the cell selection procedure, if the source cell (cell1) is an LTM candidate cell and if network configured the UE to try LTM then the UE attempts LTM execution once, in this case, the LTM recovery can be carried out.

[0150] - LTM recovery beam information. UE might additionally provide the beam information at the LTM recovery cell, e.g., cell 1 / beam1-1.

[0151] - LTM candidate cell configuration. This is to indicate the candidate cell list in the LTM candidate configuration, it might further include the full configuration (including the TCI state list) of each candidate configuration.

[0152] Case 4-c. In another example, LTM is configured to UE but never triggered. A normal Layer 3 mobility is triggered by network (by handover command in RRC message) , or triggered by a condition configured to UE (i.e., Conditional HO, CHO) . The normal HO or CHO could be successfully executed or failed. A normal HO is a HO that is triggered by a handover command in RRC Reconfiguration message. Case 4-c is shown in FIG. 8.

[0153] If successful, there is no explicit failure happening. To facilitate network to spot the issues (i.e., too early LTM switch to another beam in the same cell) , UE might be able to report such event to network under the following conditions:

[0154] - LTM is configured but other type of handover (normal HO or CHO) is executed; or CHO is configured but other type of handover (LTM or normal HO) is executed.

[0155] UE in this case might report the following information to network in a report indicating a sub-optimal HO procedure:

[0156] - the trigger condition (cause) of such report.

[0157] - The handover type that is actually carried out. In above case, it is normal HO, CHO or LTM.

[0158] - The configured handover type. In above case, it is LTM or CHO (to cover the case that both are configured, however normal mobility or LTM is triggered) .

[0159] - L1 measurements results for LTM candidate cells. UE may provide the latest L1 measurements of the LTM candidate cells to network before the LTM cell switch is triggered, to help network to evaluate the connection condition upon the LTM cell switch command was triggered.

[0160] If failed, upon above failure happens (Handover failure or RLF) , UE updates the failure report information to network and transmits it to network upon network request.

[0161] In the above scenarios, UE reports the following information to network to indicate the failure information, and its details to facilitate network to recognize the potential issues (e.g., a normal HO is triggered, even LTM is configured which could be resource inefficient) :

[0162] - The handover type that is actually carried out. In above case, it is normal HO, CHO or LTM.

[0163] - The configured handover type. In above case, it is LTM or CHO (to cover the case that both are configured, however normal mobility or LTM is triggered) .

[0164] VI. Embodiment 5

[0165] Embodiment 5 describes other miscellaneous to report from UE.

[0166] 5.1 Duration between the latest LTM configuration to the LTM trigger

[0167] Network might want to be aware how efficient LTM configuration is. One aspect is the duration between the latest LTM configuration to the LTM trigger. A longer such duration means the resource will be pre-allocated for such UE for a longer period, thus more resource in candidate cells consumed.

[0168] Such duration can be indicated to network in report indicating a sub-optimal successful LTM cell switch procedure or a failure report information.

[0169] 5.2 Successful beam does not match pre-configuration

[0170] There are cases the candidate configuration from network is sub-optimal, e.g., the best cell / beam is not a part of the LTM candidate configuration, which results in failed or sub-optimal.

[0171] Case 5.2. a. In one example, a UE experiences a RACH-based LTM. In a RACH-based LTM, UE selects a suitable beam to random access to the target cell. The RACH-based LTM is successfully executed. UE however finds that the selected beam is not included in the candidate configuration for this cell.

[0172] Case 5.2. b. In another example, a UE experienced a RACH-less LTM, and fails. UE eventually carries out an LTM recovery or RRC re-establishment at a selected cell with a selected beam by UE. UE however finds that the selected cell / beam is not included in the candidate configuration for this cell.

[0173] Case 5.2. c. In another example, a UE experienced a LTM cell switch, and successes. Soon beam failure happens, but BFR is successfully executed. UE however finds that the selected beam is not included in the candidate configuration for this cell.

[0174] Case 5.2. d. In another example, a UE experienced a RACH-less LTM, and successes. Soon RLF happens. UE eventually carries out an LTM recovery or RRC re-establishment at a selected cell with a selected beam by UE. UE however finds that the selected beam is not included in the candidate configuration for this cell (which is one of the candidate cells) .

[0175] For the sub-optimal successful LTM in case 5.2. aand 5.2. c, under the following conditions:

[0176] - The selected beam of a cell in a RACH-based LTM is not included in the candidate configuration for this cell, or

[0177] - The selected beam of a cell in a BFR after successful LTM cell switch, is not part of the candidate configuration for this cell.

[0178] UE is triggered to report a sub-optimal successful LTM cell switch. In the reported content, it at least include the LTM candidate configuration, the cell and beam information that LTM is successfully executed, or UE directly indicate the observed inconsistency.

[0179] For case 5.2. b and 5.2. d, UE reports the selected cell / beam after LTM cell switch failure or RLF, and the LTM candidate configuration.

[0180] 5.3 T304 threshold triggered sub-optimal LTM report

[0181] An LTM cell switch procedure might take too long and result in a sub-optimal LTM. The risk of failure to LTM increases as it takes longer to finish, meanwhile LTM is supposed to be a faster procedure compared to legacy Layer 3 mobility, such as to offer a lower latency / interruption and seamless experience. Network might want to collect information about such sub-optimal LTM procedure, like the RACH type of the LTM (RACH-less or RACH based) , how UE get the TA information from network, whether early DL / UL sync is done during the LTM cell switch procedure, etc., when the LTM cell switch procedure takes too long.

[0182] In one example, UE is configured with a threshold R1 that, if the ratio between the value of the elapsed time of the timer T304 for the LTM procedure, and the configured value of the T304 timer configured from network, is greater than the configured threshold R1, UE is to update the report of the associated information to the LTM procedure and report to network when requested by network. The report includes the at least one of the following:

[0183] - The trigger condition (cause) of such report, i.e., the ratio between the value of the elapsed time of the timer T304 for the LTM procedure, and the configured value of the T304 timer configured from network, is greater than the configured threshold R1.

[0184] - RACH type of the LTM (RACH-less or RACH based) .

[0185] - RACH configuration, e.g., CFRA configuration, RACH resources.

[0186] - The method UE obtain its TA value for the target, e.g., UE based or network based.

[0187] - Whether early DL sync is done for the LTM cell switch procedure.

[0188] - Whether early UL sync is done for the LTM cell switch procedure (i.e., whether the TA value is available for the target cell) .

[0189] 5.4 Cell switch command does not match the candidate configuration

[0190] In one example, a UE might receive a cell switch command including a target cell and beam information, however, such information in the cell switch command does not match any candidate configuration. For example, cell 2 / beam 2-1 is indicated in the cell switch command, but cell 2 is not part of the candidate configuration. Or in another case, beam 2-1 is not part of the candidate configuration.

[0191] UE might report this, i.e., an indication about that, UE receives a cell switch command including a target cell and beam information that does not match any candidate configuration, to network in the failure report information to network to enable network to be aware of this abnormal LTM configuration and trigger.

[0192] 5.5 The RACH information UE reports to network

[0193] In one example, UE reports the RACH related information to network, in a RACH-based LTM procedure, to indicate to network that there might be issues for the RACH related information that causes the LTM cell switch failure.

[0194] - RACH type, CFRA or CBRA.

[0195] - Random Access Preamble for the CFRA.

[0196] - SS / PBCH index that is used to determine the RACH occasion for the PRACH transmission of the CFRA Resources.

[0197] - PRACH Mask index which indicates the RACH occasion (s) associated with the SS / PBCH indicated by "SS / PBCH index" for the PRACH transmission of the CFRA Resources.

[0198] - indication of whether SUL (Supplementary Uplink) or NUL (Normal Uplink) is used as the UL carrier to transmit the PRACH of the contention-free Random Access Resources.

[0199] 5.6 TA related information

[0200] For a failure LTM cell switch, the failure might be due to issues happening during the RACH-less LTM procedure. The detailed failure cause could be the UL sync procedure. To facilitate network to spot the issues, UE might report the early UL sync related information to network, which includes at least one of the following information:

[0201] - How UE obtain the TA value, i.e., the method UE obtain its TA value for the target, e.g., UE based or network based.

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

[0203] - Early UL sync configuration, which includes, the frequency information, and numerology and BWP information, for the measured candidate cell.

[0204] For LTM procedure and for the TA value UE obtains itself (i.e., UE based early UL synchronization) , UE maintains such TA without keeping a validity timer that is used to check the validity of the TA value, therefore the TA value maintained by UE might be out of date, and is not suitable for the coming LTM cell switch. However, network might not be aware of such case, and might still trigger the LTM cell switch before UE is able to update the TA value. It is therefore beneficial for UE to report the how long UE has maintained the TA (from UE obtains the TA value in the latest early UL synchronization, to the moment UE receives the cell switch command from network) .

[0205] In one example, the duration, from UE obtains the TA value in the latest early UL synchronization, to the moment UE receives the cell switch command from network, is indicated to network in a failure report information for the corresponding case.

[0206] 5.7 Subsequent LTM record

[0207] Network might need to record the LTM track for one subsequent LTM procedure, to have a better understanding of UE mobility and subsequent LTM configuration, e.g., to make better decisions on future subsequent LTM configuration that minimizes user plane interruptions, or balance between overhead and user plane interruptions.

[0208] In one example, with network configuration which enables UE to record its subsequent LTM track, UE updates its subsequent LTM track and report to network upon network request. The track is a list of the following:

[0209] - Cell x, beam x-i, time spent in the cell and beam combination, UE location, and L1 measurement upon LTM cell switch.

[0210] - Cell y, beam y-j, time spent in the cell and beam combination, UE location, and L1 measurement upon LTM cell switch.

[0211] - …

[0212] - Cell z, beam z-k, time spent in the cell and beam combination, UE location, and L1 measurement upon LTM cell switch.

[0213] The list is with a maximum length, which maintains the track of UE’s mobility history of the subsequent LTM procedure.

[0214] In some embodiments, the track includes an indication that this record is from a subsequent LTM procedure.

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

[0216] If it is a result of an LTM recovery, UE records also the cell / beam information from network in the cell switch command.

[0217] VII. Embodiment 6

[0218] Embodiment 6 describes subsequent LTM. In one example, UE indicates to network that a failure report or a sub-optimal success report is about a subsequent LTM. Based on such indication, network may request the report from UE, in case the report might be over-written at UE side due to the frequently updated report for subsequent LTM.

[0219] VIII. Embodiment 7

[0220] Embodiment 7 describes network interfaces.

[0221] An example network interface is shown in FIG. 9. The SON related information UE reports to network for the LTM procedure, shall be transferred between gNB-CU and gNB-DU, to enable gNB-DU’s awareness of the LTM mobility related optimization. For example, the lower layer configuration of candidate configuration is decided by the gNB-DU2 that the target cell belongs to. Meanwhile, the cell switch decision and command comes from the source gNB-DU1.

[0222] For the case of inter-gNB LTM procedure (i.e., the target cell of the candidate cells in a LTM procedure can belong to another gNB) , the UE reported information should be transferred from the gNB-CU2 (that controls other cells) to gNB-CU1 (that controls the source cell) , to enable the source cell to optimize the LTM procedure.

[0223] The UE reported information on SON for LTM, is transferred between two gNB.

[0224] The UE reported information on SON for LTM is transferred from gNB-CU to gNB-DU.

[0225] FIG. 10 is an example flowchart for transmitting a failure report information. Operation 1002 includes transmitting, by a wireless device, a failure report information on a mobility robustness optimization for a layer 1 or layer 2 triggered mobility (LTM) . In some embodiments, the method can be implemented according to Embodiments 1-7. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

[0226] In some embodiments, the failure report information includes at least one of the following: an indication of a subsequent LTM; a first time duration from when a last LTM cell switch is triggered to when a LTM cell switch failure or a radio link failure (RLF) occurs; a second time duration between a latest LTM  configuration and a LTM trigger; a third time duration from when a LTM cell switch is triggered to when a first beam failure occurs; a source cell or beam information; a failed cell or beam information to identify in which cell or beam a radio link failure (RLF) occurs or ends; a cell or beam information in a cell switch command; a cell or beam information at which a wireless device successfully re-establishes a radio resource control (RRC) connection; a LTM recovery cell or beam information if a LTM recovery is executed after a cell selection procedure; a LTM candidate cell or beam configuration including a transmission configuration indicator (TCI) state list of each candidate configuration; a handover (HO) type that is carried out by a wireless device, where the handover type includes at least one of a normal HO, a conditional HO (CHO) , or a LTM; a configured HO type including at least one of a LTM or a CHO configured by a network device; an indication that a wireless device receives a cell switch command including a target cell or beam information that does not match any candidate configuration; a layer 1 measurement result; an indication of a cause to a LTM cell switch failure; a random access channel (RACH) -related information for a LTM cell switch; or a RACH-less LTM-related information.

[0227] In some embodiments, the LTM cell switch failure includes at least one of a RACH failure or a RACH-less failure.

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

[0229] In some embodiments, the RACH-less LTM-related information includes at least one of the following: how a wireless device obtains a timing advance (TA) value for a target; a TA value for a target cell; an early uplink (UL) synchronization configuration including at least one of a frequency information, a numerology, or a bandwidth part (BWP) information for a measured candidate cell; or how long a wireless device has maintained a TA value if the TA value is measured by a wireless-device-based method.

[0230] In some embodiments, a network device compares the first time duration with a local variable T1 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is early based on: the first time duration is smaller than T1; and after the first time duration, a wireless device selects an original cell or beam.

[0231] In some embodiments, a network device compares the first time duration with a local variable T1 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is a right-cell wrong-beam case based on: the first time duration is smaller than T1; a LTM cell switch failure occurs; after the LTM cell switch failure, a wireless device selects a cell in a cell switch command from the network device; and a beam selected by the wireless device does not match a beam indicated in the cell switch command.

[0232] In some embodiments, a network device compares the first time duration with a local variable T1 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is a wrong-cell case based on: the first time duration is smaller than T1; and after a LTM cell switch failure, a wireless device selects a cell that is neither a cell in a cell switch command from the network device nor a source cell.

[0233] In some embodiments, a network device compares the first time duration with a local variable T1 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is late based on: the first time duration is greater than T1; and after a LTM cell switch failure, a wireless device selects a cell that is not a source cell.

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

[0235] FIG. 11 is an example flowchart for transmitting a sub-optimal success mobility report information. Operation 1102 includes updating, by a wireless device and based on a condition being met, a sub-optimal success mobility report information on a mobility robustness optimization for a layer 1 or layer 2 triggered mobility (LTM) . Operation 1104 includes transmitting, by the wireless device, the sub-optimal success mobility report information. In some embodiments, the method can be implemented according to Embodiments 1-7. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

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

[0237] In some embodiments, the sub-optimal success mobility report information includes at least one of the following: a time duration from when a LTM cell switch is triggered to when a first beam failure occurs; an indication that a beam failure occurs shortly after a LTM cell switch procedure and a beam failure recovery (BFR) is successful; an indication that a BFR is successful following a beam failure, where a LTM is configured and not triggered; a condition that triggers a report; a source cell or beam information; a cell or beam information in a cell switch command; a cell or beam information in which a wireless device’s BFR is successfully executed; a layer 1 measurement result; a LTM candidate cell or beam configuration including a transmission configuration indicator (TCI) state list of each candidate configuration; a handover (HO) type that is carried out by a wireless device, where the HO type includes at least one of a normal HO, a conditional HO (CHO) , or a LTM; a configured HO type including at least one of a LTM or a CHO; a random access channel (RACH) type of a LTM including a RACH-less LTM or a RACH-based LTM; a RACH configuration including at least one of a contention free random access (CFRA) configuration or a contention-based random access (CBRA) configuration; a RACH resource; how a wireless device obtains a timing advance (TA) value for a target, where the obtaining is either wireless-device-based or network-based; whether an early downlink (DL) synchronization is done for a LTM cell switch procedure for a target cell; whether an early uplink (UL) synchronization is done for a LTM cell switch procedure for a target cell; or whether a TA value is available for a target cell.

[0238] In some embodiments, a network device compares the time duration with a local variable T3 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is a right-cell wrong-beam case based on: the time duration is smaller than T3; and after a BFR is successful, a wireless device connects to the network device through a configured cell in a cell switch command but in a different beam from the cell switch command.

[0239] In some embodiments, the sub-optimal success mobility report information is transmitted upon receiving a request from a network device.

[0240] FIG. 12 is an example flowchart for transmitting a LTM track information. Operation 1202 includes transmitting, by a wireless device, a list of subsequent layer 1 or layer 2 triggered mobility (LTM) track information, where the subsequent LTM track information is used to update a LTM mobility history information. In some embodiments, the method can be implemented according to Embodiments 1-7. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

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

[0242] In some embodiments, the list of subsequent LTM track information is transmitted upon receiving a request from a network device.

[0243] In some embodiments, the subsequent LTM track information includes at least one of the following: an indication to indicate that the subsequent LTM track information is for a subsequent LTM; a cell or beam information; a time spent in a cell and beam combination; a location information of the wireless device; an indication of whether a successful LTM is based on a LTM recovery or a cell switch command from a network device, where if the successful LTM is based on a LTM recovery, the wireless device records a cell or beam information in the cell switch command from the network device; or a layer 1 measurement upon a LTM cell switch.

[0244] FIG. 13 is an example flowchart for receiving a LTM information by a distributed unit (DU) of a network device. Operation 1302 includes receiving, by a distributed unit (DU) of a network device, at least one of the following information on a self-organizing network for a layer 1 or layer 2 triggered mobility (LTM) : a failure report information; a sub-optimal success mobility report information; or a subsequent LTM track information. In some embodiments, the method can be implemented according to Embodiments 1-7. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

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

[0246] FIG. 14 is an example flowchart for receiving a LTM information by a network device. Operation 1402 includes receiving, by a network device, at least one of the following information on a self-organizing network for a layer 1 or layer 2 triggered mobility (LTM) : a failure report information; a sub-optimal success mobility report information; or a subsequent LTM track information. In some embodiments, the method can be implemented according to Embodiments 1-7. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

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

[0248] In some embodiments, the failure report information received includes at least one of the following: an indication of a subsequent LTM; a first time duration from when a last LTM cell switch is triggered to when a LTM cell switch failure or a radio link failure (RLF) occurs; a second time duration between a latest LTM configuration and a LTM trigger; a source cell or beam information; a third time duration from when a LTM cell switch is triggered to when a first beam failure occurs; a failed cell or beam information to identify in which cell or beam a radio link failure (RLF) occurs or ends; a cell or beam information in a cell switch command; a cell  or beam information at which a wireless device successfully re-establishes a radio resource control (RRC) connection; a LTM recovery cell or beam information if a LTM recovery is executed after a cell selection procedure; a LTM candidate cell or beam configuration including a transmission configuration indicator (TCI) state list of each candidate configuration; a handover (HO) type that is carried out by a wireless device, where the handover type includes at least one of a normal HO, a conditional HO (CHO) , or a LTM; a configured HO type including at least one of a LTM or a CHO configured by a network device; an indication that a wireless device receives a cell switch command including a target cell or beam information that does not match any candidate configuration; a layer 1 measurement result; an indication of a cause to a LTM cell switch failure; a random access channel (RACH) -related information for a LTM cell switch; or a RACH-less LTM-related information.

[0249] In some embodiments, the sub-optimal success mobility report information received includes at least one of the following: a time duration from when a LTM cell switch is triggered to when a first beam failure occurs; an indication that a beam failure occurs shortly after a LTM cell switch procedure and a beam failure recovery (BFR) is successful; an indication that a BFR is successful following a beam failure, where a LTM is configured and not triggered; a condition that triggers a report; a source cell or beam information; a cell or beam information in a cell switch command; a cell or beam information in which a wireless device’s BFR is successfully executed; a layer 1 measurement result; a LTM candidate cell or beam configuration including a transmission configuration indicator (TCI) state list of each candidate configuration; a handover (HO) type that is carried out by a wireless device, where the HO type includes at least one of a normal HO, a conditional HO (CHO) , or a LTM; a configured HO type including at least one of a LTM or a CHO; a random access channel (RACH) type of a LTM including a RACH-less LTM or a RACH-based LTM; a RACH configuration including at least one of a contention free random access (CFRA) configuration or a contention-based random access (CBRA) configuration; a RACH resource; how a wireless device obtains a timing advance (TA) value for a target, where the obtaining is either wireless-device-based or network-based; whether an early downlink (DL) synchronization is done for a LTM cell switch procedure for a target cell; whether an early uplink (UL) synchronization is done for a LTM cell switch procedure for a target cell; or whether a TA value is available for a target cell.

[0250] In some embodiments, the subsequent LTM track information received includes at least one of the following: an indication to indicate that the subsequent LTM track information is for a subsequent LTM; a cell or beam information; a time spent in a cell and beam combination; a location information of the wireless device; an indication of whether a successful LTM is based on a LTM recovery or a cell switch command from a network device, where if the successful LTM is based on a LTM recovery, the wireless device records a cell or beam information in the cell switch command from the network device; or a layer 1 measurement upon a LTM cell switch.

[0251] FIG. 15 shows an example block diagram of a hardware platform 1500 that may be a part of a network device (e.g., a base station (BS) , a transmission and reception point (TRP) , or a 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 having instructions stored thereupon. The instructions upon execution by the processor 1510 configure the hardware platform 1500 to perform the operations described in FIGS. 1-14 and in the various embodiments described in this patent document. The transmitter 1515 transmits or sends information or data to another device. For example, a network device transmitter can send a message to a user equipment. The receiver 1520 receives information or data transmitted or sent by another device. For example, a user equipment can receive a message from a network device. For example, a UE, a wireless device, or a network device, as described in the present document, may be implemented using the hardware platform 1500.

[0252] The implementations as discussed above will apply to a wireless communication. FIG. 16 shows an example of a wireless communication system (e.g., a 5G or NR cellular network) that includes a base station 1620 and one or more user equipment (UE) 1611, 1612, and 1613. In some embodiments, the UEs access the BS (e.g., the network) using a communication link to the network (sometimes called uplink direction, as depicted by dashed arrows 1631, 1632, 1633) , which then enables subsequent communication (e.g., shown in the direction from the network to the UEs, sometimes called downlink direction, shown by arrows 1641, 1642, 1643) from the BS to the UEs. In some embodiments, the BS sends information to the UEs (sometimes called downlink direction, as depicted by arrows 1641, 1642, 1643) , which then enables subsequent communication (e.g., shown in the direction from the UEs to the BS, sometimes called uplink direction, shown by dashed arrows 1631, 1632, 1633) from the UEs to the BS. The UE may be, for example, a smartphone, a tablet, a mobile computer, a machine to machine (M2M) device, an Internet of Things (IoT) device, and so on. The UEs described in the present document may be communicatively coupled to the base station 1620 depicted in FIG. 16.

[0253] It will be appreciated by one of skill in the art that the present patent document discloses methods that, among other benefits, improve the quality of LTM cell switch and handover. The disclosed methods include reporting sub-optimal lower-layer triggered mobility (LTM) cell switch procedures and / or failure report information to the network.

[0254] Some of the embodiments described herein are described in the general context of methods or processes, which 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, executed by computers in networked environments. A 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 discs (CDs) , digital versatile discs (DVD) , etc. Therefore, the computer-readable media can include a non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.  Computer-or processor-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.

[0255] Some of the disclosed embodiments can be implemented as devices or modules using hardware circuits, software, or combinations thereof. For example, a hardware circuit implementation can include discrete analog and / or digital components that are, for example, integrated as part of a printed circuit board. Alternatively, or additionally, the disclosed components or modules can be implemented as an Application Specific Integrated Circuit (ASIC) and / or as a Field Programmable Gate Array (FPGA) device. Some implementations may additionally or alternatively include a digital signal processor (DSP) that is a specialized microprocessor with an architecture optimized for the operational needs of digital signal processing associated with the disclosed functionalities of this application. Similarly, the various components or sub-components within each module may be implemented in software, hardware, or firmware. The connectivity between the modules and / or components within the modules may be provided using any one of the connectivity methods and media that is known in the art, including, but not limited to, communications over the Internet, wired, or wireless networks using the appropriate protocols.

[0256] While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

[0257] Only a few implementations and examples are described, and other implementations, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

1.A method of wireless communication, comprising:transmitting, by a wireless device, a failure report information on a mobility robustness optimization for a layer 1 or layer 2 triggered mobility (LTM) .2.The method of claim 1, wherein the failure report information comprises at least one of the following:an indication of a subsequent LTM;a first time duration from when a last LTM cell switch is triggered to when a LTM cell switch failure or a radio link failure (RLF) occurs;a second time duration between a latest LTM configuration and a LTM trigger;a third time duration from when a LTM cell switch is triggered to when a first beam failure occurs;a source cell or beam information;a failed cell or beam information to identify in which cell or beam a radio link failure (RLF) occurs or ends;a cell or beam information in a cell switch command;a cell or beam information at which a wireless device successfully re-establishes a radio resource control (RRC) connection;a LTM recovery cell or beam information if a LTM recovery is executed after a cell selection procedure;a LTM candidate cell or beam configuration comprising a transmission configuration indicator (TCI) state list of each candidate configuration;a handover (HO) type that is carried out by a wireless device, wherein the handover type comprises at least one of a normal HO, a conditional HO (CHO) , or a LTM;a configured HO type comprising at least one of a LTM or a CHO configured by a network device;an indication that a wireless device receives a cell switch command comprising a target cell or beam information that does not match any candidate configuration;a layer 1 measurement result;an indication of a cause to a LTM cell switch failure;a random access channel (RACH) -related information for a LTM cell switch; ora RACH-less LTM-related information.3.The method of claim 2, wherein the LTM cell switch failure comprises at least one of a RACH failure or a RACH-less failure.4.The method of claim 2 or 3, wherein the RACH-related information for the LTM cell switch comprises at least one of the following:a RACH type comprising at least one of a contention free random access (CFRA) or a contention-based random access (CBRA) ;a random access preamble for a CFRA;a synchronization signal / physical broadcast channel (SS / PBCH) index that is used to determine a RACH occasion (RO) for a physical random access channel (PRACH) transmission of a CFRA resource;a PRACH mask index that indicates a RO associated with a SS / PBCH indicated by a SS / PBCH index for a PRACH transmission of a CFRA resource; oran indication of whether a supplementary uplink (SUL) or a normal uplink (NUL) is used as an uplink (UL) carrier to transmit a PRACH of a CFRA resource.5.The method of any of claims 2-4, wherein the RACH-less LTM-related information comprises at least one of the following:how a wireless device obtains a timing advance (TA) value for a target;a TA value for a target cell;an early uplink (UL) synchronization configuration comprising at least one of a frequency information, a numerology, or a bandwidth part (BWP) information for a measured candidate cell; orhow long a wireless device has maintained a TA value if the TA value is measured by a wireless-device-based method.6.The method of any of claims 2-5, wherein a network device compares the first time duration with a local variable T1 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is early based on:the first time duration is smaller than T1; andafter the first time duration, a wireless device selects an original cell or beam.7.The method of any of claims 2-5, wherein a network device compares the first time duration with a local variable T1 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is a right-cell wrong-beam case based on:the first time duration is smaller than T1;a LTM cell switch failure occurs;after the LTM cell switch failure, a wireless device selects a cell in a cell switch command from the network device; anda beam selected by the wireless device does not match a beam indicated in the cell switch command.8.The method of any of claims 2-5, wherein a network device compares the first time duration with a local variable T1 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is a wrong-cell case based on:the first time duration is smaller than T1; andafter a LTM cell switch failure, a wireless device selects a cell that is neither a cell in a cell switch command from the network device nor a source cell.9.The method of any of claims 2-5, wherein a network device compares the first time duration with a local variable T1 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is late based on:the first time duration is greater than T1; andafter a LTM cell switch failure, a wireless device selects a cell that is not a source cell.10.The method of any of claims 6-9, wherein the local variable T1 is a threshold configured for a LTM specifically.11.A method of wireless communication, comprising:updating, by a wireless device and based on a condition being met, a sub-optimal success mobility report information on a mobility robustness optimization for a layer 1 or layer 2 triggered mobility (LTM) ; andtransmitting, by the wireless device, the sub-optimal success mobility report information.12.The method of claim 11, wherein the condition comprises at least one of the following:a LTM cell switch is successfully executed;a beam failure occurs and a beam failure recovery (BFR) is successfully executed after a LTM cell switch procedure;a time duration from when a last LTM cell switch is triggered to when a first beam failure occurs is smaller than a threshold T2 configured by the network device;a LTM is configured but not triggered;a beam failure occurs and a BFR is successfully executed before a LTM cell switch is triggered;a LTM is configured but another handover (HO) type comprising at least one of a normal HO or a conditional HO (CHO) is executed;a CHO is configured but another HO type comprising a LTM or a normal HO is executed;a selected beam of a cell in a random access channel (RACH) -based LTM is not included in a candidate configuration for the cell;a selected beam of a cell in a BFR after a successful LTM cell switch is not included in a candidate configuration for the cell; orif a ratio between a value of an elapsed time of a timer T304 for a LTM procedure and a value of the timer T304 configured for a wireless device by the network device is greater than a configured threshold R1.13.The method of claim 11 or 12, wherein the sub-optimal success mobility report information comprises at least one of the following:a time duration from when a LTM cell switch is triggered to when a first beam failure occurs;an indication that a beam failure occurs shortly after a LTM cell switch procedure and a beam failure recovery (BFR) is successful;an indication that a BFR is successful following a beam failure, wherein a LTM is configured and not triggered;a condition that triggers a report;a source cell or beam information;a cell or beam information in a cell switch command;a cell or beam information in which a wireless device’s BFR is successfully executed;a layer 1 measurement result;a LTM candidate cell or beam configuration comprising a transmission configuration indicator (TCI) state list of each candidate configuration;a handover (HO) type that is carried out by a wireless device, wherein the HO type comprises at least one of a normal HO, a conditional HO (CHO) , or a LTM;a configured HO type comprising at least one of a LTM or a CHO;a random access channel (RACH) type of a LTM comprising a RACH-less LTM or a RACH-based LTM;a RACH configuration comprising at least one of a contention free random access (CFRA) configuration or a contention-based random access (CBRA) configuration;a RACH resource;how a wireless device obtains a timing advance (TA) value for a target, wherein the obtaining is either wireless-device-based or network-based;whether an early downlink (DL) synchronization is done for a LTM cell switch procedure for a target cell;whether an early uplink (UL) synchronization is done for a LTM cell switch procedure for a target cell; orwhether a TA value is available for a target cell.14.The method of claim 13, wherein a network device compares the time duration with a local variable T3 configured by an operations, administration, and maintenance (OAM) and determines that a LTM cell switch is a right-cell wrong-beam case based on:the time duration is smaller than T3; andafter a BFR is successful, a wireless device connects to the network device through a configured cell in a cell switch command but in a different beam from the cell switch command.15.The method of any of claims 11-14, wherein the sub-optimal success mobility report information is transmitted upon receiving a request from a network device.16.A method of wireless communication, comprising:transmitting, by a wireless device, a list of subsequent layer 1 or layer 2 triggered mobility (LTM) track information, wherein the subsequent LTM track information is used to update a LTM mobility history information.17.The method of claim 16, wherein the wireless device is configured with a subsequent LTM by a network device.18.The method of claim 16 or 17, wherein the list of subsequent LTM track information is transmitted upon receiving a request from a network device.19.The method of any of claims 16-18, wherein the subsequent LTM track information comprises at least one of the following:an indication to indicate that the subsequent LTM track information is for a subsequent LTM;a cell or beam information;a time spent in a cell and beam combination;a location information of the wireless device;an indication of whether a successful LTM is based on a LTM recovery or a cell switch command from a network device, wherein if the successful LTM is based on a LTM recovery, the wireless device records a cell or beam information in the cell switch command from the network device; ora layer 1 measurement upon a LTM cell switch.20.A method of wireless communication, comprising:receiving, by a distributed unit (DU) of a network device, at least one of the following information on a self-organizing network for a layer 1 or layer 2 triggered mobility (LTM) :a failure report information;a sub-optimal success mobility report information; ora subsequent LTM track information.21.The method of claim 20, wherein the at least one of the following information is received from a centralized unit (CU) of the network device.22.A method of wireless communication, comprising:receiving, by a network device, at least one of the following information on a self-organizing network for a layer 1 or layer 2 triggered mobility (LTM) :a failure report information;a sub-optimal success mobility report information; ora subsequent LTM track information.23.The method of claim 22, wherein the at least one of the following information is received from another network device.24.The method of any of claims 20-23, wherein the failure report information comprises at least one of the following:an indication of a subsequent LTM;a first time duration from when a last LTM cell switch is triggered to when a LTM cell switch failure or a radio link failure (RLF) occurs;a second time duration between a latest LTM configuration and a LTM trigger;a third time duration from when a LTM cell switch is triggered to when a first beam failure occurs;a source cell or beam information;a failed cell or beam information to identify in which cell or beam a radio link failure (RLF) occurs or ends;a cell or beam information in a cell switch command;a cell or beam information at which a wireless device successfully re-establishes a radio resource control (RRC) connection;a LTM recovery cell or beam information if a LTM recovery is executed after a cell selection procedure;a LTM candidate cell or beam configuration comprising a transmission configuration indicator (TCI) state list of each candidate configuration;a handover (HO) type that is carried out by a wireless device, wherein the handover type comprises at least one of a normal HO, a conditional HO (CHO) , or a LTM;a configured HO type comprising at least one of a LTM or a CHO configured by a network device;an indication that a wireless device receives a cell switch command comprising a target cell or beam information that does not match any candidate configuration;a layer 1 measurement result;an indication of a cause to a LTM cell switch failure;a random access channel (RACH) -related information for a LTM cell switch; ora RACH-less LTM-related information.25.The method of any of claims 20-24, wherein the sub-optimal success mobility report information comprises at least one of the following:a time duration from when a LTM cell switch is triggered to when a first beam failure occurs;an indication that a beam failure occurs shortly after a LTM cell switch procedure and a beam failure recovery (BFR) is successful;an indication that a BFR is successful following a beam failure, wherein a LTM is configured and not triggered;a condition that triggers a report;a source cell or beam information;a cell or beam information in a cell switch command;a cell or beam information in which a wireless device’s BFR is successfully executed;a layer 1 measurement result;a LTM candidate cell or beam configuration comprising a transmission configuration indicator (TCI) state list of each candidate configuration;a handover (HO) type that is carried out by a wireless device, wherein the HO type comprises at least one of a normal HO, a conditional HO (CHO) , or a LTM;a configured HO type comprising at least one of a LTM or a CHO;a random access channel (RACH) type of a LTM comprising a RACH-less LTM or a RACH-based LTM;a RACH configuration comprising at least one of a contention free random access (CFRA) configuration or a contention-based random access (CBRA) configuration;a RACH resource;how a wireless device obtains a timing advance (TA) value for a target, wherein the obtaining is either wireless-device-based or network-based;whether an early downlink (DL) synchronization is done for a LTM cell switch procedure for a target cell;whether an early uplink (UL) synchronization is done for a LTM cell switch procedure for a target cell; orwhether a TA value is available for a target cell.26.The method of any of claims 20-25, wherein the subsequent LTM track information comprises at least one of the following:an indication to indicate that the subsequent LTM track information is for a subsequent LTM;a cell or beam information;a time spent in a cell and beam combination,a location information of a wireless device;an indication of whether a successful LTM is based on a LTM recovery or a cell switch command from the network device, wherein if the successful LTM is based on a LTM recovery, the wireless device records a cell or beam information in the cell switch command from the network device; ora layer 1 measurement upon a LTM cell switch.27.An apparatus for wireless communication, comprising a processor, wherein the processor is configured to implement a method recited in any one or more of claims 1-26.28.A computer readable program storage medium having code stored thereon, the code, when executed by a processor, causing the processor to implement a method recited in any one or more of claims 1-26.

Images