Failure information reporting

Abstract

The present disclosure relates to a solution for failure information reporting, wherein a first network device 110 (e.g. base station, gNB, or source node) transmits to the second network device 120 (e.g. BS, gNB, or target node), a first message 202 for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of terminal device 130 based on determining that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device. The first network device receives a second message 204 including the LBT failure information from the second network device. In this way, the second network device can identify the situation when the LBT failure information shall be sent. The first network device serves a source cell for the handover, and the second network device serves a target cell for the handover, wherein: the terminal device reconnects to the source cell after at least one radio link failure (RLF) or handover failure (HOF); or the terminal device reconnects, after the at least one RLF or HOF, to a third cell served by the first network device or a third network device.

Description

FIELD

[0001] Example embodiments of the present disclosure generally relate to the field of communications, and in particular, to devices, methods, apparatuses, and a computer readable storage medium for failure information reporting. BACKGROUND

[0002] A communication network can be seen as a facility that enables communications between two or more communication devices, or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network. A communication device may be provided with a service by an application server.

[0003] Such communication networks operate in according with standards such as those provided by 3GPP (Third Generation Partnership Project) or ETSI (European Telecommunications Standards Institute). Examples of standards are the so-called 5G (5th Generation) standards or other standards provided by 3GPP. SUMMARY

[0004] In general, example embodiments of the present disclosure provide a solution for failure information reporting, especially for cross-node downlink (DL) listen before talk (LBT) failure information reporting.

[0005] In a first aspect, there is provided a first network device. The first network device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the first network device at least to transmit to the second network device, a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device based on determining that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device. The first network device is further caused to receive a second message including the LBT failure information from the second network device.

[0006] In a second aspect, there is provided a second network device. The second network device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the second network device at least to receive, from a first network device, a first message after a handover of a terminal device served by the first network device failed. The first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device. The second network device is further caused to transmit a second message including the LBT failure information to the first network device based on receiving the first message.

[0007] In a third aspect, there is provided a method. The method comprises based on determining that a handover of a terminal device served by a first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device, transmitting to the second network device, a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device. The method further comprises receiving, from the second network device, a second message including the LBT failure information.

[0008] In a fourth aspect, there is provided a method. The method comprises receiving, from a first network device, a first message after a handover of a terminal device served by the first network device failed. The first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by a second network device during the handover of the terminal device. The method further comprises based on receiving the first message, transmitting, to the first network device, a second message including the LBT failure information.

[0009] In a fifth aspect, there is provided an apparatus. The apparatus comprises means for based on determining that a handover of a terminal device served by a first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device, transmitting to the second network device, a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device. The apparatus further comprises means for receiving, from the second network device, a second message including the LBT failure information.

[0010] In a sixth aspect, there is provided an apparatus. The apparatus comprises means for receiving, from a first network device, a first message after a handover of a terminal device served by the first network device failed. The first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by a second network device during the handover of the terminal device. The apparatus further comprises means for based on receiving the first message, transmitting, to the first network device, a second message including the LBT failure information.

[0011] In a seventh aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method according to any one of the third aspect to fourth aspect.

[0012] In an eighth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus at least to perform at least the method according to according to any one of the third aspect to fourth aspect.

[0013] In a ninth aspect, there is provided a first network device. The first network device comprises transmitting circuitry configured to, based on determining that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device, transmitting to the second network device, a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device. The first network device further comprises receiving circuitry configured to receive, from the second network device, a second message including the LBT failure information.

[0014] In a tenth aspect, there is provided a second network device. The second network device comprises receiving circuitry configured to receive, from a first network device, a first message after a handover of a terminal device served by the first network device failed. The first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device. The second network device comprises transmitting circuitry configured to, based on receiving the first message, transmit, to the first network device, a second message including the LBT failure information.

[0001] It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some example embodiments will now be described with reference to the accompanying drawings, in which:

[0003] FIG. 1A illustrates an example of a network environment in which example embodiments of the present disclosure can be implemented;

[0004] FIG. IB illustrates an example of a network environment associated with embodiments of the present disclosure;

[0005] FIG. 2 illustrates a flow chart of method according to some embodiments of the present disclosure;

[0006] FIG. 3 illustrates a detailed example of interactions between devices in accordance with some example embodiments of the present disclosure;

[0007] FIG. 4 illustrates another detailed example of interactions between devices in accordance with some example embodiments of the present disclosure;

[0008] FIG. 5 illustrates a flowchart of a method performed by an apparatus in accordance with some example embodiments of the present disclosure;

[0009] FIG. 6 illustrates a flowchart of a method performed by an apparatus in accordance with some example embodiments of the present disclosure;

[0010] FIG. 7 illustrates a simplified block diagram of a device that is suitable for implementing some example embodiments of the present disclosure; and

[0011] FIG. 8 illustrates a block diagram of an example of a computer readable medium in accordance with some example embodiments of the present disclosure.

[0012] Throughout the drawings, the same or similar reference numerals represent the same or similar elements. DETAILED DESCRIPTION

[0013] Principles of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

[0014] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0015] References in the present disclosure to “one embodiment,” “an embodiment,” “an example embodiment,” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0016] It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0017] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and / or “including”, when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0018] As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuits (such as in analog and / or digital circuits) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software (e.g., firmware); and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor!s) or a portion of a microprocessor(s), that requires software (for example, firmware) for operation, but the software may not be present when it is not needed for operation.

