EP4666679A1

EP4666679A1 - Network nodes and methods performed therein

Info

Publication number: EP4666679A1
Application number: EP24705645.0A
Authority: EP
Inventors: Luca LUNARDI; Ali PARICHEHREHTEROUJENI; Johan Rune; Angelo Centonza; Reem KARAKI
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-02-15
Filing date: 2024-02-14
Publication date: 2025-12-24
Also published as: WO2024170638A1

Abstract

Embodiments herein may relate to a method performed by a first network node (12) for handling communication in a communication network. The first network node (12) obtains a request indication for providing information associated with a LBT procedure carried out by the first network node (12) for a HO of one or more UE. The first network node (12) then sends to a second network node (13), information related to LBT procedure carried out by the first network node (12) for a HO of a UE between one or more network nodes and one or more cells of the first network node (12) operating in a shared spectrum.

Description

NETWORK NODES AND METHODS PERFORMED THEREIN

TECHNICAL FIELD

Embodiments herein relate to a first network node, a second network node and methods performed therein regarding communication. Furthermore, a computer program product and a computer-readable storage medium are also provided herein. In particular, embodiments herein relate to handling communication, such as managing, optimizing or controlling handovers, in a communication network.

BACKGROUND

In a typical communication network, user equipments (UE), also known as wireless communication devices, mobile stations, stations (STA) and/or wireless devices, servers, computers, communicate via an Access Network (AN), such as a radio access network (RAN) or a wired access network, with one or more core networks (CNs). The AN covers a geographical area which is divided into service areas or cells, with each service area or cell being served by a network node such as an access node e.g. a Wi-Fi access point or a radio base station (RBS), which in some networks may also be called, for example, a NodeB, a gNodeB, or an eNodeB. The service area or cell is a geographical area where radio coverage is provided by the network node. The network node operates on radio frequencies to communicate over an air interface with the UEs within range of the access node. The network node communicates over a downlink (DL) to the UE and the UE communicates over an uplink (UL) to the access node.

A Universal Mobile Telecommunications System (UMTS) is a third generation (3G) telecommunication network, which evolved from the second generation (2G) Global System for Mobile Communications (GSM). The UMTS terrestrial radio access network (UTRAN) is essentially a RAN using wideband code division multiple access (WCDMA) and/or High-Speed Packet Access (HSPA) for communication with user equipment. In a forum known as the Third Generation Partnership Project (3GPP), telecommunications suppliers propose and agree upon standards for present and future generation networks and investigate, e.g., enhanced data rate and radio capacity. In some RANs, e.g., as in UMTS, several radio network nodes may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), which supervises, and coordinates various activities of the plural radio network nodes connected thereto. The RNCs are typically connected to one or more core networks.

Specifications for the Evolved Packet System (EPS) have been completed within the 3GPP and present and coming 3GPP releases, such as New Radio (NR) and extensions, are worked on. The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long-Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a 3GPP radio access technology wherein the radio network nodes are directly connected to the EPC core network. As such, the Radio Access Network (RAN) of an EPS has an essentially “flat” architecture comprising radio network nodes connected directly to one or more core networks.

With the emerging 5G technologies such as new radio (NR), the use of very many transmit- and receive-antenna elements may be of great interest as it makes it possible to utilize beamforming, such as transmit-side and receive-side beamforming. Transmit-side beamforming means that the transmitter can amplify the transmitted signals in a selected direction or directions, while suppressing the transmitted signals in other directions. Similarly, on the receive-side, a receiver can amplify signals from a selected direction or directions, while suppressing unwanted signals from other directions.

Overall Architecture of next generation (NG)-RAN.

The overall architecture of NG-RAN is described in 3GPP TS 38.401 v17.2.0 and depicted in Fig. 1.

The NG-RAN consists of a set of gNBs connected to the 5G-core (5GC) through the NG interface.

As specified in TS 38.300 v.17.0.0, NG-RAN could also consist of a set of ng- eNBs, an ng-eNB may consist of an ng-eNB-central unit (CU) and one or more ng-eNB- distributed units (DU). An ng-eNB-CU and an ng-eNB-DU are connected via W1 interface. The general principle described in this section also applies to ng-eNB and W1 interface, if not explicitly specified otherwise.

A gNB can support frequency division duplex (FDD) mode, time division duplex (TDD) mode or dual mode operation. gNBs can be interconnected through the Xn interface.

A gNB may consist of a gNB-CU and one or more gNB-DU(s). A gNB-CU and a gNB-DU are connected via F1 interface.

One gNB-DU is connected to only one gNB-CU.

NG, Xn and F1 are logical interfaces. For NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-Cll and gNB-DUs, terminate in the gNB-Cll. For ELITRAN NR - Dual Connectivity (EN-DC), the S1-LI and X2-C interfaces for a gNB consisting of a gNB-Cll and gNB-DUs, terminate in the gNB-CU. The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB.

A possible deployment scenario is described in Annex A.

The node hosting user plane part of NR Packet Data Convergence Protocol (PDCP), e.g., gNB-CU, gNB-CU-user plane (UP), and for EN-DC, Master eNB or secondary gNB depending on the bearer split, shall perform user inactivity monitoring and further informs its inactivity or (re)activation to the node having C-plane connection towards the core network, e.g., over E1 , X2. The node hosting NR radio link control (RLC), e.g., gNB-DU, may perform user inactivity monitoring and further inform its inactivity or (re)activation to the node hosting control plane, e.g. gNB-CU or gNB-CU- control plane (CP).

UL PDCP configuration, i.e. , how the UE uses the UL at the assisting node, is indicated via X2-C, for EN-DC, Xn-C, for NG-RAN, and F1-C. Radio Link Outage/Resume for DL and/or UL is indicated via X2-U, for EN-DC, Xn-U, for NG-RAN, and F1-U.

The NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL).

The NG-RAN architecture, i.e., the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL. For each NG-RAN interface, such as NG, Xn, F1, the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport, signaling transport.

It needs to be mentioned that the architecture shown above is what 3GPP has defined for 5G. Other standardization groups, such as the Open RAN (ORAN), have further extended the architecture above and have for example split the gNB-DU into two further nodes connected by a fronthaul interface. The lower node of the split gNB-DU would contain the physical (PHY) protocol and the radio frequency (RF) parts, the upper node of the split gNB-DU would host the RLC and Medium Access Control (MAC). In ORAN the upper node is called ORAN-Distributed Unit (O-DU), while the lower node is called ORAN-Remote Radio Unit (O-RU).

At current state-of-art the coordination across RAN and Transport domains is typically managed in non-real-time mode, e.g., pre-planning and provisioning the Transport domain, with the alternative to coordinate Radio and Transport domains at Service Orchestration level. And there are no products are yet available on the market. In case of dynamic changes in the allocated RAN capacity, it should be possible to optimize the Transport capacity accordingly. Mobility Load Balancing is envisaged as one of the use cases where tighter coordination between RAN and Transport is required. It is also noted that transport network is a contributor to the overall latency and resilience of the mobile services and this aspect is particularly important in the case of ultra-reliable low latency communications (LIRLLC) services according to 3GPP standard specification.

NR is targeting both licensed and unlicensed bands and a work item named NR- based Access to Unlicensed Spectrum, also referred to as NR in Unlicensed Spectrum (NR-U), was started in Jan. 2019. Allowing unlicensed networks, i.e., networks that operate in shared spectrum, or unlicensed spectrum, to effectively use the available spectrum is an attractive approach to increase system capacity. Although unlicensed spectrum does not match the qualities of the licensed regime, solutions that allow an efficient use of it as a complement to licensed deployments have the potential to bring great value to the 3GPP operators, and, ultimately, to the 3GPP industry as a whole. It is expected that some features in NR will need to be adapted to comply with the special characteristics of the unlicensed band as well as different regulations. A subcarrier spacing (SOS) of 15 or 30 kHz are the most promising candidates for NR-U orthogonal frequency division multiplexing (OFDM) numerologies for frequencies below 6 GHz.

When operating in unlicensed spectrum many regions in the world require a device to sense the medium as free before transmitting, This, operation is often referred to as listen before talk (LBT).

LBT is designed for unlicensed spectrum co-existence with other RATs. In this mechanism, a radio device applies a Clear Channel Assessment (CCA) check, i.e., channel sensing, before any transmission. The transmitter involves energy detection (ED) over a time period compared to a certain threshold value (ED threshold) in order to determine if a channel is idle. a. LBT parameter settings, including ED, may be set for devices in a network by a network node configuring the devices in the network. The limits may be set as predefined rules or tables in specifications or regulatory requirements for operation in a certain region. Such limits are part of the ETSI harmonized standard in Europe as well as the 3GPP specification for operation of LTE/NR-U in unlicensed spectrum.

3GPP TS 37.213 v17.3.0 (2022-09), clause 4.0 specifies some general terminology applicable to Channel access procedure for shared spectrum: - A channel refers to a carrier or a part of a carrier consisting of a contiguous set of resource blocks (RB) on which a channel access procedure is performed in shared spectrum.

- A channel access procedure is a procedure based on sensing that evaluates the availability of a channel for performing transmissions. The basic unit for sensing is a sensing slot with a duration T_st = 9us. The sensing slot duration T_st is considered to be idle if an eNB/gNB or a UE senses the channel during the sensing slot duration, and determines that the detected power for at least 4us within the sensing slot duration is less than energy detection threshold value _Thresh. Otherwise, the sensing slot duration T_st is considered to be busy.

- A channel occupancy refers to transmission(s) on channel(s) by eNB/gNB/UE(s) after performing the corresponding channel access procedures in this clause.

- A Channel Occupancy Time refers to the total time for which eNB/gNB/UE and any eNB/gNB/UE(s) sharing the channel occupancy perform transmission(s) on a channel after an eNB/gNB/UE performs the corresponding channel access procedures described in this clause. For determining a Channel Occupancy Time, if a transmission gap is less than or equal to 25us, the gap duration is counted in the channel occupancy time. A channel occupancy time can be shared for transmission between an eNB/gNB and the corresponding UE(s).

- A DL transmission burst is defined as a set of transmissions from an eNB/gNB without any gaps greater than 16us. Transmissions from an eNB/gNB separated by a gap of more than 16us are considered as separate DL transmission bursts. An eNB/gNB can transmit transmission(s) after a gap within a DL transmission burst without sensing the corresponding channel(s) for availability.

- A UL transmission burst is defined as a set of transmissions from a UE without any gaps greater than 16us. Transmissions from a UE separated by a gap of more than 16us are considered as separate UL transmission bursts. A UE can transmit transmission(s) after a gap within a UL transmission burst without sensing the corresponding channel(s) for availability.

- A discovery burst refers to a DL transmission burst including a set of signal(s) and/or channel(s) confined within a window and associated with a duty cycle. The discovery burst can be any of the following: o Transmission(s) initiated by an eNB that includes a primary synchronization signal (PSS), secondary synchronization signal (SSS) and cell-specific reference signal(s)(CRS) and may include non-zero power CSI reference signals (CSI-RS). o Transmission(s) initiated by a gNB that includes at least an SS/PBCH block consisting of a primary synchronization signal (PSS), secondary synchronization signal (SSS), physical broadcast channel (PBCH) with associated demodulation reference signal (DM-RS) and may also include CORESET for PDCCH scheduling PDSCH with SIB1 , and PDSCH carrying SIB1 and/or non-zero power CSI reference signals (CSI-RS).

Downlink channel access procedures are specified for an eNB operating in Licensed Assisted Access (LAA) secondary cells (Scell) on channel(s) and a gNB performing transmission(s) on channel(s) according to 3GPP TS 37.213 clause 4.1.

3GPP TS 37.213, clause 4.1.1 (“Type 1 DL channel access procedure”) describes the channel access procedure to be performed by an eNB/gNB, where the time duration spanned by the sensing slots that are sensed to be idle before a downlink transmission(s) is random.

The eNB/gNB may transmit a transmission after first sensing the channel to be idle during the sensing slot durations of a defer duration T_d and after the counter N is zero. The counter N is adjusted by sensing the channel for additional sensing slot duration(s) according to the steps below:

Additional sensing slot duration(s) according to the steps below:

1) set N = N_init, where N_init is a random number uniformly distributed between 0 and CW_P, and go to step 4;

2) if TV > 0 and the eNB/gNB chooses to decrement the counter, set N = N - 1;

3) sense the channel for an additional sensing slot duration, and if the additional sensing slot duration is idle, go to step 4; else, go to step 5;

4) if TV = 0 , stop; else, go to step 2.

5) sense the channel until either a busy sensing slot is detected within an additional defer duration T_d or all the sensing slots of the additional defer duration T_d are detected to be idle;

6) if the channel is sensed to be idle during all the sensing slot durations of the additional defer duration T_d, go to step 4; else, go to step 5; In the steps above:

T_d is the defer duration and it consists of a duration T = 16us immediately followed by m_p consecutive sensing slot durations T_sl, and T_f includes an idle sensing slot duration T_si at start of T_r.

CW_p is the Contention Window with value CW^p < CW_p < CW_{max p}

- -nip, CW_{min p}, and CW_{max p} are based on a Channel Access Priority Class (CAPC) p associated with the eNB/gNB transmission, as shown in Table 4.1.1-1.

Tjncot _p /s maximum Channel Occupancy Time for p

Table 4.1.1-1 : Channel Access Priority Class (CAPC)

The 3GPP TS 38.321 v17.2.0 describes the “Random Access Preamble transmission” in clause 5.1 .3, an excerpt reported below, including aspects related to LBT failure indication. The “LBT failure detection and recovery procedure” is defined in clause 5.21.2 of the same Technical Specification.

5.1 .3 Random Access Preamble transmission

The MAC entity shall, for each Random Access Preamble:

1> ifPREAMBLE TRANSMISSION COUNTER is greater than one; and

1> if the notification of suspending power ramping counter has not been received from lower layers; and 1> if LBT failure indication was not received from lower layers for the last Random Access Preamble transmission; and

1> if SSB or CSI-RS selected is not changed from the selection in the last Random Access Preamble transmission:

2> increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

1> select the value of DELTA PREAMBLE according to clause 7.3;

SUBSTITUTE SHEET (RULE 26) 1> set PREAMBLE RECEIVED TARGET ' POWER to preambleReceivedTargetPower + DELTA PREAMBLE + (PREAMBLE POWER RAMPING COUNTER - 1) x PREAMBLE POWER RAMPING STEP + POWER OFFSETJSTEP RA',

1> except for contention-free Random Access Preamble for beam failure recovery request, compute the RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;

1> instruct the physical layer to transmit the Random Access Preamble using the selected PRACH occasion, corresponding RA-RNTI (if available), PREAMBLE INDEX, and PREAMBLE RECEIVED TARGET _PO WER.

1> if LBT failure indication is received from lower layers for this Random Access Preamble transmission:

2> if Ibt-FailureRecoveryConfig is configured:

3> perform the Random Access Resource selection procedure (see clause 5.1.2).

2> else:

3> increment PREAMBLE TRANSMISSION COUNTER by 1;

3> WPREAMBLE TRANSMISSION COUNTER = preambleTransMax + 1:

4> if the Random Access Preamble is transmitted on the SpCell:

5> indicate a Random Access problem to upper layers;

5> if this Random Access procedure was triggered for SI request:

6> consider the Random Access procedure unsuccessfully completed.

4> else if the Random Access Preamble is transmitted on an SCell:

5> consider the Random Access procedure unsuccessfully completed.

3> if the Random Access procedure is not completed:

4> perform the Random Access Resource selection procedure (see clause 5.1.2).

3GPP discussion concerning LBT issues in DL during mobility:

The following point has been raised as part of 3GPP discussions in RAN3 Working

Group, in relation to support of NR Unlicensed for Mobility Robustness Optimization

(MRO): whether and how, in case of handover, the target gNB can send to the source gNB indication of DL LBT failure. For example: in the Xn message, sent post handover (HO) execution, which contains the radio link failure (RLF) report in an Xn message, sent post HO execution, which does not contain the RLF report. In R3-221978, disclosing a scenario where DL LBT failure impacts handover execution, it is proposed that if the target network node fails to send downlink signals such as Random Access Response, MSG4, MSGB to the UE, the target network node informs the source network node that LBT failure occurred in the target network node for the purpose of failure cause analysis.

During handover procedure, as illustrated in Fig. 2, for the case that LBT fails at the target node, e.g. the target node fails to send RAR/MSG4/MSG B to the UE due to unlicensed channel resources in target cell are unavailable, when T304 expires, from UE point of view, it does not know LBT failure in the network, and it can trigger RLF report as legacy when handover failure, HOF, happens.

Then, the source node can receive the RLF report as legacy, since the information included in the RLF report is not NR-U relevant, the source node would execute handover failure cause analysis according to the received RLF report and optimize mobility configuration as legacy e.g. modify handover trigger threshold, or TTT for RRM measurement. However, there is a possibility that the actual failure cause is inappropriate LBT related configuration rather than mobility configuration, in such a case, modifying mobility configuration by the source node is not essential and needs to be avoided.

To enable the source node distinguish mobility issue (e.g. improper mobility configuration) from LBT issue (e.g. improper LBT configuration), the target node can inform the source node that LBT failure occurred in the target node via a new introduced message or reusing the HANDOVER REPORT message. The source node can make failure cause analysis based on the RLF report and LBT failure indication from the target node, e.g. decide whether it is mobility issue or LBT issue or both. For example, if the source node decides that it is a LBT issue and only LBT configuration at the target node needs to be optimized, the source node would keep previous mobility configuration and inform the target node to do optimization for LBT configuration. For the target node, it can optimize the LBT configuration after receiving the informing message from the source node, or it may modify the LBT configuration optionally when it finds DL LBT failure happens.

SUMMARY

As part of developing embodiments herein one or more problems were first identified.

The point mentioned above, concerning the ongoing 3GPP discussion on whether and how, in case of handover, the target gNB can send to the source gNB indication of DL LBT failure is still unresolved. For example, if it should be: in the Xn message, sent post HO execution, which contains the RLF report in an Xn message, sent post HO execution, which does not contain the RLF report.

Moreover, the more general problem concerning mobility when DL LBT failures are present at the target network node is not clearly addressed.

For instance, if we consider a certain target network node for handover, the presence of DL LBT issues does not necessarily cause a failure in handover execution. The transmission of different DL signals during the handover execution, e.g., Msg2, Msg4, Msg B, can be delayed or totally blocked based on whether and for how long a shared channel is detected as busy.

One limitation of current technology is that mobility decisions, or the ability to optimize Random Access procedure related parameters do not consider how likely it is to fail a handover towards a potential target network node when DL LBT issues are present at that target network node, or how likely it is to fail certain steps of the handover execution procedure, e.g., how easy or difficult it is for a UE to receive Msg4 after it has sent Msg3, when DL LBT issues are present at that target network node.

Another limitation of current technology is that a certain network node e.g., source network node cannot assess how close to a failure a handover successfully completed towards another network node e.g., target network node could be due to the presence of DL LBT issue at the target network node.

In R3-221978, it has been proposed that when a certain HO failure happens due to LBT failure at the target network node, the target network node can send an indication to the source network node indicating that an LBT failure occurred in the target network node.

The proposal is limited, at least in the following aspects: it does not consider the presence of DL LBT failures for successful handover executions,

- the source network node cannot understand at which stage of the handover execution the handover procedure failed, e.g., if it is in responding to Msg1 or in responding to Msg3,

- the source network node cannot assess how severe the presence of DL LBT issues is at the target network node.

The source network node has limited information to determine the optimal target network node in case of multiple candidates, potentially experiencing DL LBT failures, but at different degrees. There is also no possibility to consider the presence of DL LBT failures at the target network node when optimizing Random Access procedure related parameters.

An object herein is to provide a mechanism to handle communication efficiently in the communication network.

According to an aspect the object is achieved, according to embodiments herein, by providing a method performed by a first network node for handling communication in a communication network. The first network node may be a target node of a handover of a UE from a second network node. The first network node obtains a request indication for providing information associated with an LBT procedure carried out by the first network node for a HO of one or more UEs. The first network node sends to the second network node, information associated with an LBT procedure carried out by the first network node for a HO of a UE between one or more network nodes and one or more cells of the first network node operating in shared spectrum. The received information may, for example, indicate one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

According to yet another aspect the object is achieved, according to embodiments herein, by providing a method performed by a second network node for handling communication in a communication network. The second network node may send a request indication, to a first network node, for providing information associated with an LBT procedure carried out by the first network node for a HO of one or more UEs. The second network node receives from a first network node information associated with a LBT procedure carried out by the first network node for a HO of a UE between one or more network nodes and one or more cells of the first network node operating in shared spectrum. The second network node uses the received information for performing a mobility robustness optimization, The received information may, for example, indicate one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

According to yet another aspect the object is achieved, according to embodiments herein, by providing a first network node for handling communication in a communication network. The first network node is configured to obtain a request indication for providing information associated with an LBT procedure carried out by the first network node for a HO of one or more UEs. The first network node is further configured to send to a second network node, information associated with an LBT procedure carried out by the first network node for a HO of a UE between one or more network nodes and one or more cells of the first network node operating in shared spectrum, The received information may, for example, indicates one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

According to yet another aspect the object is achieved, according to embodiments herein, by providing a second network node for handling communication in a communication network. The second network node may be configured to send a request indication, to a first network node, for providing information associated with a LBT procedure carried out by the first network node for a HO of one or more UEs. The second network node is configured to receive from a first network node, information associated with a LBT procedure carried out by the first network node for a HO of a UE between one or more network nodes and one or more cells of the first network node operating in shared spectrum. The second network node is further configured to use the received information for performing a mobility robustness optimization,. The received information may, for example, indicate one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

It is furthermore provided herein a computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the methods herein, as performed by the first network node and the second network node, respectively. It is additionally provided herein a computer-readable storage medium, having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the methods herein, as performed by the first network node and the second network node, respectively.

The proposed solution enables network nodes, in particular the source node of the HO, such as the second network node, to determine the HO failure types properly e.g., preventing to wrongly classify the HO failure caused by the downlink LBT issue as due to Too Early HO or due to HO to wrong cell. The proposed solution enables the second network node to, for example, determine whether a peer RAN node is a good candidate for handover, based on the presence and intensity of DL LBT issues at the peer node. Thus, embodiments herein handle communication efficiently in the communication network.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described in more detail in relation to the enclosed drawings, in which: Fig. 1 shows a schematic overview depicting an overall architecture of NG-RAN according to prior art;

Fig. 2 shows an overall architecture for signalling according to prior art;

Fig. 3 shows a communication network according to embodiments herein;

Fig. 4 shows a flowchart depicting a method performed by a first network node according to embodiments herein;

Fig. 5 shows a flowchart depicting a method performed by a second network node according to embodiments herein;

Fig. 6a shows a combined signalling scheme and flowchart according to some embodiments herein;

Fig. 6b shows a combined signalling scheme and flowchart according to some embodiments herein;

Fig. 6c shows a combined signalling scheme and flowchart according to some embodiments herein;

Fig. 6d shows a signalling scheme according to some embodiments herein;

Fig. 6e shows a signalling scheme according to some embodiments herein;

Fig. 7 shows a schematic overview depicting a first network node according to embodiments herein;

Fig. 8 shows a schematic overview depicting a second network node according to embodiments herein;

Fig. 9 schematically illustrates a telecommunication network connected via an intermediate network to a host computer;