[0019] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0020] As used herein, the term “cellular network” refers to a network operating in accordance with any suitable radio access technology defined by standards, such as Long Term Evolution (LTE), LTE-Advanced (LTE-A), new radio Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device of a cellular network may be performed according to any suitable communication protocols, including, but not limited to, the fourth generation (4G), 4.5G, the future fifth generation (5G) communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various cellular networks. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0021] As used herein, the term “network device” refers to any device in a cellular network via which a terminal device accesses a data network and receives services exposed by other network devices of the cellular network. In some examples, a network device may comprise or implement a network function of a 5th generation communication system (5GS) (e.g., a core network) of a cellular network. In some examples, the network devices may be located at the RAN of the 5GS. The network device may be part of a satellite, a base station (BS) or an access point (AP), for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), a NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, a low power node such as a femto, a pico node, and so forth, depending on the applied terminology and technology. A gNB may include a centralized unit CU and one or more distributed DUs. Femto and Pico nodes are small base stations with a small coverage area.

[0022] The term “terminal device” refers to a device of a communication system of a cellular network, such as a 5th generation communication system (5GS) that may be capable of wireless (e.g., radio) communication with a NR-RAN of the 5GS). By way of example rather than limitation, a terminal device may also be referred to as a wireless communication device, user equipment (UE), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). Examples of a terminal device include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehiclemounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, wireless customer-premises equipment (CPE), an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (for example, remote surgery), an industrial device and applications (for example, a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. In the following description, the terms “terminal device”, “communication device”, “terminal”, “user equipment” and “UE” may be used interchangeably.

[0023] One of focused self-organizing networks (SON) use cases there was Mobility Robustness Optimization (MRO), which has been introduced already with 4G / LTE to optimize the handover timing for each cell-pair border individually with the so-called Cell-Individual Offset (CIO) which is to be tweaked.

[0024] NR-U has to follow the rules like listen-before-talk (LBT), which have been established to allow fair cooperation of various radio access techniques (RATs) in unlicensed bands, e.g. with Wireless LAN (WLAN). In contrast to operation in licensed bands, each event-based radio transmission for signaling or reporting has to undergo the LBT procedure and faces a channel access or transmission deferral caused by detected channel occupation which is called by 3GPP PHY “LBT failure” as it can be seen as LBT caused transmission failure, although it is actually not a failure but the outcome of the must-have LBT feature.

[0025] Since MRO is optimizing the handover timing, this LBT caused deferral of mobility related signaling messages might harmfully impact the MRO procedure. MRO enhancements needed for NR-U operation have been considered. In order to get information about the LBT-caused deferrals, it was agreed to log the “number of LBT failures” belonging to HO-related signaling messages which are exchanged between UE and network during the handover procedure, and that this logged LBT failure information will be retrievable in case of RLF / HOF. The UL LBT failure information is collected in UE and will be provided with the RLF-report. The DL LBT failure information might be collected both in the source node and in the target. All those distributed information about LBT related deferrals need to be brought together to judge the impact of LBT on the handover timing.

[0026] Since the source node triggers the handover, source node (or SON / MRO instance hosted by source node, respectively) is seen as accountable for the failure analysis and MRO counter creation of Too Late Handover (TLH), Too Early Handover (TEH), Handover to Wrong Cell (HWC), which are later - after certain statistical significance - triggering the cellborder specific handover parameter re-adjustment. Thus, the DL LBT failure information collected in the target node needs to be brought to source node.

[0027] The logging of the DL LBT failures is triggered along with handover preparation procedure with an IE added to HANDOVER REQUEST message, and it is implied that reporting should happen only in case of HOF or RLE at the target side - but when exactly this logged information is to be reported by means of the ACCESS AND MOBILITY INDICATION message is not specified.

[0028] A dedicated trigger criterion is missing. The ACCESS AND MOBILITY INDICATION message is a unidirectional message which needs a trigger condition, which is typically the reception of a Successful Handover Report (SHR) received from UE at target node after successful handover completion. And the ACCESS AND MOBILITY INDICATION message is used to convey this SHR to the source node where handover was initiated and where MRO instance for problem analysis is located.

[0029] In case of MRO for NR-U, this new NR-U specific information about DL LBT failures occurred during or after handover execution has to be considered and to be brought to the source node for root cause analysis. While in case of SHR the UE always successfully completes the handover and connects to target cell, where SHR is received, in case of RLF / HOF the UE could reconnect to any cell afterwards. Depending on where the UE is reconnecting after the RLF / HOF an appropriate method to convey the information from target to source node is to be initiated.

[0030] When UE reconnects to a cell hosted by the source node, the target node may not know that there was a HOF and that it shall send the ACCESS AND MOBILITY INDICATION message. Source node retrieves RLF-report and gets aware from the RLF-report variables RLF-type == hof and previousPCellld == CGHcqM global identifier) of the cell served by analyzing node, that it itself is responsible for MRO analysis. In case of MRO, all needed information would be with the responsible entity, and it would not trigger further inter-node messages for information retrieval.

[0031] But in case of MRO in NR-U, that DL LBT failure information logged at the target node is also needed for concluding MRO analysis, however a trigger criterion that and when the target node should provide that information to the analyzing source node with the agreed ACCESS AND MOBILITY INDICATION message is missing.

[0032] The problem of that un-precise specification on providing the DL LBT failure information occurs both for basic HO and CHO, since also for basic HO multiple target cells can be prepared with the HANDOVER REQUEST message, but network decides within RRCReconfiguration with sync message which target cell is to be used.

[0033] There is a problem, if several (such as N) candidates were prepared with HANDOVER REQUEST message (including DLLBT failure information request), i.e. so-called multiple preparation was employed, because all of them might trigger - together UE preparation resources release triggered by the timer expiry - the provisioning of DL LBT failure information via ACCESS AND MOBILITY INDICATION message. The problem is that N-l of these messages might be void and in vain. And the one where RACH was attempted is actually known for an explicit retrieval.

[0034] In case of CHO, there are always several candidate cells prepared, but source node is not aware of the target cell which has been chosen for handover execution. Thus, if UE fails with HOF, the failedPCellld is known as chosen target cell in the RLF-report, but the node serving the target cell could either rely on the above-mentioned implementation-specific timer solution to get the DL LBT failure information provided or rely on the HANDOVER CANCEL message which is sent to release handover preparation to the unused candidate cells. For both options, there is the same issue as above for baseline HO, namely that N-l of the triggered ACCESS AND MOBILITY INDICATION messages is void and in vain.

[0035] If the UE re-establishes in a cell hosted by target node, the target node is triggered by the RLF-report retrieval and pre-analysis to send the FAILURE INDICATION message including the RLF-report to the analyzing source node indicated by the RLF-report variables RLF-type = = hof andpreviousPCellld = = cell served by source node, that the initiating node responsible for detailed MRO analysis is to informed and the RLF-report forwarded to it via FAILURE INDICATION message.

[0036] However, a trigger criterion for sending the ACCESS AND MOBILITY INDICATION message including the DL LBT Failure Information is not directly specified, even though it might be obvious that is the same trigger as for FAILURE INDICATION message.

[0037] The related question or problem is more an optimization issue and may be a descriptive aspect in the specification with respect to trigger criterion.

[0038] In view of the above, example embodiments of the present disclosure provide a solution for failure information reporting. In the example embodiments of the present disclosure, a first network device may transmit to the second network device, a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device based on determining that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device. The first network device may receive a second message including the LBT failure information from the second network device. In this way, the second network device or target node may identify the situation when the LBT failure information (e.g., DL LBT information) needs to be sent.

[0039] FIG. 1A illustrates an example of a network environment 100A in which example embodiments of the present disclosure can be implemented. The environment 100A may be a part of a communication network and comprise a plurality of devices, such as a first network device 110, a second network device 120, a terminal device 130. As an example, the first network device 110 may be implemented as a base station (BS), a gNB, or a source node. The second network device 120 may be implemented as a base station (BS), a gNB or a target node. The terminal device 130 may be implemented as a UE device, or an access terminal device etc.

[0040] To transmit data and / or control information, the terminal device 130 may perform communications with the first network device 110 and / or the second network device 120. A link from the terminal device 130 to the first network device 110 and / or the second network device 120 is referred to as an uplink (UL), while a link from the first network device 110 and / or the second network device 120 to the terminal device 130 is referred to as a downlink (DL).

[0041] Although the first network device 110, the second network device 120, the terminal device 130 are described in the communication environment lOOAof FIG. 1 A, embodiments of the present disclosure may equally apply to any other suitable communication devices in communication with one another. That is, embodiments of the present disclosure are not limited to the exemplary scenarios of FIG. 1A. In other embodiments, the first network device 110, the second network device 120, the terminal device 130 may be any other communication devices, for example, any other wireless communication devices.

[0042] It is to be understood that the particular number of various communication devices and the particular number of various communication links as shown in FIG. 1A is for illustration purpose only without suggesting any limitations. The communication environment 100 may include any suitable number of communication devices and any suitable number of communication links for implementing embodiments of the present disclosure. In addition, it should be appreciated that there may be various wireless as well as wireline communications (if needed) among all of the communication devices.

[0043] FIG. IB illustrates an example of a network environment associated with embodiments of the present disclosure. In the network environment, lines 104 and 156 may represent cell A of the first network device 110 (which may be also referred to gNBl or a source node). Lines 168 and 170 may represent cell B of the first network device 110. A line 172 may represent cell C of the second network device 120 (which may be also referred to gNB2 or a target node). Lines 174,176 and 178 may represent cell D of the first network device 110.

[0044] When the terminal device 130 connects with cell A 104 of the first network device 110, an event for conditional handover (CHO) preparation 102 may occur. When the measurement event 102 criteria fulfilled and the terminal device may trigger reporting. At 106, this reporting may be blocked by LBT (UL LBT failures which are logged on the terminal device 130 side).

[0045] At 108, the terminal device 130 may successfully transmit the report to the first network device 110. At 158, the target candidate cells, such as Cell C of the second network device 120, may be prepared with HANDOVER REQUEST message. At 114 and 118, when the target candidate cells are prepared, the terminal device may be configured with condConfig. For example, at 114, the first network device 110 may transmit the RRCReconfiguration including conditionalReconfiguration to the terminal device 130. At 118, the terminal device 130 may transmit RRCReconfigurationComplete information to the Cell B 168 of the first network device 110. At 112 and 116, this RRC may also undergo LBT and be blocked. After the terminal device 130 is configured, it may start monitoring the measurements of candidate cell against condConfig.

[0046] If the event 122 that condConfig criterion is fulfilled for one of the candidate cells (such as Cell C 172 or Cell D 174-176 of the second network device 120), the terminal device 130 may autonomously detach from the first network device 110 and start RACH procedure to the chosen target cell and start the timer T304. In some embodiments, at 124, the RACH procedure may be blocked by LBT (such as UL LBT failures), but it may be retried until it is successful at 126.

[0047] When the second network device 120 receives signal on the RACH from the terminal device 130, it may trigger Random Access Report (RAR). At 160, the RAR may be blocked due to the DL LBT failures. At 128, the RAR may be LBT blocked and failed.

[0048] At 132, the event RLF or HOF (handover failure, HOF) occurs. The whole UL synchronization procedure with RACH and RAR may be supervised by the timer T304, and the handover may be declared as failed when the timer T304 expires. The Declaration of RLF / HOF may start the re-establishment phase supervised by timer T311.

[0049] The terminal device 130 may start re-establishment with cell search and perform RACH procedure towards best serving cell. At 134, the RACH procedure may be LBT blocked. At 136, terminal device 130 may retry to perform the RACH procedure and success. At 138, when the second network device 120 receives signal on the RACH from the terminal device 130, the second network device 120 may transmit RAR to the terminal device 130.