Fig. 10 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection; and

Figs. 11-14 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.

DETAILED DESCRIPTION

Embodiments herein relate to communication networks in general. Fig. 3 is a schematic overview depicting a communication network 1. The communication network 1 comprises one or more access networks, such as RANs, and one or more CNs. The communication network 1 may use one or a number of different technologies. Embodiments herein relate to recent wired and wireless networks such as Wi-Fi, new radio (NR), other existing wired or wireless networks, and further developments of existing wireless communications systems such as e.g., LTE or WCDMA. In the communication network 1, a UE 10, for example, a wireless device such as a mobile station, a non-access point (non-AP) station (STA), a STA and/or a wireless terminal, is comprised communicating via the one or more Access Networks (AN) to other UEs or one or more CNs. It should be understood by the skilled in the art that “UE” is a non-limiting term which means any terminal, wireless communications terminal, internet of things (loT) capable device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station capable of communicating using radio communication with a radio network node within an area served by the radio network node.

The communication network 1 comprises a first network node 12 providing radio coverage over a geographical area, a first service area 11 or first cell, of a first RAT, such as WiFi, NR, LTE, or similar. The first network node 12 may be a transmission and reception point such as an access node, an access controller, a base station, e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a UE within the area served by the radio network node depending e.g. on the first radio access technology and terminology used. The first network node 12 may be an access node such as a WiFi-modern or a radio network node and may be referred to as a target radio network node wherein the service area may be referred to as a target cell. It should be noted that a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage.

The communication network 1 may further comprise a second network node 13 providing radio coverage over a geographical area, a second service area 14 or second cell, of a RAT, such as WiFi, NR, LTE, or similar. The second network node 13 may be a transmission and reception point such as an access node, an access controller, a base station, e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a UE within the area served by the network node depending e.g. on the radio access technology and terminology used. The second network node 13 may be an access node such as a WiFi-modern or a radio network node and may be referred to as a source radio network node wherein the service area may be referred to as a source cell.

The second network node 13 receives from the first network node 12, information associated with a LBT procedure (one or more LBT procedures) carried out by the first network node 12 for a HO of a UE between one or more network nodes and one or more cells of the first network node 12 operating in shared spectrum. The second network node 13 is further configured to use the received information for performing a mobility robustness optimization.

According to some aspects of the present disclosure (Scenario A.1 : DL LBT related information for handovers incoming from a certain RAN node during a time interval):

- the second network node 13, such as the source network node of a handover, or conditional handover, may requests the first network node 12, such as the target network node of the HO, to provide DL LBT related information concerning mobility procedures executed i.e. , handover executions between the second network node 13 and the one or more target cells of the first network node 12 operating in shared spectrum during a time interval. o For example, the request is to obtain the number of LBT failures in DL occurred during a time period following the preparation of one or more mobility procedure, e.g., handover, between the second network node 13 and the first network node 12, e.g. for a time period during which the mobility procedures are expected to be executed.

- the first network node 12 sends to the second network node 13 the requested information o in case of successful handover execution and/or in case of failed handover execution.

The same embodiments as for scenario A.1 can be reused in scenario A.2: DL LBT related information for handovers incoming from a certain neighbour/source cell (controlled by the second network node 13) to a certain target cell (controlled by the first network node 12 having the role of target network node).

According to some other aspects of the present disclosure (Scenario B: DL LBT related information for handovers incoming from any RAN node):

- the second network node 13 such as the source network node for handover or conditional handover may request the first network node 12 such as the target network node to provide DL LBT related information concerning mobility procedures executed i.e., handover executions between any network node and the one or more target cells of the first network node 12 operating in shared spectrum.

- the first network node 12 sends to the second network node 13 the requested information o in case of successful handover execution and/or in case of failed handover execution

According to some other aspects of the present disclosure (Scenario C: DL LBT related information for an individual incoming handover):

- the second network node 13 such as the source network node for handover or conditional handover may request the first network node 12 such as the target network node to provide DL LBT related information concerning one specific mobility procedure executed i.e., handover execution between a cell of the second network node 13 and one of the target cells of the first network node 12 operating in shared spectrum.

Information associated with or related to an LBT procedure may comprise DL LBT related information, which concerns the impact of one or more DL LBTs at the target network node, e.g., indication of LBT failures in DL that blocked or delayed the transmission of DL messages or signals comprised in the mobility procedure, e.g., transmission of Random Access Response after successful reception of a Random Access Preamble, transmission of Msg B after successful reception of a Msg A, transmission of Msg 4 after successful reception of Msg 3, or transmission of synchronization signal block (SSB) after the Handover Request was received by the target network node from the source network node.

It should be noted that a network node may be a RAN node, an Operation and Maintenance (OAM), a Core Network node, a Service Management and Orchestration (SMO), a Network Management System (NMS), a Non-Real Time RAN Intelligent Controller (Non-RT RIC), a Real-Time RAN Intelligent Controller (RT-RIC), a gNB, eNB, en-gNB, ng-eNB, gNB-CU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, lAB-node, lAB-donor DU, lAB-donor-CU, IAB-DU, IAB-MT, O-CU, O-CU- CP, O-CU-UP, O-DU, O-RU, O-eNB, a Cloud-based network function, a Cloud-based centralized training node.

The terms NR-ll and NR Unlicensed are used interchangeably and represent a type of shared spectrum for NR.

The description provided for NR Unlicensed should not be regarded as limiting in terms of applicability of embodiments to different 3GPP generations, i.e. the embodiments are applicable to 3GPP generations preceding NR (such as LTE) and to 3GPP generation following NR, such as 6G, as long as UE and network node operates in shared spectrum.

“LBT issue” or “LBT failure” terms are used to indicate a situation that UE or a network node performs channel sensing and determines that the channel is busy, e.g., occupied by other transmitters such as other UEs, other RAN nodes or other non-3GPP transmitters e.g., Wi-Fi nodes. Determining that the channel is busy (or occupied) can be done in various approaches. In a non-limiting example, the UE or a network node measures the detected power value across the channel and compares it with an energy detection threshold. If the measured detected power is above the threshold the UE determines channel is occupied which is called as LBT issue or LBT failure.

- A random access preamble is also referred to as Msg1, and a Random Access Response message is also referred to as Msg2.

In this document the terms “source node” and “source network node” are equivalent. Similarly, the terms “target node” and “target network node” are equivalent.

Expressions such as: “actual time elapsed for handover execution at the target node”, “handover execution time at the target node”, “actual time elapsed for handover execution at the target network node”, “handover execution time at the target network node”, “actual time elapsed for handover execution at the target”, “handover execution time at the target” can be used interchangeably.

Handover supervision timer at the target network node refers to a timer to monitor the handover execution at the target network node.

The “sensing time” as mentioned herein can be intended as including or excluding the backoff time, or the defer duration time (ref. TS 37.123 v17.3.0). Some scenarios are illustrated herein to describe the methods of embodiments.

The embodiments may consider failures or successes in handover executions during which DL LBT failures and/or issues were present.

In the following, the first network node 12 is the target network node, and the second network node 13 is the source network node. Considers scenarios: the first network node 12 may receive from the UE 10 a Random Access Preamble, and fails to transmit the corresponding Random Access Response, also referred to as Msg2, due to detecting the shared channel as busy, such as a DL LBT failure. the first network node 12 may receive from the UE 10 a Msg 3, and fails to transmit the corresponding Msg 4 due to detecting the shared channel as busy, the first network node r12 may receive from the UE 10 a Msg A, and fails to transmit the corresponding Msg B due to detecting the shared channel as busy, a certain percentage of the time that a handover supervision timer at the target network node 12 is configured to run elapses during which DL transmissions (e.g., of Msg2, or Msg B, or Msg4) are not possible due to detecting the shared channel as busy. for a specific handover execution, or for a plurality of handover executions a certain amount of time elapses, while a handover supervision timer at the target network node 12 is running, during which DL transmissions, e.g., of Msg2, or Msg B, or Msg4, are not possible due to detecting the shared channel as busy. for a specific handover execution, or for a plurality of handover executions a certain number of attempts of DL transmissions, e.g., of Msg2, or Msg B, or Msg4, during one or multiple handover executions are not possible due to detecting the shared channel as busy. a certain percentage of handover executions initiated during a reference time interval, e.g., during a reporting period, fails due to detecting the shared channel as busy when attempting DL transmissions, e.g., of Msg2, or Msg B, or Msg4. a certain percentage of handover executions initiated during a reference time interval, e.g., during a reporting period, and incoming from a certain source network node 13 fails due to detecting the shared channel as busy when attempting DL transmissions, e.g. of Msg2, or Msg B, or Msg4. the first network node 12 fails to send SSB(s) for a certain amount of time due to detecting the channel as busy after successfully completed handover. The method actions performed by the first network node 12, i.e. the target network node, for handling communication in the communication network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 4. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Dashed boxes indicate optional features. The first network node may be a target node of a handover of the UE 10 from the second network node.

Action 401. The first network node 12 obtains a request indication for providing information associated with an LBT procedure carried out by the first network node 12 for a HO of one or more UEs. For example, the first network node 12 may receive, from the second network node 13 or from another network node, a request, e.g. subscription request, to receive information related to one or more LBT procedures carried out by the first network node 12 for a HO of one or more UEs. The request indication may be comprised in a request message, requesting the first network node 12 to record and report DL LBT related information, such as information related to one or more LBT procedures, upon fulfillment of one or more conditions. The one or more conditions may be comprised in the request message or preconfigured at the first network node 12.

Action 402. The first network node 12 may obtain an indication whether a HO of UE 10 between any network node and one or more cells of the first network node 12 operating in shared spectrum has succeeded or failed due to an issue related to an LBT procedure in Downlink. The first network node 12 may determine that the HO failed due to LBT issues in Downlink or receive information that HO failed due to LBT issues in Downlink. The first network node 12 may log the DL LBT related information hindering the first network node 12 to complete the HO procedure for the UE 10.

Action 403. The first network node 12 sends to the second network node 13 information associated with the LBT procedure carried out by the first network node 12 for the HO of the UE 10 between one or more network nodes and one or more cells of the first network node 12 operating in shared spectrum. The information may comprise DL LBT related information, and the first network node 12 may send a first message comprising DL LBT related information, i.e., the information. This may be performed irrespective whether the HO failed or succeeded. The information, for example, indicates one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

Thus, embodiments herein disclose methods comprising one or more of the following actions performed by the first network node 12, such as a target of a HO: • Preparing a HO command and sending to the second network node 13, wherein the second network node 13 may eventually send it to a UE 10, upon HO request, e.g., a HANDOVER REQUEST XnAP message, from the first network node 12.

• Detecting a HO execution by the UE 10, e.g., based on the contention free RA resources configured for the HO.

• Logging DL LBT related information hindering the first network node 12 to complete the HO procedure for the UE 10.

• Optionally correlating the logged DL LBT related information and a RLF report or a successful handover report (SHR) received from the UE 10.

• Sending the DL LBT related information and optionally the RLF report and the SHR to the second network node 13, e.g., via the Xn Handover Report message.

The method actions performed by the second network node 13, i.e. the sourcing network node or another network node, for handling communication in the communication network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 5. The actions do not have to be taken in the order stated below but may be taken in any suitable order. Dashed boxes indicate optional features. The second network node 13 may have handed over the UE 10 to the first network node 12.

Action 501. The second network node 13 may send a request indication, to the first network node 12, for providing information related to an LBT procedure carried out by the first network node 12 for a HO of one or more UEs. The request indication may be comprised in a request message, requesting the first network node 12 to record and report DL LBT related information upon fulfillment of one or more conditions. The one or more conditions may be comprised in the request message.

Action 502. The second network node 13 receives from the first network node 12, information associated with a LBT procedure carried out by the first network node 12 for the HO of a UE between one or more network nodes and one or more cells of the first network node 12 operating in shared spectrum.

Action 503. The second network node 13 uses the received information for performing a mobility robustness optimization. The information may, for example, indicate one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal. The second network node 13 may use the information by determining a HO failure type by classifying the HO failure as a downlink LBT failure based on the information. The second network node 13 may use the information to modify handover parameters such as threshold, or time to trigger (TTT), and/or RA parameters such as preamble format, time resources, and frequency resources for Physical random access (PRACH) parameters.

Embodiments herein disclose methods comprising one or more of the following performed by the second network node 13 which may e.g., be the source of HO:

• Receiving DL LBT related information pertaining to the first network node 12 and optionally the RLF report and/or the SHR from the first network node 12 which may e.g., be target of HO.

• Correlating the DL LBT related information pertaining to the first network node 12 and the optionally received RLF report and/or SHR.

• Using the combined information for the sake of mobility robustness optimization.

Some scenarios are illustrated herein to describe the methods of embodiments.

In the following, the first network node 12 is the target network node, and the second network node 13 is the source network node. Considers scenarios: the first network node 12 receives from the UE 10 a Random Access Preamble, and fails to transmit the corresponding Random Access Response (also referred to as Msg2) due to detecting the shared channel as busy, e.g., a DL LBT failure, the first network node 12 receives from the UE 10 a Msg 3, and fails to transmit the corresponding Msg 4 due to detecting the shared channel as busy. the first network node 12 receives from the UE 10 a Msg A, and fails to transmit the corresponding Msg B due to detecting the shared channel as busy. a certain percentage of the time that a handover supervision timer at the first network node 12 is configured to run elapses during which DL transmissions, e.g., of Msg2, or Msg B, or Msg4, are not possible due to detecting the shared channel as busy, for a specific handover execution, or for a plurality of handover executions, a certain amount of time elapses, while a handover supervision timer at the first network node 12 is running, during which DL transmissions, e.g., of Msg2, or Msg B, or Msg4, are not possible due to detecting the shared channel as busy, for a specific handover execution, or for a plurality of handover executions, a certain number of attempts of DL transmissions, e.g., of Msg2, or Msg B, or Msg4, during one or multiple handover executions are not possible due to detecting the shared channel as busy. a certain percentage of handover executions initiated during a reference time interval, e.g., during a reporting period, fails due to detecting the shared channel as busy when attempting DL transmissions, e.g., of Msg2, or Msg B, or Msg4. a certain percentage of handover executions initiated during a reference time interval, e.g., during a reporting period, and incoming from a certain source network node fails due to detecting the shared channel as busy when attempting DL transmissions, e.g., of Msg2, or Msg B, or Msg4. the first network node 12 fails to send SSB(s) for a certain amount of time due to detecting the channel as busy after successfully completed handover.

Fig. 6a is a combined signalling and flowchart scheme according to some embodiments herein.

Action 601. The first network node 12 obtains the request indication for providing information associated with an LBT procedure carried out by the first network node 12. For example, the first network node 12 may receive, from the second network node 13, a request (e.g. subscription) to receive information related to a LBT procedure. The request may be comprised in a second message from a requesting network node, wherein the request is to record and report DL LBT related information upon a condition fulfilled. The condition may be comprised in the message or preconfigured at the first network node 12.

Action 602. The first network node 12 may obtain the indication of a failed HO procedure due to an issue related to LBT. The first network node 12 may determine that the HO of a UE failed due to LBT issues or receive information that HO failed due to LBT issues.

Action 603. The first network node 12 sends to the second network node 13, initiating the HO procedure, the information associated with the LBT procedure carried out by the first network node 12. The information may comprise DL LBT related information, and the first network node 12 may send a first message comprising DL LBT related information, i.e., the information. This may be performed irrespective whether the HO failed or succeeded.

Action 604. The second network node 13 uses the received information for the sake of mobility robustness optimization. The second network node 13 may determine the HO failure types properly e.g., preventing to wrongly classify the HO failure caused by the downlink LBT issue as due to Too Early HO or due to HO to wrong cell. The second network node 13 may, for example, determine whether a peer RAN node is a good candidate for handover, based on the presence and intensity of DL LBT issues at the peer node.

Scenario A.1 : DL LBT related information for handovers incoming from a certain RAN node during a time interval.

This scenario addresses the case of multiple handovers occurring from a second network node 13 e.g., a certain source node to the one or more target cells of the first network node e.g., target network node operating in shared spectrum during a time interval. For this scenario, the methods are executed by the first network node 12 in the role of the target network node for a plurality of handovers incoming from any cell of a specific second network node 13 towards any cell of the first network node 12 operating in shared spectrum during a time interval.

In one embodiment, the first network node 12 determines that at least one handover execution failed due to DL LBT issues at the first network node 12, wherein the corresponding handover preparation was initiated by the second network node 13. Based on that, the first network node 12 sends a FIRST MESSAGE to the second network node 13, which comprises the information such as DL LBT related information.

In some non-limiting examples of realization, the FIRST MESSAGE can be a RESOURCE STATUS UPDATE XnAP message, or an ACCESS AND MOBILITY INDICATION XnAP message.

In non-limiting examples, the DL LBT related information may comprise an indication of the percentage of handover executions initiated by the second network node 13 that failed during a certain reporting period due to blocked transmissions by the first network node 12 of any message occurring during handover execution in DL, such as Msg2 or Msg4 or Msg B, due to a busy shared channel.

In another non-limiting example, the DL LBT related information may comprise an indication of the percentage of conditional handover executions initiated by the second network node 13 that failed during a certain reporting period due to blocked transmission of any of Msg2 or Msg4 or Msg B in the first network node 12 due to a busy shared channel.

In another non-limiting example, the DL LBT related information may comprise an indication of the average percentage of a handover supervision timer running at the first network node 12, or the average percentage of an actual handover execution time at the first network node 12, that was spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B, for the failed handovers.

In another non-limiting example, the DL LBT related information may comprise an indication of the average percentage of a handover supervision timer running at the first network node 12, or the average percentage of an actual handover execution time at the first network node 12, that was spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B, for the successful handovers.

- As one option, the FIRST MESSAGE may be sent periodically.

- As another option, the FIRST MESSAGE may be sent after a certain number of handovers have failed since the preceding transmission of the FIRST MESSAGE.

In one embodiment, the first network node 12 determines that at least for a successfully completed handover originated by a certain second network node 13, certain DL LBT impact was determined at the first network node 12. Based on that, the first network node 12 sends a FIRST MESSAGE to the second network node 13 from which the handover originated, the FIRST MESSAGE comprising DL LBT related information.

In some non-limiting examples of realization, the FIRST MESSAGE may be a RESOURCE STATUS UPDATE XnAP message, or an ACCESS AND MOBILITY INDICATION XnAP message.

In non-limiting examples, the DL LBT related information may comprise an indication of the percentage of successfully completed handovers - initiated by the second network node 13 - for which the time elapsed for sensing the shared channel for transmission of any handover execution message in DL, such as Msg2 or Msg4 or Msg B, is above a certain percentage of a handover supervision timer running at the first network node 12, or a certain percentage of an actual handover execution time at the first network node 12.

In non-limiting examples, the DL LBT related information may comprise an indication of the percentage of successfully completed conditional handovers - initiated by the second network node 13 - for which the time elapsed for sensing the shared channel for transmission of any of Msg2 or Msg4 or Msg B is above a certain percentage of a handover supervision timer running at the first network node 12, or a certain percentage of an actual handover execution time at the first network node 12. In another non-limiting example, the DL LBT related information may comprise an indication of the average percentage of a handover supervision timer running at the first network node 12, or the average percentage of an actual handover execution time at the first network node 12, that were spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B, for the successful handovers.

In another non-limiting example, the DL LBT related information may comprise an indication of the average percentage of a handover supervision timer running at the first network node 12, or the average percentage of the actual handover execution time at the first network node 12, that were spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B, for the failed handovers.

- As one option, the FIRST MESSAGE may be sent periodically.

- As another option, the FIRST MESSAGE may be sent after a certain number of successful handovers have occurred since the preceding transmission of the FIRST MESSAGE.

In one embodiment, the first network node 12 sends DL LBT related information in a FIRST MESSAGE to the second network node 13 if at least one handover has occurred, irrespective of the outcome i.e., success or failure of the handover(s).

In non-limiting examples, the DL LBT related information may comprise an indication of the percentage of handover executions initiated by the second network node 13 that failed during a certain reporting period due to blocked transmissions of any handover execution message in DL, such as Msg2 or Msg4 or Msg B in the first network node 12 due to a busy shared channel.

In another non-limiting example, the DL LBT related information may comprise an indication of the average percentage of a handover supervision timer running at the first network node 12, or the average percentage of an actual handover execution time at the first network node 12, that were spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B, for the failed handovers. In another non-limiting example, the DL LBT related information may comprise an indication of the average percentage of a handover supervision timer running at the first network node 12, or the average percentage of an actual handover execution time at the first network node 12, that were spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B, for the successful handovers.

- As one option, the FIRST MESSAGE may be sent periodically.

- As another option, the FIRST MESSAGE may be sent after a certain number of handovers have occurred since the preceding transmission of the FIRST MESSAGE.

In one embodiment, which may be combined with any of the above embodiments of Scenario A.1 , the first network node 12 such as the target network node), before sending DL LBT related information to the certain second network node 13 such as the source network node may receive, action 401 , from that certain second network node 13 such as the source network node a SECOND MESSAGE including a request e.g. subscription to receive from the first network node 12 DL LBT related information associated to handover execution, in one variant in case of handover failure, or in another variant in case of handover success, or in another variant irrespective of the outcome of the handovers, for handovers originated from that specific second network node 13.

- An example of SECOND MESSAGE may be a RESOURCE STATUS REQUEST XnAP message.

In addition, the second network node 13 may indicate in the SECOND MESSAGE at least one condition to be fulfilled for the first network node 12 to send or to stop sending the DL LBT related information to the second network node 13.

Some non-limiting examples of conditions may be: the attempt(s) to transmit any DL message being part of the handover execution process, namely the processes of random access to the target cell and RRC reconfiguration of the UE to the target cell as per configuration established during handover preparation, failed due to DL shared channel detected as busy. the attempt(s) to transmit Random Access Response (Msg2) after receiving Random Access Preamble failed due to DL shared channel detected as busy. the attempt(s) to transmit Msg4 after receiving Msg3 failed due to DL shared channel detected as busy. the attempt(s) to transmit Msg B after receiving Msg A failed due to DL shared channel detected as busy. the attempt(s) to transmit any of Msg2, Msg4, Msg B failed due to DL shared channel detected as busy. the time elapsed for sensing the shared channel in DL while attempting to transmit all the DL messages comprised in the reconfiguration with synchronization, e.g., for transmitting both Msg2 and Msg4, or for transmitting Msg B,

■ for failed handover execution(s), or successful handover execution(s), or both failed and successful handover execution(s) the time elapsed for sensing the shared channel in DL while attempting to transmit any of the DL messages comprised in the reconfiguration with synchronization

■ for failed handover execution(s), or successful handover execution(s), or both failed and successful handover execution(s) the time elapsed for sensing the shared channel in DL while attempting to transmit at least one the DL messages comprised in the reconfiguration with synchronization

■ for failed handover execution(s), or successful handover execution(s), or both failed and successful handover execution(s) the time elapsed for sensing the shared channel in DL while attempting to transmit all the DL messages comprised in the reconfiguration with synchronization, e.g., for transmitting both Msg2 and Msg4, or for transmitting Msg B, is above a certain percentage of a handover supervision timer running at the target network node,

■ as one option the condition also comprises that the handover failed, e.g. a handover supervision timer running at the target network node expired,