[0050] At 140, UL sync to the found cell D 174-176 of the second network device 120 may be successfully completed, and the actual RRCReestablishment procedure may start. At 142, the terminal device 130 may transmit a RRC Reestablishment Request to the second network device 120 which can blocked by LBT. At 144, the terminal device 130 may retry to transmit a RRC Reestablishment Request to the second network device 120 successfully.

[0051] At 146, the second network device 120 may not transmit a RRCReestablishment message to the terminal device 130 because of the LBT. At 148, the second network device 120 may retry to transmit the RRCReestablishment message to the terminal device 130 successfully.

[0052] At 150, the terminal device 130 may be again hindered to transmit a RRCReestablishmentComplete message to the second network device 120 because of the LBT. At 152, the terminal device 130 may retry to transmit the RRCReestablishmentComplete message to the second network device 120 successfully. At 154, after Reestablishment is completed, the RLF-report may be retrieved from the terminal device 130 to the second network device 120.

[0053] At 162, the previous source node (such as, the first network device 110) information may be derived from RLF-report, and it may trigger the second network device 120 to transmit the FAILURE INDICATION message including the RLF-report to the source node or the first network device 110. It is noted that in some embodiments of this disclosure, the third network device may be also the same second network device 120.

[0054] In some embodiments, self-organizing networks (SON) instance in the source node further may carry out the root cause analysis for this RLF / HOF The SON instance needs all LBT failure information starting from the event 122 until the event 132 where the UL LBT failure information is in the RLF-report.

[0055] At 164, the second network device 120 may transmit the ACCESS AND MOBILITY INDICATION message including the DL LBT Failure Information to the first network deice 110. At 166, a trigger criterion for sending the ACCESS AND MOBILITY INDICATION message including the DL LBT Failure Information is not clear.

[0056] FIG. 2 illustrates a flowchart of method according to some embodiments of the present disclosure. For the purpose of discussion, the method 200 will be described with reference to FIG. 1 A. It would be appreciated that although the process flow 200 has been described referring to FIG. 1 A, this process flow 200 may be likewise applied to other similar communication scenarios.

[0057] In the process flow 200, when a first network device 110 determines that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device 110 by the radio link failure report or through a failure indication from a third network device, the first network device 110 may transmit (205) a first message 202 for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device 120 during the handover of the terminal device 130 to the second network device 120.

[0058] In some embodiments, the first message 202 may comprise an existing message reused for retrieving the LBT failure information or a dedicated message defined for retrieving the LBT failure information. In some further embodiments, the existing message or the dedicated message may include a flag or indicator for requesting the LBT failure information reporting. In some further embodiments, the dedicated message does not include the flag because the dedicated message may be the indicator.

[0059] The second network device 120 may then receive (210), from a first network device 110, the first message 202 after a handover of a terminal device served by the first network device 110 failed. The first message 202 may be used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device 120 during the handover of the terminal device 130.

[0060] The second network device 120 may transmit (215) a second message 204 including the LBT failure information to the first network device 110 based on receiving the first message 202. In some embodiments, the second message 204 may comprise an existing message reused for providing the LBT failure information or a dedicated message for providing the LBT failure information. The first network device 110 may then receive (220) the second message 204 including the LBT failure information from the second network device 120.

[0061] In some further embodiments, the first message 202 may be a dedicated retrieve LBT failure information request message, and the second message may be a dedicated retrieve LBT failure information response message or an enhanced access and mobility indication message. In some further example embodiments, the first message 202 may be an enhanced handover cancel message including a flag or indicator for retrieving the LBT failure information, and the second message 204 may be an enhanced access and mobility indication message. The flag or indicator may comprise a trigger criterion for providing the LBT failure information.

[0062] In some embodiments, the first network device 110 may serve a source cell for the handover, and the second network device 120 may serve a target cell for the handover. The terminal device 130 may reconnect to the source cell after at least one radio link failure (RLF) or handover failure (HOF). In some further embodiments, the terminal device 130 may reconnect to a third cell served by the first network device 110 or a third device.

[0063] In some further embodiments, the handover may be a conditional handover, or the handover may be prepared to multiple target devices. The second network device 120 may be a candidate target node for the conditional handover or for the multiple preparation handover. The terminal device 130 may be to be handed over to one of the candidate cells prepared by the candidate target node for the conditional handover or for multiple preparation handover.

[0064] In this way, the second network device 120 or a target node may be enabled to identify the situation when the LBT failure information (e.g., DL LBT information) needs to be sent, especially when the terminal device or UE reconnects after the RLF / HOF to the source cell or to third cell served by same node, i.e. RLF-report will be retrieved by the node which is hosting the serving cell.

[0065] To make only the one target node where HOF occurred aware that the DL LBT failure information is needed, the first network device 110 or source node may initiate a procedure which explicitly indicates that second network device 120 or the target node to provide the DL LBT failure information needed to carry out the MRO root cause analysis for an RLF / HOF experienced by dedicated UE.

[0066] FIG. 3 illustrates a detailed example of interactions 300 between devices in accordance with some example embodiments of the present disclosure. It is noted that FIG. 3 can be deemed as a further example of the process flow 200. For example, the gNBl 310 may be example devices of the first network device 110, the gNB2 320 may be example devices of the second network device 120, and the UE 330 may be example devices of the terminal device 130. It is to be understood that these devices are described only for the purpose of illustration without suggesting any limitation as to the scope of the disclosure. This process will be described in detail as follows.

[0067] In FIG. 3, lines 304 and 356 may represent cell A of the gNBl 310 (which may be also referred to a source node). Lines 368, 370 and 378 may represent cell B of the gNBl 310. A line 3 72 may represent cell C of the gNB2 320 (which may be also referred to gNB2 or a target node). Lines 374 and 376 may represent cell D of the gNBl 310.

[0068] When the UE 330 connects with cell A 3 04 of the gNB 1 310, an event for conditional handover (CHO) preparation 302 may occur. When the measurement event 302 criteria fulfilled and the UE 330 may trigger reporting. At 306, this reporting may be blocked by LBT (UL LBT failures which are logged on the UE 330 side).

[0069] At 308, the UE 330 may successfully transmit the report to the gNBl 310. At 358, the target candidate cells, such as cell C of the gNB2 320, may be prepared with HANDOVER REQUEST message. At 314 and 318, when the target candidate cells are prepared, the UE may be configured with condConfig. For example, at 314, the gNBl 310 may transmit the RRCReconfiguration including conditionalReconfiguration to the UE 330. At 318, the UE 330 may transmit RRCReconfigurationComplete information to the Cell B 368 of the gNBl 310. At 312 and 316, this RRC may also undergo LBT and be blocked. After the UE 330 is configured, it may start monitoring the measurements of candidate cell against condConfig.

[0070] If event 322 that condConfig criterion is fulfilled for one of the candidate cells (such as cell C 372 or cell D 374-376 of the gNB2 320), the UE 330 may autonomously detach from the gNBl 310 and start RACH procedure to the chosen target cell and start the timer T304. In some embodiments, at 324, the RACH procedure may be blocked by LBT (such as UL LBT failures), but it may be retried until it is successful at 326.

[0071] When the gNB2 320 receives signal on the RACH from the UE 330, it may trigger Random Access Report (RAR). At 360, the RAR may be blocked due to the DL LBT failures. At 328, the RAR may be LBT blocked and failed.

[0072] At 332, the event RLF or HOF occurs., The whole UL synchronization procedure with RACH and RAR may be supervised by the timer T304, and the handover may be declared as failed (handover failure, HOF) when the timer T304 expires. The Declaration of RLF / HOF may start the re-establishment phase supervised by timer T311.

[0073] The UE 330 may start re-establishment with cell search and perform RACH procedure towards best serving cell. At 334, the RACH procedure may be LBT blocked. At 336, the UE 330 may retry to perform the RACH procedure and success. At 338, when the gNBl 310 receives signal on the RACH from the UE 330, the gNBl 310 may transmit RAR to the UE 330.

[0074] At 340, UL sync to the found cell A 304-356 of the gNBl 310 may be successfully completed, and the actual RRCReestablishment procedure may start. At 342, the UE 330 may not transmit a RRC Reestablishment Request to the gNB 1310 because of the LBT. At 344, the UE 330 may retry to transmit a RRC Reestablishment Request to the gNBl 310 successfully.

[0075] At 346, the gNB 1310 may not transmit a RRCReestablishment message to the UE 330 because of the LBT. At 348, the gNBl 310 may retry to transmit the RRCReestablishment message to the UE 330 successfully.

[0076] At 350, the UE 330 may not transmit a RRCReestablishmentComplete message to the gNBl 310 because of the LBT. At 352, the UE 330 may retry to transmit the RRCReestablishmentComplete message to the gNBl 310 successfully. At 354, after Reestablishment is completed, the RLF-report may be retrieved from the UE 330 to the gNB 1 310.

[0077] At 362, the DL LBT failure information may be retrieved from target node or the gNB2 320with new messages named, for instance, retrieve LBTinformation request from the source node or the gNBl 310 to target node or the gNB2 320. At 364, The retrieve LBT information request may trigger in the response the access and mobility indication or a new message, e.g. retrieve LBTinformation response from target node or the gNB2 320 to source the source node or the gNBl 310.

[0078] It is noted that, in this disclosure, the message naming "retrieve LBT information request” or “retrieve LBT information response” are only examples and may not appear literally in practice. In this way, an alternative method to explicitly indicate the target node to provide the DL LBT failure information for specific failed handover is provided. This explicit indicator may have a form of a new class-1 procedure.

[0079] In some embodiments, for the basic HO, typically only one target node or gNB2 320 is prepared, and the target may assume that UE 330 will arrive within a reasonably short time after HO preparation. If it does not arrive, the target node 320 may assume the HO failed and the UE reconnected to the source or another node. Such assumption must be made in order to avoid reserving precious access resources too long. For that, the candidate node may start a timer with reception of HANDOVER REQUEST message which monitors the successful arrival of the UE 330. If the UE 330 did not connect within a defined timespan the timer expires or it is stopped with successful HO completion. The expiry will trigger the release of the UE-specific resources and data created for the handover. The same criterion may be used to trigger sending the ACCESS AND MOBILITY INDICATION message with the DL LBT failure information, if it was requested for this UE 330 in the HANDOVER REQUEST message.

[0080] FIG. 4 illustrates another detailed example of interactions 400 between devices in accordance with some example embodiments of the present disclosure. It is noted that FIG. 4 can be deemed as a further example of the process flow 200. It is to be understood that these devices are described only for the purpose of illustration without suggesting any limitation as to the scope of the disclosure. This process will be described in detail as follows.

[0081] In FIG. 4, lines 404 and 456 may represent cell A of the gNBl 410 (which may be also referred to a source node). Lines 468, 470 and 478 may represent cell B of the gNBl 410. A line 472 may represent cell C of the gNB2 420 (which may be also referred to gNB2 or a target node). Lines 474 and 476 may represent cell D of the gNBl 410.

[0082] When the UE 430 connects with cell A 404 of the gNBl 410, an event for conditional handover (CHO) preparation 402 may occur. When the measurement event 402 criteria fulfilled and the UE 430 may trigger reporting. At 406, this reporting may be blocked by LBT (UL LBT failures which are logged on the UE 430 side).