■ as another option the condition also comprises that the handover was successful, which also means that the handover supervision timer running at the target network node did not expire and the T304 timer at the UE did not expire,

■ as yet another option the condition applies irrespective of the outcome (success or failure) of the handover. the time elapsed for sensing the shared channel in DL while attempting to transmit all the DL messages comprised in the reconfiguration with synchronization, e.g., for transmitting both Msg2 and Msg4, or for transmitting Msg B, is above a certain percentage of the actual handover execution time at the first network node 12, the time elapsed for sensing the shared channel in DL while attempting to transmit at least one of the DL messages comprised in the reconfiguration with synchronization, e.g., Msg2, Msg4, Msg B, is above a certain percentage of a handover supervision timer running at the first network node 12,

■ as one option the condition also comprises that the handover failed, e.g., a handover supervision timer running at the first network node 12 expired,

■ as another option the condition also comprises that the handover was successful, which also means that the handover supervision timer running at the first network node 12 did not expire,

■ as yet another option the condition applies irrespective of the outcome (success or failure) of the handover. the time elapsed for sensing the shared channel in DL while attempting to transmit at least one of the DL messages comprised in the reconfiguration with synchronization, e.g., for transmitting both Msg2 and Msg4, or for transmitting Msg B, is above a certain percentage of the actual handover execution time at the first network node 12, the accumulated time spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or to transmit Msg B exceeds a certain threshold time,

■ as one option the condition also comprises that the handover failed,

■ as another option the condition also comprises that the handover was successful,

■ as yet another option the condition applies irrespective of the outcome (success or failure) of the handover, the time spent sensing the shared channel in the DL for attempt(s) to transmit Msg2, Msg4 or MsgB exceeds a certain threshold time,

■ as one option the condition also comprises that the handover failed

■ as yet another option the condition applies irrespective of the outcome (success or failure) of the handover the attempt(s) to transmit SSB(s) for certain amount of time failed due to DL shared channel detected as busy the actual handover execution time at the target network node the handover supervision timer running at the target network node

In addition, the second network node 13 may indicate in the SECOND MESSAGE if the DL LBT related information should be reported one time upon the fulfillment of any one of condition. Alternatively, the source network node can indicate to report the DL LBT impact information every time a condition is fulfilled. Also, the second network node 13 may indicate when to stop reporting DL LBT related information.

Furthermore, the second network node 13 may indicate in the SECOND MESSAGE one or more of the following:

During the preparation of a conditional handover (CHO), the second network node 13 may include in the SECOND MESSAGE a request to the (candidate) first network node 12 to record and later report DL LBT issue information for a certain time period e.g. starting upon reception of the SECOND MESSAGE.

During the preparation of a conditional handover (CHO), the second network node 13 may include in the SECOND MESSAGE a request to the (candidate) first network node 12 to record and later report DL LBT issue information for a time period starting at the reception of the SECOND MESSAGE in the candidate first network node 12, and ending when the CHO has been executed towards the candidate first network node 12 or when the candidate first network node 12 receives a HANDOVER CANCEL XnAP message from the second network node 13.

In addition to the above, a network node may send, unrelated to any handover or conditional handover or any other mobility procedure, a message to another network node, wherein the message contains a request to the receiving network node to record and later report DL LBT related information for a certain time period e.g. starting upon reception of the message containing the request.

A network node may send, unrelated to any handover or conditional handover or any other mobility procedure, a message to another network node, wherein the message contains a request to the receiving network node to record and report DL LBT issue information until further notice. The requested reporting may be periodic with a reporting period indicated in the request message or event-triggered with the triggering event(s) indicated in the request message.

A network node may send, a message, unrelated to any handover or conditional handover or any other mobility procedure preparation, to another network node, wherein the message contains a request to the receiving network node to record and report DL LBT related information after the completion of any handover preparation procedure. The requested reporting may be periodic with a reporting period indicated in the request message or event-triggered with the triggering event(s) indicated in the request message. The requested reporting may be configured to last for a specific time window.

Scenario A.2: DL LBT related information for handovers incoming from a certain neighbour/source cell controlled by the second network node 13 to a certain target cell controlled by the first network node 12 having the role of target network node.

The same embodiments as for scenario A.1 can be reused in scenario A.2.

Scenario B: DL LBT related information for the handovers incoming from any RAN node during an observed time interval

Fig. 6b is a combined signalling and flowchart scheme according to some embodiments herein.

Action 611. The first network node 12 obtains a request indication for providing information associated with a LBT procedure carried out by the first network node 12 for a HO of a UE. For example, the first network node 12 may receive, from the second network node 13 or another network node, a request e.g. subscription to receive information related to a LBT procedure. The request may be comprised in a second message from a requesting network node, wherein the request is to record and report DL LBT related information upon a condition being fulfilled. The condition may be comprised in the message or preconfigured at the first network node 12. Action 612. The first network node 12 may determine that at least one handover execution of a UE failed due to DL LBT impact at the first network node 12, wherein the corresponding handover preparation was initiated by any other network node.

Action 613. The first network node 12 sends to the second network node 13 information associated with the LBT procedure carried out by the first network node 12 for the HO of the UE. The information may comprise DL LBT related information, and the first network node 12 may send a first message comprising DL LBT related information, i.e. , the information. This may be performed irrespective whether the HO failed or succeeded. Based on that, the first network node 12 sends a THIRD MESSAGE to a certain second network node 13, which third message comprises DL LBT related information.

Action 614. The second network node 13 uses the received information for the sake of mobility robustness optimization. The second network node 13 may determine the HO failure types properly e.g., preventing to wrongly classify the HO failure caused by the downlink LBT issue as due to Too Early HO or due to HO to wrong cell. The second network node 13 may, for example, determine whether a peer RAN node is a good candidate for handover, based on the presence and intensity of DL LBT issues at the peer node, such as the first network node 12.

This scenario addresses the case of many handovers occurring from any source network node to a certain target network node. For this scenario, the methods are executed by the first network node 12 in the role of the target network node for any handover incoming from any cell of any second network node(s), such as the second network node 13 or another network node, towards any cell of the first network node 12.

In one embodiment, the first network node 12 determines that at least one handover execution failed due to DL LBT mpact at the first network node 12 wherein the corresponding handover preparation was initiated by any other network node. Based on that, the first network node 12 sends a THIRD MESSAGE to the certain second network node 13 which includes DL LBT related information.

In some non-limiting examples of realization, the THIRD MESSAGE may be a RESOURCE STATUS UPDATE XnAP message, or an ACCESS AND MOBILITY INDICATION XnAP message.

In non-limiting examples, the DL LBT related information may comprise an indication of the percentage of handover execution - initiated by any other network node - that failed during a certain reporting period due to blocked transmissions of any handover execution message in DL, such as Msg2 or Msg4 or Msg B in the first network node 12 due to a busy shared channel.

In non-limiting examples, the DL LBT related information may comprise an indication of the percentage of conditional handover execution - initiated by any other network node - that failed during a certain reporting period due to blocked transmissions of any of Msg2 or Msg4 or Msg B in the first network node 12 due to a busy shared channel.

In another non-limiting example, the DL LBT related information may comprise an indication of the average percentage of handover supervision timer running at the first network node 12, or the average percentage of the actual handover execution time, that were spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B, for the failed handovers.

In another non-limiting example, the DL LBT related information may comprise an indication of the average percentage of handover supervision timer running at the first network node 12, or the average percentage of the actual handover execution time, that were spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B, for the successful handovers.

- As one option, the THIRD MESSAGE may be sent periodically.

- As another option, the THIRD MESSAGE may be sent after a certain number of handovers have failed since the preceding transmission of the THIRD MESSAGE.

The first network node 12 may determine that at least for a successfully completed handover originated by any other network node, a certain DL LBT impact was determined at the first network node 12. Based on that, the first network node 12 sends a THIRD MESSAGE to a certain second network node such as the second network node 13, the THIRD MESSAGE comprising DL LBT related information.

In some non-limiting examples of realization, the THIRD MESSAGE may comprise a RESOURCE STATUS UPDATE XnAP message, or an ACCESS AND MOBILITY INDICATION XnAP message.

In non-limiting examples, the DL LBT related information may be an indication of the percentage of successfully completed handovers - initiated by any other network node - for which the time elapsed for sensing the shared channel for transmission of any of Msg2 or Msg4 or Msg B is above a certain percentage of handover supervision timer running at the first network node 12, or a certain percentage of the actual handover execution time. In non-limiting examples, the DL LBT related information may be an indication of the percentage of successfully completed conditional handovers - initiated by any other network node - for which the time elapsed for sensing the shared channel for transmission of any of Msg2 or Msg4 or Msg B is above a certain percentage of handover supervision timer running at the first network node 12, or a certain percentage of the actual handover execution time.

- As one option, the THIRD MESSAGE may be sent periodically.

- As another option, the THIRD MESSAGE may be sent after a certain number of successful handovers have occurred since the preceding transmission of the THIRD MESSAGE.

In one embodiment, which may be combined with any of the above embodiments of Scenario B, the first network node 12 such as the target network node, before sending the DL LBT impact information to the certain second network node 13 may receive from the second network node 13 a FOURTH MESSAGE including a request e.g..subscription to receive from the first network node 12 DL LBT related information for handover executions failed at the first network node 12 due to LBT issues in DL, for handovers from any other network node towards the first network node 12.

- An example of FOURTH MESSAGE may be a RESOURCE STATUS REQUEST XnAP message.

In addition, the second network node 13 may indicate in the FOURTH MESSAGE at least one condition to be fulfilled for the first network node 12 to send the DL LBT related information to the second network node 13. The conditions can be the same described for Scenario A.1. Fig. 6c is a combined signalling and flowchart scheme according to some embodiments herein.

Action 621. The first network node 12 obtains a request indication for providing information associated with a LBT procedure carried out by the first network node 12 for a HO of a UE. For example, the first network node 12 may receive, from the second network node 13 or another network node, a request (e.g. subscription) to receive information related to a LBT procedure. The request may be comprised in a 6th message from a requesting network node, wherein the request is to record and report DL LBT related information upon a condition being fulfilled. The condition may be comprised in the message or preconfigured at the first network node 12.

Action 622. The first network node 12 may determine that handover execution of a UE succeeded at the first network node 12.

Action 623. The first network node 12 sends to the second network node 13 information associated with a LBT procedure carried out by the first network node 12 for the HO of the UE 10. The information may comprise DL LBT related information, and the first network node 12 may send a first message comprising DL LBT related information, i.e. , the information. The first network node 12 may send a Fifth MESSAGE to a certain second network node 13, which third message comprises DL LBT related information.

Action 624. The second network node 13 uses the received information for the sake of mobility robustness optimization. The second network node 13 may determine the HO failure types properly e.g., preventing to wrongly classify the HO failure caused by the downlink LBT issue as due to Too Early HO or due to HO to wrong cell. The second network node 13 may, for example, determine whether a peer RAN node is a good candidate for handover, based on the presence and intensity of DL LBT issues at the peer node.

Scenario C: DL LBT related information for an individual handover execution.

This scenario addresses the case of individual handover from a source network node such as the second network node 13 to a target network node such as the first network node 12. For this scenario, the methods are executed by the first network node 12 in the role of the target network node of a specific handover procedure, and by the second network node 13 that is the source network node of the same handover procedure. Note: upon expiry of timer T304 the handover execution fails, and the UE 10 stores the handover failure information e.g., in VarRLF-Report. Note that the corresponding Radio Link Failure, RLF, report may or may not comprise an indication of LBT failures or consistent LBT failures related to the UL direction.

In one embodiment, the first network node 12 may determine that a certain handover execution failed due to DL LBT issue at the first network node 12. Based on that, the first network node 12 sends a FIFTH MESSAGE to the second network node 13 from which the handover originated, the FIFTH MESSAGE comprising DL LBT related information.