[0083] At 408, the UE 430 may successfully transmit the report to the gNBl 410. At 458, the target candidate cells, such as cell C of the gNB2 420, may be prepared with HANDOVER REQUEST message. At 414 and 418, when the target candidate cells are prepared, the UE may be configured with condConfig. For example, at 414, the gNBl 410 may transmit the RRCReconfiguration including conditionalReconfiguration to the UE 430. At 418, the UE 430 may transmit RRCReconfigurationComplete information to the Cell B 468 of the gNBl 410. At 412 and 416, this RRC may also undergo LBT and be blocked. After the UE 430 is configured, it may start monitoring the measurements of candidate cell against condConfig.

[0084] If event 422 that condConfig criterion is fulfilled for one of the candidate cells (such as cell C 472 or cell D 474-476 of the gNB2 420), the UE 430 may autonomously detach from the gNBl 410 and start RACH procedure to the chosen target cell and start the timer T304. In some embodiments, at 424, the RACH procedure may be blocked by LBT (such as UL LBT failures), but it may be retried until it is successful at 426.

[0085] When the gNB2 420 receives signal on the RACH from the UE 430, it may trigger Random Access Report (RAR). At 460, the RAR may be blocked due to the DL LBT failures. At 428, the RAR may be LBT blocked and failed.

[0086] At 432, the event RLF or HOF occurs. The whole UL synchronization procedure with RACH and RAR may be supervised by the timer T304, and the handover may be declared as failed (handover failure, HOF) when the timer T304 expires. The Declaration of RLF / HOF may start the re-establishment phase supervised by timer T311.

[0087] The UE 430 may start re-establishment with cell search and perform RACH procedure towards best serving cell. At 434, the RACH procedure may be LBT blocked. At 436, the UE 430 may retry to perform the RACH procedure and success. At 438, when the gNBl 410 receives signal on the RACH from the UE 430, the gNBl 410 may transmit RAR to the UE 430.

[0088] At 440, UL sync to the found cell A 404-456 of the gNBl 410 may be successfully completed, and the actual RRCReestablishment procedure may start. At 442, the UE 430 may not transmit a RRC Reestablishment Request to the gNB 1410 because of the LBT. At 444, the UE 430 may retry to transmit a RRC Reestablishment Request to the gNBl 410 successfully.

[0089] At 446, the gNBl 410 may not transmit a RRCReestablishment message to the UE 430 because of the LBT. At 448, the gNBl 410 may retry to transmit the RRCReestablishment message to the UE 430 successfully.

[0090] At 450, the UE 430 may not transmit a RRCReestablishmentComplete message to the gNBl 410 because of the LBT. At 452, the UE 430 may retry to transmit the RRCReestablishmentComplete message to the gNBl 410 successfully. At 454, after Reestablishment is completed, the RLF-report may be retrieved from the UE 430 to the gNB 1 410.

[0091] In case of CHO or multiple preparation, the unused candidate preparations may be freed both after successful HO completion and after a failed handover with RLF / HOF as considered here. To free those resources, the source gNB 410 may send the HANDOVER CANCEL message toward the other candidate target gNBs (such as gNB2 420), which have been prepared for the UE 430.

[0092] At 462, the HANDOVER CANCEL message may include a flag or indicator. The flag or indicator in the HANDOVER CANCEL message may be the required trigger criterion to provide the DL LBT failure information. At 464, gNB 420 may use the already specified access and mobility indication message including the DL LBT failure information to send the information. In this way, HANDOVER CANCEL message may be extended to trigger the reporting via access and mobility indication message.

[0093] FIG. 5 illustrates a flowchart of a method 500 performed by an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 500 will be described from the perspective of the first network device 110 with reference to FIG. 1 A.

[0094] At block 502, the first network device 110 may transmit a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by a second network device during the handover of the terminal device to the second network device based on determining that a handover of a terminal device served by the first network device has been performed to the second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device. At block 504, the first network device 110 may receive a second message including the LBT failure information from the second network device.

[0095] In some embodiments, the first message may comprise an existing message reused for retrieving the LBT failure information, or a dedicated message defined for retrieving the LBT failure information. In some further embodiments, the existing message may include a flag or indicator for requesting the LBT failure information reporting.

[0096] In some example embodiments, the second message may comprise an existing message reused for providing the LBT failure information, or a dedicated message for providing the LBT failure information. In some other example embodiments, the first message may be a dedicated retrieve LBT failure information request message, and the second message may be a dedicated retrieve LBT failure information response message or an enhanced access and mobility indication message.

[0097] In some embodiments, the first message may be an enhanced handover cancel message including a flag or indicator for retrieving the LBT failure information, and the second message may be an enhanced access and mobility indication message. In some further embodiments, the flag or indicator may comprise a trigger criterion for providing the LBT failure information.

[0098] In some embodiments, the first network device may serve a source cell for the handover, and the second network device may serve a target cell for the handover. The terminal device may reconnect to the source cell after at least one radio link failure (RLF) or handover failure (HOF); or the terminal device may reconnect, after the at least one RLF or HOF, to a third cell served by the first network device or a third device.

[0099] In some further embodiments, the handover may be a conditional handover, or the handover may be prepared to multiple target devices, and the second network device may be a candidate target node for the conditional handover or for the multiple preparation handover and the terminal device is to be handed over to one of the candidate cells prepared by the candidate target node for the conditional handover or for multiple preparation handover.

[00100] FIG. 6 illustrates a flowchart of a method 600 performed by an apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of the second network device 120 with reference to FIG. 1 A.

[00101] At block 602, the second network device 120 may receive, from a first network device, a first message after a handover of a terminal device served by the first network device failed. The first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device. At block 604, the second network device 120 may, transmit a second message including the LBT failure information to the first network device based on receiving the first message.

[00102] In some embodiments, the first message may comprise an existing message reused for retrieving the LBT failure information or a dedicated message defined for retrieving the LBT failure information. In some further embodiments, the existing message may include a flag or indicator for requesting the LBT failure information reporting.