- In one example of the FIFTH MESSAGE may be the HANDOVER REPORT XnAP message, and the DL LBT related information may comprise a special value for the Handover Report Type information element (IE) indicating that the handover execution failed due to LBT issues in DL at the first network node 12 blocking the transmission of Msg2 (or Msg4, or Msg B). The first network node 12 may correlate the information of the DL LBT issue to the corresponding UE 10, the UE that failed in the HO execution, using a UE identifier such as source cell -radio network temporary identifier (RNTI), or target cell RNTI (C-RNTI) or any application protocol identifier such as the XnAP UE identifiers.

In another embodiment, the first network node 12 determines a certain DL LBT impact on a certain handover successfully completed at the first network node 12. Based on that, the first network node 12 sends a FIFTH MESSAGE to the second network node 13 from which the handover originated, the FIFTH MESSAGE comprising DL LBT related information.

- In one example of the FIFTH MESSAGE may be the HANDOVER REPORT XnAP message, and the DL LBT related information consists of a special value for the Handover Report Type IE indicating that the handover execution succeeded with delay in transmission of DL signals (e.g., Msg2, Msg4, Msg B) caused by channel access procedures at the first network node 12.

- In one example, the FIFTH MESSAGE may be the HANDOVER REPORT XnAP message, and the DL LBT related information consists of a new Information Element, e.g., a NR-U Information For HO IE providing information concerning the impact of shared spectrum operation i.e. NR-U during the handover execution e.g., the time elapsed to sense the shared channel before transmission of any of Msg2, Msg4, MsgB. In another example, the FIFTH MESSAGE may be a HANDOVER SUCCESS XnAP message.

In another example, the FIFTH MESSAGE may be an ACCESS AND MOBILITY INDICATION XnAP message, where the DL LBT issue information may be reported together with the Successful Handover Report for the handover affected by LBT issues.

The first network node 12 may correlate the information of the DL LBT related information to information associated with the corresponding UE 10 i.e., the UE that failed in the HO execution using a UE identifier such as source cell C-RNTI, or target cell C-RNTI or any XnAP based UE identifier.

In another embodiment, during the handover preparation phase of a certain handover the target network node e. the first network node 12 may receive from the source network node i.e. the second network node 13 a SIXTH MESSAGE including a request (e.g. subscription) to receive from the first network node 12 DL LBT related information associated to the handover execution. In one variant, the request concerns only the case of handover failure. In another variant, the request concerns only the case of handover success. In yet another variant, the request applies irrespective of the outcome of the handover. An example of the SIXTH MESSAGE can be the HANDOVER REQUEST XnAP message.

In addition, the second network node 13 may indicate in the SIXTH MESSAGE at least one condition to be fulfilled according to which first network node 12 determines to send or stop sending the DL LBT related information to the second network node 13. The conditions can be the same described for Scenario A.1.

DL LBT related information may comprise one or more or a combination of: amount of time spent at the first network node 12 for sensing the channel in DL during the handover execution procedure and the handover execution succeeded, amount of time spent at the first network node 12 for sensing the channel in DL during the handover execution procedure and the handover execution failed, time elapsed by sensing the channel in DL for failed handover execution, time elapsed by sensing the channel in DL for successful handover execution, an actual handover execution time at the first network node 12 or an aggregation of times for actual handover executions at the first network node 12, such as an average, a minimum, a maximum a handover supervision timer running at the first network node 12 a percentage of a handover supervision timer running at the first network node 12 and the time elapsed at the target node for sensing the channel in DL. a percentage of an actual handover execution at the first network node 12 and a time elapsed at the first network node 12 for sensing the channel in DL. an indication e.g., a flag indicating that a handover execution failed due to DL LBT issues, e.g. an indication that a handover execution for which the first network node 12, during the handover preparation phase, has been requested to send DL LBT related information, has failed. an indication e.g. a flag indicating that at least one handover execution failed due to DL LBT issues. an indication e.g. a flag indicating that at least one successful handover execution has been impacted e.g. delayed due channel access procedure. an indication e.g. a flag indicating that DL LBT issues were present for successful handover executions towards a certain target cell/node. an indication of the number of handover executions that failed during a time interval e.g., during a reporting time period due to DL LBT issues. an indication of the percentage of handover executions that failed during a time period e.g., during a reporting time period due to DL LBT issues. an indication e.g., a flag indicating the presence of DL LBT failures during handover execution. an indication e.g., a flag indicating that there is an impact in the handover execution time at the target node due to channel access procedure. an indication e.g., a flag indicating the presence of DL LBT failures during failed handover execution. an indication e.g., a flag indicating the presence of DL LBT failures during successful handover execution. a percentage of a handover supervision timer running at the first network node 12 and/or a percentage of the actual handover execution time spent at the first network node 12 during which the presence of DL LBT failures has been detected. In other word, the ratio between a handover supervision timer and/or the actual handover execution time and the time DL LBT issue was observed and/or detected during the HO execution and optionally also the configured handover supervision timer running at the first network node 12 and/or the value of the actual time elapsed for handover execution at the first network node 12. In an embodiment the time that DL LBT issue was detected/observed could be the sum of all the discontinuous time interval in which the DL LBT issue was detected or it can be the largest time interval in which the DL LBT issue was detected. a time period during which the presence of DL LBT failures has been detected, and optionally also the configured handover supervision timer running at the first network node 12 and/or the actual value of the handover execution time at the first network node 12. a percentage of handover supervision timer running at the first network node 12 and/or a percentage of the actual handover execution time at the first network node 12 elapsed by sensing the channel in DL for failed handover execution. a percentage of handover supervision timer running at the first network node 12 and/or a percentage of the actual handover execution time at the first network node 12 elapsed by sensing the channel in DL for successful handover execution, an accumulated percentage of the handover supervision timer running at the first network node 12 (and/or an accumulated percentage of the actual handover execution time) that was spent sensing the shared channel in the DL during attempts to transmit Msg2, Msg4 and/or Msg B. an accumulated time period spent sensing the shared channel in the DL during attempts to transmit Msg2, Msg4 and/or Msg B. an indication of the average percentage of a handover supervision timer running at the first network node 12 and/or an indication of the average percentage of accumulated percentage of the actual handover execution that was spent sensing the shared channel in the DL for attempts to transmit Msg2 and Msg4, or for attempts to transmit Msg B. an indication, indicating that at least one Random Access Response (Msg2) could not be transmitted due to DL LBT failures.

- An indication, indicating that at least one Msg4 could not be transmitted due to DL LBT failures. an indication, indicating that at least one Msg B could not be transmitted due to DL LBT failures. an indication, indicating that any one of Msg 2, Msg4, Msg B could not be transmitted due to DL LBT failures. an indication of time elapsed while attempting to transmit Random Access Response after successful reception of the corresponding Random Access Preamble an indication of time elapsed while attempting to transmit Contention Resolution Msg 4 after successful reception of Msg 3 an indication of time elapsed while attempting to transmit Contention Resolution Msg B after successful reception of Msg A an indication of time elapsed sensing the channel in the DL while attempting to transmit Random Access Response after successful reception of the corresponding Random Access Preamble an indication of time elapsed sending the channel in the DL while attempting to transmit Contention Resolution Msg 4 after successful reception of Msg 3 an indication of time elapsed sensing the channel in the DL while attempting to transmit Contention Resolution Msg B after successful reception of Msg A an indication of the number of LBT attempts for transmission of - or attempts of transmission of - respectively Msg2, Msg4 and/or Msg B an indication of the accumulated number of LBT attempts for transmission of - or attempts of transmission of - Msg2 and Msg4 an indication, indicating that DL transmission could not be transmitted due to DL LBT failure

- An indication, indicating that SSB transmissions could not be transmitted due to