[00103] In some embodiments, the second message may comprise an existing message reused for providing the LBT failure information or a dedicated message for providing the LBT failure information. In some other embodiments, the first message may be a dedicated retrieve LBT information request message, and the second message may be a dedicated retrieve LBT information response message or an enhanced access and mobility indication message.

[00104] In some example embodiments, the first message may be an enhanced handover cancel message including a flag or indicator for retrieving the LBT failure information, and the second message may be an enhanced access and mobility indication message.

[00105] In some example embodiments, the flag or indicator may comprise a trigger criterion for providing the LBT failure information. In some further embodiments, the first network device may serve a source cell for the handover, and the second network device may serve a target cell for the handover, and the terminal device may reconnect to the source cell after at least one radio link failure (RLF) or handover failure (HOF). Alternatively, or additionally, the terminal device may reconnect, after the at least one RLF or HOF, to a third cell served by the first network device or a third device.

[00106] In some further embodiments, the handover may be a conditional handover, or the handover may be prepared to multiple target devices, and the second network device may be a candidate target node for the conditional handover or for the multiple preparation handover and the terminal device is handed over to one of the candidate cells prepared by the candidate target node for the conditional handover or for the multiple preparation handover.

[00107] In some embodiments, an apparatus capable of performing any of the method 500 may be part of a first network device 110 and may comprise means for performing the respective operations of the method 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00108] In some embodiments, the apparatus comprises means for transmitting to the second network device, a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device based on determining that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device. In some embodiments, the apparatus comprises means for receiving, from the second network device, a second message including the LBT failure information.

[00109] In some embodiments, the first message may comprise an existing message reused for retrieving the LBT failure information, or a dedicated message defined for retrieving the LBT failure information. In some further embodiments, the existing message may include a flag or indicator for requesting the LBT failure information reporting.

[00110] In some example embodiments, the second message may comprise an existing message reused for providing the LBT failure information, or a dedicated message for providing the LBT failure information. In some other example embodiments, the first message may be a dedicated retrieve LBT failure information request message, and the second message may be a dedicated retrieve LBT failure information response message or an enhanced access and mobility indication message.

[00111] In some embodiments, the first message may be an enhanced handover cancel message including a flag or indicator for retrieving the LBT failure information, and the second message may be an enhanced access and mobility indication message. In some further embodiments, the flag or indicator may comprise a trigger criterion for providing the LBT failure information.

[00112] In some embodiments, the first network device may serve a source cell for the handover, and the second network device may serve a target cell for the handover. The terminal device may reconnect to the source cell after at least one radio link failure (RLF) or handover failure (HOF); or the terminal device may reconnect, after the at least one RLF or HOF, to a third cell served by the first network device or a third device.

[00113] In some further embodiments, the handover may be a conditional handover, or the handover may be prepared to multiple target devices, and the second network device may be a candidate target node for the conditional handover or for the multiple preparation handover and the terminal device is to be handed over to one of the candidate cells prepared by the candidate target node for the conditional handover or for multiple preparation handover.

[00114] In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 500. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[00115] In some embodiments, an apparatus capable of performing any of the method 600 may be part of a second network device 120 and may comprise means for performing the respective operations of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00116] In some embodiments, the apparatus comprises means for receiving, from a first network device, a first message after a handover of a terminal device served by the first network device failed, and the first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device. In some embodiments, the apparatus comprises means for based on receiving the first message, transmitting, to the first network device, a second message including the LBT failure information.

[00117] In some embodiments, the first message may comprise an existing message reused for retrieving the LBT failure information or a dedicated message defined for retrieving the LBT failure information. In some further embodiments, the existing message may include a flag or indicator for requesting the LBT failure information reporting.

[00118] In some embodiments, the second message may comprise an existing message reused for providing the LBT failure information or a dedicated message for providing the LBT failure information. In some other embodiments, the first message may be a dedicated retrieve LBT information request message, and the second message may be a dedicated retrieve LBT information response message or an enhanced access and mobility indication message.

[00119] In some example embodiments, the first message may be an enhanced handover cancel message including a flag or indicator for retrieving the LBT failure information, and the second message may be an enhanced access and mobility indication message.

[00120] In some example embodiments, the flag or indicator may comprise a trigger criterion for providing the LBT failure information. In some further embodiments, the first network device may serve a source cell for the handover, and the second network device may serve a target cell for the handover, and the terminal device may reconnect to the source cell after at least one radio link failure (RLF) or handover failure (HOF). Alternatively, or additionally, the terminal device may reconnect, after the at least one RLF or HOF, to a third cell served by the first network device or a third device.

[00121] In some further embodiments, the handover may be a conditional handover, or the handover may be prepared to multiple target devices, and the second network device may be a candidate target node for the conditional handover or for the multiple preparation handover and the terminal device is handed over to one of the candidate cells prepared by the candidate target node for the conditional handover or for the multiple preparation handover.

[00122] In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 600. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

[0001] FIG. 7 illustrates simplified block diagram of a device 700 that is suitable for implementing some example embodiments of the present disclosure. The device 700 may be provided to implement a communication device, for example, the first network device 110, the second network device 120 as shown in FIG. 1. As shown, the device 700 includes one or more processors 710, one or more memories 720 coupled to the processor 710, and one or more communication modules 740 coupled to the processor 710.

[0002] The communication module 740 is for bidirectional communications. The communication module 740 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements.

[0003] The processor 710 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 700 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0004] The memory 720 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 724, an electrically programmable read only memory (EPROM), a flash memory, a hard disk, a compact disc (CD), a digital video disk (DVD), and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 722 and other volatile memories that will not last in the power-down duration.

[0005] A computer program 730 includes computer executable instructions that are executed by the associated processor 710. The program 730 may be stored in the ROM 724. The processor 710 may perform any suitable actions and processing by loading the program 730 into the RAM 722.