DL LBT failure an indication of whether a UE subject to handover execution was configured with a contention-free random access preamble an indication that a UE subject to handover execution was configured with a contention-free random access preamble, but the contention-free random access preamble was not received an identifier, e.g. a C-RNTI or a “Source NG-RAN node UEXnAP ID" or a “Target NG-RAN node UEXnAP ID", of a UE subject to a handover execution the DL LBT issue information pertains to, or, optionally, an indication of that the first network node 12 does not know which UE the DL LBT issue information pertains to (which could be indicated by absence of a UE identifier, or, optionally, an identifier of the UE that the first network node 12 has determined as the most likely UE to be subject of a handover execution the DL LBT issue information pertains to, or, optionally, a list of identifiers of UEs which possibly could be subject to a handover execution the DL LBT issue information pertains to an indication of the SSB associated with the random access preamble initiating the handover execution the DL LBT issue information pertains to.

The DL LBT related information sent from the first network node 12 to the second network node 13 may cover various time periods, aspects and/or events. This coverage may be specified in a standard or may be indicated in a request from the second network node 13, e.g., in a HANDOVER REQUEST XnAP message, a RESOURCE STATUS UPDATE XnAP message, or an ACCESS AND MOBILITY INDICATION XnAP message, or it may be partly specified and partly indicated in a request from the second network node 13.

DL LBT issue information could cover one or more of the following non-limiting list of options:

The duration of handover supervision timer running at the first network node 12 the actual handover execution time spent at the first network node 12 until the handover is completed.

The handover execution and a possible subsequent RRC re-establishment procedure.

If a contention-free random access preamble was used, and the random access procedure was a 4-step random access procedure, the DL LBT issue information covers the Msg2 transmission attempts and, if any, the Msg4 transmission attempts.

If a contention-based random access preamble was used, and the random access procedure was a 4-step random access procedure, the DL LBT issue information covers the Msg4 transmission attempts (if any), but not the Msg2 transmission attempts.

If a contention-based random access preamble was used, and the random access procedure was a 4-step random access procedure, the DL LBT related information covers Msg4 transmission attempts, and may also cover Msg2 transmission attempts. In one variant, Msg2 transmission attempts are covered only if the Msg2 transmission eventually succeeded and a subsequently received Msg3 confirmed the UE’s identity. In another variant, Msg2 transmission attempts are covered even if Msg2 transmission failed and then the first network node 12 associates (with the Msg2 DL LBT issue information) an indication indicating that the first network node 12 does not know whether the random access preamble responding to was sent by the concerned UE.

If a 2-step random access procedure was initiated, and fallback to 4-step random access did not occur, the DL LBT related information covers the Msg B transmission attempts.

If a 2-step random access procedure was initiated, and fallback to 4-step random access occurred, the DL LBT related information covers the Msg B transmission attempts and the Msg4 transmission attempts.

The DL LBT issue information covers only failed transmissions of Msg2, Msg4 and/or Msg B i.e. cases where no transmission attempt of the concerned message was successful, e.g. because all transmission attempts were blocked by LBT failure.

The DL LBT issue information covers transmission attempts for Msg2, Msg4 and/or Msg B, even if the transmission of the concerned message was eventually successful i.e. irrespective of whether the message was eventually successfully transmitted or if none of the attempts to transmit the concerned message was successful.

Examples of implementation

In this section, some examples of implementations are reported. The parts that are new are marked in bold, italic and underlined.

First example.

A first example is indicated below, refers to Scenario 1 and presents additions to existing text in XnAP (TS 38.423 v17.3.0)

8.4.8 Handover Report

8.4.8.1 General

The purpose of the Handover Report procedure is to transfer mobility related information and NR-U related information associated to mobility between NG-RAN nodes.

The procedure uses non-U E-associated signalling.

8.4.8.2 Successful Operation

Figure 6d (8.4.8.2-1): Handover Report, successful operation NG-RAN nodei initiates the procedure by sending the HANDOVER REPORT message to NG- RAN node₂. When receiving the message NG-RAN node₂ shall assume that a mobility- related problem was detected.

If the Handover Report Type IE is set to "HO too early" or "HO to wrong cell", then NG- RAN nodei indicates to NG-RAN node₂ that, following a successful handover from a cell of NG-RAN node₂ to a cell of NG-RAN nodei, a radio link failure occurred and the UE attempted RRC Re-establishment or re-connected either at the original cell of NG-RAN node₂ (Handover Too Early), or at another cell (Handover to Wrong Cell). The detection of Handover Too Early and Handover to Wrong Cell events is made according to TS 38.300 [9].

The HANDOVER REPORT message may include:

- the Mobility Information IE, if the Mobility Information IE was sent for this handover from NG-RAN node2 (in case the NG-RAN node2 provided it more than once, the most recent Mobility Information IE is included in the HANDOVER REPORT message);

- the Source cell C-RNTI IE.

- the CHO Configuration IE, if the CHO Configuration IE was sent for this handover from NG-RAN node₂.

- the NR-U Information For HO IE, if the NR-U Information For HO Request IE was sent for this handover from NG-RAN node?.

If received, NG-RAN node₂ uses the above information according to TS 38.300 [9].

If the Handover Report Type IE is set to "Inter-system ping-pong", then NG-RAN node₂ shall deduce that a completed handover from a cell of NG-RAN node₂ to a cell in another system might have resulted in an inter-system ping-pong and the UE was successfully handed over to a cell of NG-RAN nodei (indicated with Target cell CGI IE).

If the Handover Report Type IE is set to " HO failed due to DL LBT issues blocking Msg 2 or Mso4 ", then NG-RAN nodei indicates to NG-RAN node? that the execution of a handover from a cell of NG-RAN node? to a cell of NG-RAN nodei, failed due to DL LBT issues blocking transmission of Mso2 or Mso4 in NG-RAN node j.

9.1.1.1 HANDOVER REQUEST

This message is sent by the source NG-RAN node to the target NG-RAN node to request the preparation of resources for a handover.

Direction: source NG-RAN node target NG-RAN node.

9.1.3.17 HANDOVER REPORT

This message is sent by NG-RAN nodei to NG-RAN node₂ to report a handover failure event, or other critical mobility problem. Direction: NG-RAN node i NG-RAN node ₂.

9.2.3. xx NR-U Information For HO

This IE contains NR-U information associated to handover execution.

Second example

A second example is indicated below, presenting additions to existing text in XnAP (TS 38.423 V17.3.0). 9.1.3.25 ACCESS AND MOBILITY INDICATION

This message is sent by NG-RAN nodei to transfer access and mobility related information to NG-RAN node₂.

Direction: NG-RAN node i NG-RAN node ₂.

In one alternative, the DL LBT related information is comprised in the Successful HO Report (SHR). In the example of realization above, this means that the Successful HO Report Container comprises the "NR-U Information for HO".

Third example

A third example is indicated below, and presents additions to existing text in XnAP (TS 38.423 V17.3.0). 8.4.10 Resource Status Reporting Initiation

8.4.10.1 General This procedure is used by an NG-RAN node to request the reporting of load measurements to another NG-RAN node.

The procedure uses non UE-associated signalling.

8.4.10.2 Successful Operation

Figure 6e (8.4.10.2-1): Resource Status Reporting Initiation, successful operation

(skip unchanged)

Interaction with other procedures

When starting a measurement, the Report Characteristics IE in the RESOURCE STATUS REQUEST indicates the type of objects NG-RAN node₂ shall perform measurements on. For each cell, NG-RAN node₂ shall include in the RESOURCE STATUS UPDATE message:

- the Radio Resource Status IE, if the first bit, "PRB Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1". If NG-RAN node₂ is a gNB and if the cell for which Radio Resource Status IE is requested to be reported supports more than one SSB, the Radio Resource Status IE for such cell shall include the SSB Area Radio Resource Status Item IE for all SSB areas supported by the cell. If the SSB To Report List IE is included for a cell, the Radio Resource Status IE for such cell shall include the requested SSB Area Radio Resource Status List IE; If the cell for which Radio Resource Status IE is requested to be reported supports more than one slice, and if the Slice To Report List IE is included for a cell, the Radio Resource Status IE for such cell shall, if supported, include the requested Slice Radio Resource Status Item IE

(skip unchanged)

- the NR-U Channel List IE, if the sixth bit, "NR-U Channel List Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1".

- the NR-U Information IE, if the seventh bit, "NR-U Information Request" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1

9.1.3.18 RESOURCE STATUS REQUEST

This message is sent by NG-RAN nodei to NG-RAN node₂ to initiate the requested measurement according to the parameters given in the message.

Direction: NG-RAN nodei NG-RAN node₂.

(skip unchanged)

Fig. 7 is a schematic overview of the first network node 12, such as the target network node, for handling communication in the communication network 1 according to embodiments herein. The first network node may be a target node of a HO of the UE from the second network node 13.

The first network node 12 may comprise processing circuitry 701, e.g., one or more processors, configured to perform the methods herein.

The first network node 12 and/or the processing circuitry 701 is configured to obtain the request indication for providing information associated with a LBT procedure carried out by the first network node 12 for a HO of one or more UEs. The first network node 12 and/or the processing circuitry 701 may be configured to obtain the request indication by receiving, from the second network node 13 or from another network node, the request to receive information related to a LBT procedure of a HO of one or more UEs. The request may be comprised in a request message from a requesting network node, wherein the request is to record and report DL LBT related information upon a condition fulfilled. The condition may be comprised in the message or preconfigured at the first network node 12.

The first network node 12 and/or the processing circuitry 701 is configured to send to the second network node 13, information associated with a LBT procedure carried out by the first network node 12 for a HO of a UE between one or more network nodes, such as the second network node 13, and one or more cells of the first network node 12 operating in shared spectrum.

The first network node 12 and/or the processing circuitry 701 may be configured to obtain the indication whether a HO has succeeded or failed due to an issue related to LBT procedure. The first network node 12 and/or the processing circuitry 701 may be configured to obtain the indication by determining that the HO failed due to LBT issues or receive information that HO failed due to LBT issues.

The information may comprise DL LBT related information, and the first network node and/or the processing circuitry 701 may be configured to send the first message comprising the DL LBT related information irrespective whether the HO failed or succeeded. The information may indicate one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

The first network node 12 may comprise a memory 705. The memory 705 comprises one or more units to be used to store data on, such as configuration data, threshold values, information, indications, failure information, HO parameter value(s), indices, configuration, indications, flags, thresholds, measurements, events and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the first network node 12 may comprise a communication interface 706, comprising such as a transmitter, a receiver, a transceiver and/or one or more antennas.

The methods according to the embodiments described herein for the first network node 12 are respectively implemented by means of e.g. a computer program product 707 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first network node 12. The computer program product 707 may be stored on a computer-readable storage medium 708, e g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 708, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first network node 12. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a first network node 12 for handling communication in the communication network, wherein the first network node 12 comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said first network node 12 is operative to perform any of the methods herein.

Fig. 8 is a schematic overview of the second network node 13, such as the source network node, for handling communication in the communication network 1 according to embodiments herein.

The second network node 13 may comprise processing circuitry 801 , e.g. one or more processors, configured to perform the methods herein.

The second network node 13 and/or the processing circuitry 801 is configured to receive from the first network node 12, information associated with a LBT procedure carried out by the first network node 12 for a HO of a UE between one or more network nodes and one or more cells of the first network node 12 operating in shared spectrum.

The second network node 13 and/or the processing circuitry 801 is configured to use the received information for performing a mobility robustness optimization.

The second network node 13 and/or the processing circuitry 801 may be configured to send the request indication, to the first network node 12, for providing information associated with a LBT procedure carried out by the first network node 12 for a HO of one or more UEs. The request indication may be comprised in a request message, requesting the first network node 12 to record and report DL LBT related information upon a condition fulfilled. The condition may be comprised in the request message.

The information may indicate one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

The second network node 13 and/or the processing circuitry 801 may be configured to use the received information by determining a HO failure type by classifying the HO failure as a downlink LBT failure based on the information.

The second network node 13 may comprise a memory 805. The memory 805 comprises one or more units to be used to store data on, such as data packets, mobility state of UEs, indications, mobility optimization, configuration data, grants, parameter(s), indices, configuration, indications, events and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the second network node 13 may comprise a communication interface 806, such as comprising a transmitter, a receiver, a transceiver and/or one or more antennas.

The methods according to the embodiments described herein for the second network node 13 are respectively implemented by means of e.g. a computer program product 807 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by second network node 13. The computer program product 807 may be stored on a computer-readable storage medium 808, e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 808, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second network node 13. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a second network node 13 for handling communication in the communication network, wherein the second network node 13 comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said second network node 13 is operative to perform any of the methods herein.

In some embodiments a more general term “node” is used and it can correspond to any type of radio-network node or any network node, which communicates with a wireless device, wired device and/or with another network node. Examples of network nodes are, router, modem, server, UE, NodeB, master (M)eNB, secondary (S)eNB, a network node belonging to Master cell group (MCG) or Secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, gNodeB, network controller, radio-network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, Remote radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), etc.

In some embodiments the non-limiting term wireless device or user equipment (UE) is used and it refers to any type of wireless device communicating with a network node and/or with another wireless device in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, proximity capable UE (aka ProSe UE), internet of things capable device, machine type UE or UE capable of machine to machine (M2M) communication, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles etc.

Embodiments are applicable to any RAT or multi-RAT systems, where the wireless device receives and/or transmit signals (e.g. data) e.g. New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

As will be readily understood by those familiar with communications design, that functions means or circuits may be implemented using digital logic and/or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and/or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of a wireless device or network node, for example.

Alternatively, several of the functional elements of the processing means discussed may be provided through the use of dedicated hardware, while others are provided with hardware for executing software, in association with the appropriate software or firmware. Thus, the term “processor” or “controller” as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware and/or program or application data. Other hardware, conventional and/or custom, may also be included. Designers of communications devices will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

With reference to Fig. 9, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3GPP-type cellular network, which comprises an access network 3211 , such as a radio access network, and a core network 3214. The access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points being examples of the receiver/transmitter node herein, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network 3214 over a wired or wireless connection 3215. A first UE 3291, being an example of the receiver/transmitter node, located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291 , 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 3221, 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown). The communication system of Fig. 9 as a whole enables connectivity between one of the connected UEs 3291, 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291, 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211 , the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig. 10. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311 , which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Fig.10) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Fig.10) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331 , which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides.

It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Fig. 10 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291, 3292 of Fig. 9, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 10 and independently, the surrounding network topology may be that of Fig. 9.

In Fig. 10, the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the user equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing, e.g., on the basis of load balancing consideration or reconfiguration of the network.

The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the performance since the mobility optimization may be improved and thereby provide benefits such as improved efficiency and/or may lead to better performance such as responsiveness and/or battery time of the UE.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311, 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 3311 , 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Fig. 11 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 11 will be included in this section. In a first step 3410 of the method, the host computer provides user data. In an optional substep 3411 of the first step 3410, the host computer provides the user data by executing a host application. In a second step 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 3440, the UE executes a client application associated with the host application executed by the host computer.

Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 12 will be included in this section. In a first step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 3530, the UE receives the user data carried in the transmission.

Fig. 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 13 will be included in this section. In an optional first step 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 3620, the UE provides user data. In an optional substep 3621 of the second step 3620, the UE provides the user data by executing a client application. In a further optional substep 3611 of the first step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 3630, transmission of the user data to the host computer. In a fourth step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Fig. 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 14 will be included in this section. In an optional first step 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 3720, the base station initiates transmission of the received user data to the host computer. In a third step 3730, the host computer receives the user data carried in the transmission initiated by the base station.

Modifications and other embodiments of the disclosed embodiments will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the embodiment(s) is/are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Abbreviation Explanation 3GPP 3rd Generation Partnership Project

5G 5th Generation