[0006] The embodiments of the present disclosure may be implemented by means of the program 730 so that the device 700 may perform any process of the disclosure as discussed with reference to FIG. 2. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0007] In some example embodiments, the program 730 may be tangibly contained in a computer readable medium which may be included in the device 700 (such as in the memory 720) or other storage devices that are accessible by the device 700. The device 700 may load the program 730 from the computer readable medium to the RAM 722 for execution. The computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.

[0008] FIG. 8 illustrates a block diagram of an example of a computer readable medium 800 in accordance with some example embodiments of the present disclosure. The computer readable medium 800 has the program 730 stored thereon. It is noted that although the computer readable medium 800 is depicted in form of CD or DVD in FIG. 8, the computer readable medium 800 may be in any other form suitable for carry or hold the program 730.

[0009] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0010] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the method 200 as described above with reference to FIG. 2. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0011] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0012] In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[0013] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The term “non-transitory,” as used herein, is a limitation of the medium itself (i,e„ tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0014] Further, while operations are depicted 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. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0015] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A first network device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the first network device at least to:based on determining that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device, transmit to the second network device, a first message for retrieving listen before talk (LBT) failure information of LBT failures experienced by the second network device during the handover of the terminal device; andreceive, from the second network device, a second message including the LBT failure information.

2. The first network device of claim 1, wherein the first message comprises:an existing message reused for retrieving the LBT failure information; ora dedicated message defined for retrieving the LBT failure information.

3. The first network device of claim 2, wherein the existing message includes a flag or indicator for requesting the LBT failure information reporting.

4. The first network device of any of claims 1-3, wherein the second message comprises:an existing message reused for providing the LBT failure information; ora dedicated message for providing the LBT failure information.

5. The first network device of any of claims 1-4, wherein:the first message is a dedicated retrieve LBT failure information request message; and the second message is a dedicated retrieve LBT failure information response message or an enhanced access and mobility indication message.

6. The first network device of any of claims 1-4, wherein:the first message is an enhanced handover cancel message including a flag orindicator for retrieving the LBT failure information; andthe second message is an enhanced access and mobility indication message.

7. The first network device of claim 3 or 6, wherein the flag or indicator comprisesa trigger criterion for providing the LBT failure information.

8. The first network device of any of claims 1-7, wherein the first network device serves a source cell for the handover, and the second network device serves a target cell for the handover, and wherein:the terminal device reconnects to the source cell after at least one radio link failure (RLF) or handover failure (HOF); orthe terminal device reconnects, after the at least one RLF or HOF, to a third cell served by the first network device or a third network device.

9. The first network device of any of claims 1-6, wherein the handover is a conditional handover, or the handover is prepared to multiple target devices, and wherein:the second network device is a candidate target node for the conditional handover or for the multiple preparation handover and the terminal device is to be handed over to one of the candidate cells prepared by the candidate target node for the conditional handover or for multiple preparation handover.

10. A second network device compri sing:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the second network device at least to:receive, from a first network device, a first message after a handover of a terminal device served by the first network device failed, wherein the first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device; andbased on receiving the first message, transmit, to the first network device, a second message including the LBT failure information.

11. The second network device of claim 10, wherein the first message comprises: an existing message reused for retrieving the LBT failure information; ora dedicated message defined for retrieving the LBT failure information.

12. The second network device of claim 11, wherein the existing message includes a flag or indicator for requesting the LBT failure information reporting.

13. The second network device of any of claims 10-12, wherein the second message comprises:an existing message reused for providing the LBT failure information; ora dedicated message for providing the LBT failure information.

14. The second network device of any of claim 11-13, wherein:the first message is a dedicated retrieve LBT information request message; andthe second message is a dedicated retrieve LBT information response message or an enhanced access and mobility indication message.

15. The second network device of any of claims 10-13, wherein:the first message is an enhanced handover cancel message including a flag or indicator for retrieving the LBT failure information; andthe second message is an enhanced access and mobility indication message.

16. The second network device of claim 12 or 15, wherein the flag or indicator comprises a trigger criterion for providing the LBT failure information.

17. The second network device of any of claims 10-16, wherein the first network device serves a source cell for the handover, and the second network device serves a target cell for the handover, and wherein:the terminal device reconnects to the source cell after at least one radio link failure (RLF) or handover failure (HOF); orthe terminal device reconnects, after the at least one RLF or HOF, to a third cell served by the first network device or a third network device.

18. The second network device of any of claims 10-16, wherein the handover is a conditional handover, or the handover is prepared to multiple target devices, and wherein:the second network device is a candidate target node for the conditional handover or for the multiple preparation handover and the terminal device is handed over to one of the candidate cells prepared by the candidate target node for the conditional handover or for the multiple preparation handover.

19. A method compri sing:based on determining that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device, transmitting, to the second network device, a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device; andreceiving, from the second network device, a second message including the LBT failure information.

20. A method compri sing:receiving, from a first network device, a first message after a handover of a terminal device served by the first network device failed, wherein the first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device; andbased on receiving the first message, transmitting, to the first network device, a second message including the LBT failure information.

21. An apparatus comprising:means for based on determining that a handover of a terminal device served by the first network device has been performed to a second network device, and that the handover failed which is indicated to the first network device by the radio link failure report or through a failure indication from a third network device, transmitting, to the second network device, a first message for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device; andmeans for receiving, from the second network device, a second message including the LBT failure information.

22. An apparatus comprising:means for receiving, from a first network device, a first message after a handover of a terminal device served by the first network device failed, wherein the first message is used for retrieving listen before talk (LBT) failure information of the LBT failures experienced by the second network device during the handover of the terminal device; and5 means for based on receiving the first message, transmitting, to the first networkdevice, a second message including the LBT failure information.

23. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of claim 19 or 20.34

Images