5GC 5G Core network

5GS 5th Generation System AMF Access and Mobility Management Function

ASN.1 Abstract Syntax Notation One

AT Attention

AR Augmented Reality

AS Access Stratum

CGI Cell Global Identity

CN Core Network

CP Control Plane

CU Central Unit

CU-CP Central Unit Control Plane

CU-UP Central Unit User Plane

DU Distributed Unit

DASH Dynamic Adaptive Streaming over HTTP

DC Dual Connectivity

DL Downlink

DNS Domain Name System

DU Distributed Unit

E-CGI E-UTRAN CGI eNB Evolved Node B I E-UTRAN Node B en-gNB A gNB acting as a secondary node in an EN-DC scenario (i.e. in a DC scenario with an eNB as the master node and a gNB as the secondary node. EN E-UTRAN-NR

EPC Evolved Packet Core

EPS Evolved Packet System

E-UTRA Evolved UTRA

E-UTRAN/EUTRAN Evolved UTRAN gNB Radio base station in NR

HSS Home Subscriber Server

HTTP Hypertext T ransfer Protocol

I AB Integrated Access and Backhaul

ID Identifier/ldentity

IE Information Element

LTE Long Term Evolution

MAC Medium Access Control MCC Mobile Country Code

MCE Measurement Collection Entity I Measurement Collector Entity

MDT Minimization of Drive Tests

MME Mobility Management Entity

MNC Mobile Network Code

MTSI Multimedia Telephony Service for IMS

N3IWF Non-3GPP Interworking Function

NG Next Generation

NG The interface between an NG-RAN and a 5GC.

NGAP NG Application Protocol

NG-RAN NG Radio Access Network

NID Network identifier

NR New Radio

NWDAF Network Data Analytics Function

O&M Operation and Maintenance

OAM Operation and Maintenance

PDCP Packet Data Convergence Protocol

PDU Protocol Data Unit

PLMN Public Land Mobile Network

QMC QoE Measurement Collection

QoE Quality of Experience

RAN Radio Access Network

RAT Radio Access Technology

RLC Radio Link Control

RNC Radio Network Controller

RRC Radio Resource Control

RVQoE RAN Visible QoE

S1 The interface between the RAN and the CN in LTE.

S1AP S1 Application Protocol

S-NSSAI Single Network Slice Selection Assistance Information

SMO Service Management and Orchestration

SRB Signaling Radio Bearer

TA Tracking Area

TCE T race Collection Entity I T race Collector Entity

TNGF Trusted Non-3GPP Gateway Function TWIF Trusted WLAN Interworking Function

UDM Unified Data Management

UE User Equipment

UMTS Universal Mobile Telecommunication System

URI Uniform Resource Identifier

URL Uniform Resource Locator Uniform Resource Locator

UTRA Universal Terrestrial Radio Access

UTRAN Universal Terrestrial Radio Access Network

WLAN Wireless Local Area Network

Xn The interface between two gNBs in NR.

XnAP Xn Application Protocol

Embodiments.

Embodiment A1.

A method performed by a first network node for handling communication in the communication network, the method comprising obtaining a request indication for providing information associated with a LBT procedure carried out by the first network node for a HO of one or more UEs; and sending to the second network node, information related to LBT procedure carried out by the first network node for a HO of a UE between one or more network nodes and one or more cells of the first network node operating in shared spectrum.

Embodiment A2.

The method according to embodiment A1 , wherein obtaining the request indication comprises receiving, from the second network node or from another network node, a request to receive information related to a LBT procedure carried out by the first network node for a HO of one or more UEs.

Embodiment A3.

The method according to embodiment A2, wherein the request is comprised in a request message from a requesting network node, wherein the request is to record and report DL LBT related information upon fulfillment of one or more conditions .

Embodiment A4. The method according to embodiment A3, wherein the one or more conditions are comprised in the message or preconfigured at the first network node.

Embodiment A5.

The method according to any of the embodiments A1-A4, further comprising obtaining an indication whether a HO has succeeded or failed due to an issue related to LBT procedure in Downlink.

Embodiment A6.

The method according to embodiment A5, wherein obtaining the indication comprises determining that the HO failed due to LBT issues or receive information that HO failed due to LBT issues in Downlink.

Embodiment A7.

The method according to any of the embodiments A1-A6, wherein the information comprises DL LBT related information, and the first network node sends a first message comprising the DL LBT related information irrespective whether the HO failed or succeeded.

Embodiment A8.

The method according to any of the embodiments A1-A7, wherein the information indicates one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

Embodiment B1.

A method performed by a second network node for handling communication in a communication network 1, the method comprising receiving information related to an LBT procedure carried out by the first network node for a HO of a UE between one or more network nodes and one or more cells of the first network node operating in shared spectrum; and using the received information for performing a mobility robustness optimization

Embodiment B2.

The method according to embodiment B1, further comprising sending a request indication, to the first network node, for providing information related to an LBT procedure carried out by the first network node for a HO of one or more UEs.

Embodiment B3.

The method according to embodiment B2, wherein the request indication is comprised in a request message, requesting is to record and report DL LBT related information upon fulfillment of one or more conditions.

Embodiment B4.

The method according to embodiment B3, wherein the one or more conditions are comprised in the request message.

Embodiment B5.

The method according to any of the embodiments B1-B4, wherein the information indicates one or more LBT failures in DL that blocked or delayed a transmission of a DL message or of a DL signal.

Embodiment B6.

The method according to any of the embodiments B1-B5, wherein using the information comprises determining a HO failure type by classifying the HO failure as a downlink LBT failure based on the information.

Embodiment C1.

A first network node for handling communication in the communication network, wherein the first network node is configured to obtain a request indication for providing one or more information related to an LBT procedure carried out by the first network node for a HO of one or more UEs; and send to the second network node, information related to an LBT procedure carried out by the first network node for a HO of a UE between one or more network nodes and one or more cells of the first network node operating in shared spectrum.

Embodiment D1.

A second network node for handling communication in a communication network 1 , wherein the second network node is configured to receive from the first network node, information related to an LBT procedure carried out by the first network node for a HO of a UE between one or more network nodes and one or more cells of the first network node operating in shared spectrum; and use the received information for performing a mobility robustness optimization.

Claims

1. A method performed by a first network node (12) for handling communication in a communication network (1), the method comprising obtaining (401) a request indication for providing information associated with a listen before talk, LBT, procedure carried out by the first network node (12) for a handover, HO, of one or more user equipments, UE; and sending (403) to a second network node (13), information related to LBT procedure carried out by the first network node (12) for a HO of a UE between one or more network nodes and one or more cells of the first network node (12) operating in a shared spectrum.

2. The method according to claim 1 , wherein obtaining (401) the request indication comprises receiving, from the second network node (13) or from another network node, a request to receive information related to a LBT procedure carried out by the first network node (12) for a HO of one or more UEs.

3. The method according to claim 2, wherein the request is comprised in a request message from a requesting network node, wherein the request is to record and report downlink LBT related information upon fulfillment of one or more conditions.

4. The method according to claim 3, wherein the one or more conditions are comprised in the message or preconfigured at the first network node (12).

5. The method according to any of the claims 1-4, further comprising obtaining (402) an indication whether a HO has succeeded or failed due to an issue related to LBT procedure in downlink.

6. The method according to claim 5, wherein obtaining the indication comprises determining that the HO failed due to LBT issues or receive information that HO failed due to LBT issues in Downlink.

7. The method according to any of the claims 1-6, wherein the information comprises downlink LBT related information, and the first network node (12) sends a first message comprising the downlink LBT related information irrespective whether the HO failed or succeeded.

8. The method according to any of the claims 1-7, wherein the information indicates one or more LBT failures in downlink that blocked or delayed a transmission of a downlink message or of a downlink signal.

9. A method performed by a second network node (13) for handling communication in a communication network (1), the method comprising receiving (502) information related to a listen before talk, LBT, procedure carried out by a first network node (12) for a handover, HO, of a user equipment, UE, between one or more network nodes and one or more cells of the first network node (12) operating in a shared spectrum; and using (503) the received information for performing a mobility robustness optimization.

10. The method according to claim 9, further comprising sending (501) a request indication, to the first network node (12), for providing information related to an LBT procedure carried out by the first network node (12) for a HO of one or more UEs.

11. The method according to claim 10, wherein the request indication is comprised in a request message, requesting the first network node (12) to record and report downlink LBT related information upon fulfillment of one or more conditions.

12. The method according to claim 11 , wherein the one or more conditions are comprised in the request message.

13. The method according to any of the claims 9-12, wherein the information indicates one or more LBT failures in downlink that blocked or delayed a transmission of a downlink message or of a downlink signal.

14. The method according to any of the claims 9-13, wherein using (503) the information comprises determining a HO failure type by classifying the HO failure as a downlink LBT failure based on the information.

15. A first network node (12) for handling communication in a communication network, wherein the first network node (12) is configured to obtain a request indication for providing information related to a listen before talk, LBT, procedure carried out by the first network node (12) for a handover, HO, of one or more user equipments, UE; and send to a second network node (13), information related to an LBT procedure carried out by the first network node (12) for a HO of a UE between one or more network nodes and one or more cells of the first network node (12) operating in shared spectrum.

16. The first network node (12) according to claim 15, wherein the first network node (12) is configured to obtain the request indication by receiving, from the second network node (13) or from another network node, a request to receive information related to a LBT procedure carried out by the first network node (12) for a HO of one or more UEs.

17. The first network node (12) according to claim 16, wherein the request is comprised in a request message from a requesting network node, wherein the request is to record and report downlink LBT related information upon fulfillment of one or more conditions.

18. The first network node (12) according to claim 17, wherein the one or more conditions are comprised in the message or preconfigured at the first network node (12).

19. The first network node (12) according to any of the claims 15-18, wherein the first network node (12) is configured to obtain an indication whether a HO has succeeded or failed due to an issue related to LBT procedure in Downlink.

20. The first network node (12) according to claim 19, wherein the first network node (12) is configured to obtain the indication by determining that the HO failed due to LBT issues or receive information that HO failed due to LBT issues in Downlink.

21. The first network node (12) according to any of the claims 15-20, wherein the information comprises downlink LBT related information, and the first network node (12) is configured to send a first message comprising the downlink LBT related information irrespective whether the HO failed or succeeded.

22. The first network node (12) according to any of the claims 15-21 , wherein the information indicates one or more LBT failures in DL that blocked or delayed a transmission of a downlink message or of a downlink signal.

23. A second network node (13) for handling communication in a communication network (1), wherein the second network node (13) is configured to: receive from a first network node (12), information related to a listen before talk, LBT, procedure carried out by the first network node (12) for a handover, HO, of a user equipment, UE, between one or more network nodes and one or more cells of the first network node (12) operating in shared spectrum; and use the received information for performing a mobility robustness optimization.

24. The second network node (13) according to claim 23, wherein the second network node (13) is configured to: send a request indication, to the first network node (12), for providing information related to an LBT procedure carried out by the first network node (12) for a HO of one or more UEs.

25. The second network node (13) according to claim 24, wherein the request indication is comprised in a request message, requesting the first network node (12) to record and report downlink LBT related information upon fulfillment of one or more conditions.

26. The second network node (13) according to claim 25, wherein the one or more conditions are comprised in the request message.

27. The second network node (13) according to any of the claims 23-26, wherein the information indicates one or more LBT failures in downlink that blocked or delayed a transmission of a downlink message or of a downlink signal.

28. The second network node (13) according to any of the claims 23-27, wherein the second network node (13) is configured to use the information by determining a HO failure type by classifying the HO failure as a downlink LBT failure based on the information.

29. A computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the claims 1-14, as performed by the first network node and the second network node, respectively.

30. A computer-readable storage medium, having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the claims 1-14, as performed by the first network node and the second network node, respectively.