list-style="none">

a beam identifier;

an identifier of a beam-specific cell individual offset;

an index of a synchronization signal block; and

an index of a channel state information reference signal.

A beam identifier may be understood as any information which is able to identify the beam, which the mobile device was using at the time the time-to-trigger procedure was initiated, in particular even though the mobile device has switched the beam in the meantime in particular while the time-to-trigger procedure was still running. The beam related information may alone or together with further information (e.g. a cell identifier or a time stamp) allow or assist in identifying the beam. A beam identifier may for instance only have a size of in the order of bits. For instance, a beam identifier may be (at least temporarily) be unique (e.g. with respect to the network or the cell). A beam identifier may in particular be realized as an identifier of an (in particular beam-specific) cell individual offset (CIO). Generally, the cell-individual offset only applies to one or some of the beams of a respective cell. However, the cell individual offset may also apply to all beams of a cell.

In a preferred example, the beam related information is based on or comprises an index of a synchronization signal block (also referred to as SSB). For instance, in New Radio, a cell can send out up to 64 different SSBs, each for instance using a different beam of a different width and/or direction. Additionally or alternatively, the beam related information is based on or comprises an index of a channel state information reference signal (also referred to as CSI-RS). In addition to SSBs, a cell can send out separate CSI-RSs, where a single CSI-RS is allocated to a single user, or to multiple users which may be in a similar spatial direction. CSI-RS may use the same set of beams as CSI-RS, or a different set of beams, e.g. CSI-RS may use a finer spatial granularity, i.e. smaller beam widths. The CSI-RS may provide PDCCH and/or PDSCH, for instance. The SSB may be quasi co-located (QCL) with the CSI-RS, which can be understood as, simply speaking, the respective signals having gone through very similar conditions, such that detection of one signal can facilitate detecting the respective other signal.

In a preferred example, the stored beam related information is provided to the network as part of one or more of:

- a measurement report;
- a re-establishment request;
- a radio link failure report;
- a successful handover report.

The stored beam related information may in particular be provided to one or more of:

- the serving cell;
- the neighboring cell used as a target cell for a handover; and
- a third cell of the network.

A measurement report comprising the beam related information may in particular be provided from the mobile device of the first aspect to the RAN node of the second aspect (e.g. from the UE to the source or serving cell). A re-establishment request may in particular be provided from the mobile device of the first aspect to the RAN node of the second aspect (e.g. from the UE to the serving cell, the neighboring cell and/or a third cell (i.e. a cell which is neither the serving cell nor the neighboring cell of the handover)), e.g. depending on where the mobile device tries to re-establish the respective connection. A successful handover report may in particular be provided from the mobile device of the first aspect to the RAN node of the second aspect (e.g. from the UE to the neighboring cell). A radio link failure (also referred to as RLF) report may be provided from the mobile device of the first aspect to the RAN node of the second aspect (e.g. from the UE to the serving cell, the neighboring cell or a third cell), e.g. depending on where the radio link has failed and where the mobile device tries to re-establishes a radio link in order to send a respective radio link failure report.

Generally, that information (such as the beam related information) is provided to a cell of the network (such as the serving cell, the neighboring cell or any third cell) is understood to mean that the information is provided to the network entity, e.g. such as to a base station or a part thereof, operating the respective cell (or at least taking part in generating or creating the respective cell).

Since only the beam related information, such as an identifier, needs to be added to the respective request or report, the additional load on the air interface between the mobile device and the network can be kept very limited, when the beam related information is provided to the network.

In an example, the stored beam related information is provided to the network during or after the time-to-trigger procedure. Generally, as soon as the time-to-trigger procedure is initiated the respective beam used at that time and thus the corresponding beam related information can be identified and stored (or may already be stored due to other reasons). In one example, the beam related information may be provided to the network during the time-to trigger procedure, e.g. while the timer of the time-to-trigger procedure is still running. In another example, the beam related information may be provided to the network after the time-to trigger procedure or active, e.g. after the timer of the time-to-trigger procedure has expired. In one example, the beam related information may be sent to the network hours (e.g. up to 24, 48 or even more hours, for instance) later.

In one example, the method further comprises:

- switching to a new beam during the time-to-trigger procedure.

More specifically, the switching of the beam may happen after initiating or causing initiating the time-to-trigger procedure for the handover, but before the handover itself. The beam may be switched from a first beam (the beam which was used when the time to trigger procedure was initiated) to a second beam of the serving cell. However, the beam may also be switched again (to a third beam) thereafter. A reason for a switch of a beam may in particular be that the mobile device has moved within the serving cell to a location which is covered or better covered by a different beam. In particular in case many beams are used for the cell (which may be up to16, 32, 64 or even more beams per cell) a switch of the beam during the time-to-trigger procedure (which may be as long as 100 ms or even longer) happens quite regularly and are not an exception anymore. In case the beam is switched during the time-to-trigger procedure (e.g. while the timer of the time-to-trigger procedure is still running), the described approach has the advantage that the information related to the beam, which was used by the mobile device at the time of initiating the time-to-trigger procedure. In contrast to known approaches, which only store information about last connected cell or beam, which is, however, not necessarily (and when a beam switch has taken place certainly not) the same beam as the beam when the time-to-trigger procedure was started.

In an example, the method further comprises:

- receiving a handover command for a handover from the serving cell to the neighboring cell used as a target cell.

The handover command may be provided from the serving cell to the mobile device due to a measurement report (which may comprise the beam related information described above) sent from the mobile device to the serving cell. However, as described above, when the actual handover from the serving cell to the target cell is actually executed, the mobile device may have switched (once or even multiple times) the beam in the serving cell compared to the beam, which was used when the time-to-trigger procedure was initiated. Since the stored beam related information is provided to the network (e.g. by means of the measurement report), the network can use the obtained beam related information, when optimizing a parameter of the relevant beam (i.e. the beam used when the time-to-trigger procedure was started) related to handover procedures. As a result, the network can effectively avoid problems for future handovers.

In an example, the method further comprises:

- deleting the stored beam related information or allowing the stored beam related information to be deleted, if one or more of
  - a predetermined time has passed;
  - an acknowledgment for a measuring report, the measuring report comprising the stored beam related information, is received;
  - a handover command is received;
  - the time-to-trigger procedure is stopped; and
  - a further time-to-trigger procedure is initiated.

The stored beam related information may be deleted or allowed to be deleted if a predetermined time (e.g. after the information has been stored or after the timer of the time-to-trigger procedure has expired) has passed. For this, a (further) timer may be started and the information may be deleted or allowed to be deleted if the timer has expired. The stored beam related information may also be deleted or allowed to be deleted if an acknowledgment for a measuring report, the measuring report (e.g. sent by the mobile device to the network) comprising the stored beam related information, is received. The stored beam related information may also be deleted or allowed to be deleted if a handover command is received. In these two cases, the mobile device can assume that the beam related information was received by the network. The stored beam related information may also be deleted or allowed to be deleted if the time-to-trigger procedure is stopped (e.g. when the timer of the time-to-trigger procedure expires and, depending on the result of the evaluation of the measurement event condition, the measurement event is triggered or cancelled) and/or if a further time-to-trigger procedure is initiated. In either of these two cases, the mobile device may assume that the handover procedure was cancelled and that the previously stored beam related information will not be needed anymore. Only one, some or all of the above conditions may be applied and the beam related information may be deleted or allowed to be deleted e.g. if a single one of the respective conditions is fulfilled. Furthermore, it is also conceivable that combinations of the above conditions may be applied, e.g. the beam related information may only be deleted or allowed to be deleted if multiple conditions are fulfilled.

In an example, the beam related information is obtained as part of one or more of:

- a measurement report;
- a re-establishment request;
- a handover request;
- a handover report;
- a radio link failure report;
- a radio link failure indication; and
- a successful handover report.

The stored beam related information may in particular be obtained from one or more of:

- the mobile device;
- the serving cell;
- the neighboring cell used as a target cell for a handover; and
- a third cell.

As explained above, a measurement report, a re-establishment request, a radio-link failure report and a successful handover report (each comprising the beam related information) may each be obtained from the mobile device. A handover request (comprising the beam related information) may in particular be obtained at the neighboring cell from the serving cell. A handover report (comprising the beam related information) may in particular be obtained at the serving cell from the neighboring cell. A radio link failure indication (comprising the beam related information) may in particular be obtained from the serving cell, the neighboring cell or a third cell, e.g. depending on where the radio link has failed and where the mobile device tries to re-establishes a radio link.

In an example, the method further comprises:

- adding the obtained beam related information to a UE history.

The UE history may be the UE history stored in the RAN node, such as a RAN node of the serving cell. Apart from the obtained beam related information, the UE history may further comprise the last visited cells (e.g. the respective cell IDs) and the corresponding time of stay of a respective UE or mobile device. By additionally adding the beam related information allows the beam related information to be utilized by a serving cell, even after a successful handover of the UE to a neighboring cell, which normally causes the serving cell to delete any further UE context information of the UE handed over.

It is to be understood that the presentation of the embodiments disclosed herein is merely by way of examples and non-limiting.

Other features of the present disclosure will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the present disclosure, for which reference should be made to the appended claims. It should be further understood that the drawings are not drawn to scale and that they are merely intended to conceptually illustrate the structures and procedures described herein.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows an exemplary mobility scenario with slow and fast moving UEs crossing cell borders, in which exemplary embodiments of the present disclosure can be implemented;

FIG. 2 shows a diagram illustrating a beam based mobility scenario where exemplary embodiments of the present disclosure are implementable;

FIG. 3 shows a diagram of an exemplary communication network where exemplary embodiments of the present disclosure are implementable;

FIG. 4 shows a signaling diagram illustrating an exemplary handover processing, which is applicable to exemplary embodiments of the present disclosure;

FIG. 5 shows a flow diagram illustrating exemplary embodiments of the present disclosure;

FIG. 6 shows a flow diagram illustrating a further exemplary embodiment of the present disclosure;

FIG. 7 shows a flow diagram illustrating a further exemplary embodiment of the present disclosure;

FIG. 8 shows a flow diagram illustrating a further exemplary embodiment of the present disclosure;

FIG. 9 shows a flow diagram illustrating a further exemplary embodiment of the present disclosure;

FIG. 10 shows a flow diagram illustrating a further exemplary embodiment of the present disclosure;

FIG. 11 shows a flow diagram illustrating a further exemplary embodiment of the present disclosure;

FIG. 12 is a block diagram of an exemplary embodiment of an apparatus according to the present disclosure;

FIG. 13 is a block diagram of an exemplary embodiment of a base station; and

FIG. 14 is a schematic illustration of examples of tangible and non-transitory computer-readable storage media.

DETAILED DESCRIPTION OF THE FIGURES

The following description serves to deepen the understanding of the present disclosure and shall be understood to complement and be read together with the description of example embodiments of the present disclosure as provided in the above SUMMARY section of this specification.

The present disclosure addresses mobility scenarios in a cellular and mobile communication network. The Mobility Robustness Optimization (MRO) is a method to optimize mobility parameters in order to minimize failures, unnecessary handovers etc. In conventional networks, MRO may for instance optimize the “cell-individual offset” (CIO) which is one of the main mobility parameters controlling the handover. A serving cell configures different CIOs for different neighbours in the cell, i.e. the network can control the handover separately for every cell pair.

An example is given in FIG. 1. It shows a cellular network comprising base stations BS and different cells C1, C2, C3 and C4. Cell C1 has several neighbours, e.g. cell C2, cell C3 and ell C4. The boundary between cell C1 and cell C3 may be dominated by fast cars moving on a street. The boundary between the same cell C1 and a different neighbour cell C4 may be dominated by a park-like area with pedestrian or even static users.

With conventional MRO, the network collects statistics for every cell boundary. For instance, the boundary C1→C3 may show failures due to “too late handovers” caused by the fast users on the street, whereas the boundary C1→C4 may show “too early handovers” or ping-pongs caused by the slow or static pedestrians. Using the CIO, the network can react by configuring a large CIO (e.g. +4 dB) on the street dominated boundary C1→C3, since this would upgrade the cell measurements of cell C3, thereby causing early handovers avoiding RLFs. Equivalently, the network configures a low CIO (e.g.-ldB) in the pedestrian-dominated boundary C1→C4, since this would downgrade the measurements of cell C4, thereby causing late handovers avoiding ping-pongs.

Instead of the CIO, the network may also configure different time-to-trigger (TTT) parameters for different neighbours. In this regard, a so called “alternative TTT” may be used. Such an alternative TTT is configured along with a list of neighbour cell IDs, so that the UE will apply the alternative TTT when the entry condition is triggered by one member of the list. The original sense was to configure a shorter TTT for small cell neighbours. In principle, this can also be applied in a similar way as the CIO. An alternative, shorter TTT can be configured for those neighbours with high speed boundaries, e.g. the cell C1 would configure a shorter TTT (e.g. 40 ms instead of the default of e.g. 100 ms) for neighbour cell C3. Automatic optimization can follow the same MRO principles as described above for the CIO.

In New Radio (NR), the use of beamforming methods becomes essential, in particular due to a spectrum at larger frequencies where more severe propagation conditions have to be compensated by beamforming gain. The different sections within a cell in FIG. 1 illustrate the area defined by different beams. In the following we will show how beamforming could be used to improve MRO performance.

A much more elegant solution is to perform a beam-specific optimization. From the figure, we observe that the beams increase the spatial resolution from cell (pair) level to beam (pair) level. The street on the boundary C1→C2 is originated in one beam, and the park-like pedestrian area cover other beams. This seems to be a much more natural grouping than the velocity. Hence, the network may

- Set up beam-specific handover statistics;
- Optimize different CIO for different beam (pair) s;
- Configure different CIOs depending on the beams that the UE is moving in.

This allows beam-specific MRO in a sense that the network creates beam specific key performance indicators and derives beam specific CIOs. The UE is not involved in this invention. This implies that the network has to reconfigure the UE with a new CIO whenever the UE is switched to a new beam. Furthermore, the network has to make its evaluation with existing information.

However, in some situations, MRO can make bad decision when based on existing information. Assume the following scenario where the beam is switched while the TTT procedure is running:

- The UE is connected to cell A/beam 1 and uses Ocn1.
- The entry condition of a measurement reporting event (e.g. A3) is fulfilled and TTT procedure is started.
- While TTT procedure is running, the UE is switched to beam 2 and selects a new Ocn2.

In this situation different problems can arise:

- 1. The TTT timer expires, a measurement report is sent, and a handover to cell B is initiated and successfully executed.
  - a. However, the UE is handed over back to the original cell A shortly after the handover to cell B (usually called a “ping-pong”).
  - b. However, the UE suffers an RLF in cell B shortly after the handover to cell B (usually called “too early handover” or “handover to wrong cell”, depending on whether the UE will re-establish in the original cell A or in a new (third) cell C).
- 2. The TTT timer expires, a measurement report is sent, and a handover to cell B is initiated, but fails (so called Handover Failure).
- 3. A Radio Link Failure happens before the handover is initiated. This may happen wither before the TTT timer expires, or when the measurement report is not received by cell A, or when the handover command is not received by the UE. This is typically called “too late handover”.

MRO procedures are designed to identify that cell A has done a bad handover decision, and to enable cell A to correct optimize the parameters for the decision for future handovers. To this end, several messages via X2 interface are supported, e.g. an RLF indication and or a handover report.

When extending the concept of MRO to be beam-specific, it is desirable to identify, which of the beam specific CIOs has to be changed, i.e. which is the “guilty” beam the parameter settings of which should be corrected.

In the scenario illustrated above, it is unclear whether beam 1 or beam 2 is the “guilty” one, i.e. whether the CIO of beam 1 (connected beam when the TTT procedure was started) or of beam 2 (connected beam when measurement report is sent) should be corrected. We can already observe that changing the offset of beam 2 definitely cannot make the handover earlier, only a parameter change of beam 1 can effect that. It is also difficult to make the handover later by changing the offset of beam 2. When switching to beam 2, the TTT procedure is already running, so the TTT procedure can only be stopped when already connected via beam 2 and restarted later on which may cause a rather significant postponing of the handover. We can conclude, that beam 1 should actually be changed on all the cases sketched above.

From simulations, it was derived that beam switches during the TTT procedure happen more often than expected, i.e. this is not a corner case. Especially, if many beams are used (e.g. 64 beams in Frequency Range 2), moving UEs will not stay long in a single beam. And if the time stayed in a single beam approaches a similar order of magnitude as the timer of the TTT procedure, the probability of such an event increases.

Today's approaches do not provide a solution to this problem.

The RRC re-establishment request contains mainly the last connected cell (PCI), the UE identifier in the last connected cell (C-RNT), and the re-establishment cause (e.g. RLF). Extending the request with beam information, however, would result in information with respect to the last connected beam. In case of a handover failure, this can even be different from beam 2 (new serving beam while the TTT procedure is running), since the UE may switch the beam again after the measurement report was sent to the source cell of the handover and before executing the random access to the target cell.

The RLF report contains information about the situation at the time when the failure happens and can thus only comprise information about beam 2, and not beam 1.

The UE history, which is stored by the cells and which comprises the last visited cells with a dwell time (time of stay), can be forwarded during a handover. Even if the UE history information is extended with beam information, the network would only able to identify the last beam before a handover, which again can be even different from beam 2 (since the beam could be changed again between sending out the measurement report and receiving the handover command).

It may be possible in some cases that the network makes a rough approximation of the beam at the time of starting the TTT procedure: For instance, assuming that the serving cell receives a measurement report, the serving cell knows/or may remember when the beam has been switched, and it knows the duration of the TTT interval, so it may determine the beam at the time of starting the TTT procedure. However, this suffers quite some uncertainty, since the network does not know how long the UE processing was until measurement report was finally sent, it does not know how long it took to send the measurement report (retransmissions), etc. So, this will now be very accurate. Even worse, such an approximation may be impossible for some other cases, e.g. RLF, where cell selection and RACH introduce additional sources of significant inaccuracy.

We can conclude that these approaches may not allow any beam resolution. If extended, they allow to determine the beam at the expiry of the TTT timer (or even a later beam), but not the beam at the time of starting the TTT procedure. Vendor-specific approximations in the network may be very inaccurate.

It is thus desirable to have a method which allows the network to determine the beam at the time of starting the TTT procedure, without increasing the complexity too much.

In the following the overall environment, in which embodiments of the present disclosure may be implemented, is first described with reference to FIGS. 2, 3 and 4.

FIG. 2 shows a diagram illustrating a beam based mobility scenario where examples of embodiments are implementable. As indicated in FIG. 2, it is assumed that a cell (in FIG. 2, a source cell as a cell currently serving a UE, and a target cell to which handover procedure of a UE is executed are shown, wherein the number of cells indicated in FIG. 2 is merely a simplified example for illustrative purposes) comprises a plurality (or at least one) of beams 1, 2 and 3, each of which may have similar or different properties, wherein the coverage areas of the respective beams may be overlapping or separate from each other. When a UE (not shown in FIG. 2) is moving e.g. from the source cell towards the target cell and a handover condition is fulfilled (e.g. one or more thresholds for connection quality to the source/target cell are met), a time-to-trigger procedure may be started and if the respective condition is still fulfilled at the end of the TTT, the connection is not only switched from the source cell to the target cell, but also from one or more of the (currently serving) beam(s) in the source cell to one or more of the beams in the target cell (indicated by arrows directed to the respective beams 1 to 3 of the target cell). That is, a UE is served by a specific beam at each moment of time. According to examples of communication systems, beam mobility within a cell is handled by specific layers of a protocol stack. For example, beam mobility is handled in lower layers, such as at Physical and MAC sublayer, and is transparent for higher layers. For example, in current cellular communication systems based on 3GPP standards, when beam operations are used, the handover is triggered at Layer 3 by using cell quality measurements of the source and target cell. Nevertheless, the UE is served by one beam in the source cell and after the handover will be served by one beam in the target cell.

5G introduces the New Radio technology and also an architecture for which the different sublayers of the RAN may be split into two logical entities in a communication network control element (like a BS or gNB), which are referred to as distributed unit (DU) and central unit (CU). For example, the CU is a logical node that controls the operation of one or more DUs over a front-haul interface (referred to as FI interface). The DU is a logical node including a subset of the gNB functions, depending on the functional split option. Since the management of beams is handled at physical and MAC layer, higher layers like layer 3 (network layer) may not have information regarding which beam is currently used for the UE (i.e. which beam serves the UE). For example, in case of the split configuration of CU/DU indicated above, the CU has no information about which beam is currently used to serve the UE.

This may have some impact on how a handover is performed/prepared, which may have an impact on the mobility optimization. In the following, different exemplifying embodiments will be described using, as an example of a communication network to which examples of embodiments may be applied, a communication network architecture based on 3GPP standards for 5G communication networks, without restricting the embodiments to such architectures, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communication networks having suitable means by adjusting parameters and procedures appropriately, e.g. 4G networks, Wi-Fi, worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad-hoc networks (MANETs), wired access, etc., Furthermore, without loss of generality, the description of some examples of embodiments is related to a mobile communication network, but principles of the invention can be extended and applied to any other type of communication network, such as a wired communication network.

As shown in FIG. 3, a communication element such as a user equipment (UE) 10 is connected to a cell 1, i.e. the base station or such as a gNB 20, via a communication beam of the cell 1 (e.g. beam 1 of the beams 1 to 3 of cell 1). In the example shown in FIG. 2, the gNB 20 is provided with a CU 23 and two DUs 21 and 22 being connected to the CU 23 by a FI interface.

Furthermore, as shown in the example of FIG. 3, there is a plurality of further cells (in FIG. 2, for illustrative purposes, two cells, i.e. cell 2 and cell 3 are shown) to which the UE 10 can connect, e.g. by executing a handover procedure. That is, cells 2 and 3 may be target cells for a handover while cell 1 is currently serving the UE 10 would be the source cell for a respective handover procedure. Similarly to cell 1, cells 2 and 3 are controlled by gNB 25 and 26, respectively, and each provides a plurality of beams 1 to 3.

As shown in FIG. 3, each gNB of the cells is connected to a core network, such as a 5GC, via respective interfaces, indicated as NG interfaces. Furthermore, each gNB of the cells is connected with each other by means of a specific interface, which is referred to e.g. as an Xn-C interface.

Generally, when conducting a handover for UE 10 in a communication network environment such as that shown in FIG. 3, the UE 10 sends, for example, an event based measurement report to gNB of the cell to which the UE 10 is currently connected, i.e. the serving gNB 20 which controls the source cell 1. For example, the report includes information related to the cell quality, beam measurement results, and/or beam IDs of communication beams in the source and target cells which are receivable (i.e. measurable) by the UE 10.

For optimizing the quality of handover processes, different additional features are considered. One of these features is the so-called mobility robustness optimization (MRO). MRO is a feature of a self-organized network (SON) for automatic detection and correction of errors in the mobility configuration allowing optimizing the quality of handover process. For example, the CIO between two cells can be modified to cope with the problem of too early or too late handover. Late handover means that the UE does not receive the handover command, e.g. due to weak signal, e.g. since the UE is moving faster than the handover parameter settings allow. The handover command does not reach the UE (already located in the target cell) so that connection is lost. By using information from the target cell, handover parameters can be adjusted. On the other hand, handover too early means that the signal strength in the target cell is too weak, and the connection is lost almost immediately.

FIG. 4 shows a signaling diagram illustrating a processing for a handover processing where examples of embodiments are applicable. In detail, FIG. 4 shows a signaling message flow in case of a 5G based system (e.g. like that shown in FIG. 3) where a an inter-gNB handover is conducted. The processing described in connection with FIG. 4 represents one possible starting point for procedures related to a handover control according to examples of embodiments. In S410, the source gNB initiates a handover and issues a handover Request over the Xn interface to the target gNB. In S420, the target gNB performs admission control. Then, in S430, the target gNB provides RRC configuration as part of a handover acknowledgement message. In S440, the source gNB sends a handover command to the UE in which it provides the RRC configuration. The handover command message includes at least cell ID and all information required to access the target cell so that the UE can access the target cell without reading system information. The access information to the target cell may include beam specific information. In S450, the UE moves the RRC connection to the target gNB. Then, in S460, the UE replies the handover complete message.

FIG. 5 illustrates a flow diagram 500 illustrating exemplary embodiments of the present disclosure for 3 different cases.

In S501, the entry condition of e.g. the A3 event is fulfilled, and the TTT procedure is started. In S502, the UE stores the ID of the current beam specific CIO or the ID of the current beam. According to the present disclosure it has been realized that the UE is able determine the actual beam, which is used at the time when the TTT procedure is started, and that the UE can log this information. Therefore, the UE logs or stores this beam related information, e.g. when the TTT procedure is stared or at least when the UE changes the CIO or the beam while the TTT procedure is running, so that the logged or stored information comprises information about the beam used when the TTT procedure was started, e.g. at least an identifier of the CIO or the beam before the changing.

In case the timer of the TTT procedure expires, S503, the UE will send a measurement report to the network including the stored information, S504. The network may then use this information to optimize the beam-specific CIOs, S505.

In case an RLF happens before the TTT timer expires, S506, the UE sends an RRC re-establishment request and/or creates an RLF Report (the RLF Report may be sent out immediately, or up to 48 hours later) to the network, S507. Again, the network may use this information to optimize the beam specific CIOs, S508.

In case the TTT timer is stopped (e.g. since the entry condition is no longer fulfilled), S509, the information stored by the UE may be deleted, S510.

As partly already illustrated above and as will be explained in more detail below, the UE may send the logged/stored beam related information to the network in different ways, e.g. in one or more of

- a measurement report, which may be triggered when the TTT timer expires (see S504, for instance);
- a re-establishment request in case an RLF happens before the TTT timer expires, or in case a handover failure happens (see S507, for instance);
- in an RLF report in case an RLF happens before the TTT timer expires, or in case a handover failure happens (see S507, for instance); and/or
- in a report sent after a successful handover (such a successful handover report is currently under discussion, but it is not specified yet).

The beam related information may in particular be a beam ID, which may in particular correspond to the index of the SSB or CSI-RS providing PDCCH and/or PDSCH, or to the SSB index that is Quasi co-located (QCL) with the CSI-RS providing PDCCH and/or PDSCH.

In the following, it will be illustrated in more detail how the network can solve each of the problems 1a, 1b, 2 and 3 outlined above.

FIG. 6 shows a flow diagram 600 illustrating a further exemplary embodiment of the present disclosure. This embodiment in particular deals with the above problem 1a of a ping-pong handover.

The source or serving cell A (such as source cell of FIG. 2 or cell 1 of FIG. 3) receives a measurement report comprising the beam related information previously stored at the UE (such as the ID of the CIO or of the beam used by the UE at the time of starting the TTT procedure), S601.

The source or serving cell initiates a handover to target cell B (such as target cell of FIG. 2 or cell 2 or 3 of FIG. 3), S602. The handover request message (e.g. a message via X2) contains the stored beam related information e.g. the measurement report with the beam related information. Additionally or alternatively, the UE may also add the stored information to the UE history. Such information is presently not stored in the UE history.

In this scenario, the handover from cell A to cell B succeeds, S603. The source cell A will delete any information regarding the UE handed over. Even if it does not delete it, it will no longer be able to identify the respective UE later on, i.e. all UE related information is lost in the source cell A at this point, as long as the stored information is not added to the UE history.

However, shortly after, another successful handover from cell B back to cell A happens (called a “ping-pong”), S604.

In one embodiment, in S605, cell A can solve the problem on the correct beam of cell A (e.g. by changing the parameters such that the handover is executed later) by using the stored information in the UE history (stored in S602), which is also part of the handover request.

In another embodiment, inS606, cell B may send a handover report message (e.g. via X2) to cell A, which includes the stored information (received at cell B in the previous handover request in S602) and optionally indicating a cause (such as “ping-pong”). This embodiment does not require extending the UE History as above, but it requires an extension of the existing handover report.

Using said obtained beam related information, when optimizing a parameter of the beam related to handover procedures in order to fix or solve the problem may in particular be based on any known and suitable MRO method. For instance, the corresponding beam-specific CIO may be increased or decreased either immediately, or the network may count certain beam-specific key performance indicators (e.g. ping-pong, too late HO, too early HO, wrong cell HO) and may then correct the beam-specific CIO when sufficient statistics are available.

FIG. 7 shows a flow diagram 700 illustrating a further exemplary embodiment of the present disclosure. This embodiment deals in particular with the above problem of a too early handover or wrong cell handover, referred to as problem 1b above.

In S701, the source or serving cell A (such as source cell of FIG. 2 or cell 1 of FIG. 3) receives a measurement report (MR) with the information previously stored at the UE and related to the beam which was used by the UE at the time of initiating the time-to-trigger procedure.

In S702, a successful handover happens from source cell A to target cell B (such as target cell of FIG. 2 or cell 2 or 3 of FIG. 3). Here again, the handover request contains the measuring report and thus the stored beam related information and the source cell A deletes all UE related information (UE context) after the successful handover.

A radio link failure happens shortly after, S703.

In S704, the UE sends an RRC re-establishment request to the original cell A (the case of a too early handover) or to a third cell C (the case of a wrong cell handover). This request may or may not contain the stored beam related information. Furthermore, for the sake of completeness, the UE may also prepare an RLF Report, but this is not relevant in this example.

In S705, either cell A or cell C sends an RLF indication message (e.g. via X2 interface) to cell B. Cell A will not be able to recognize the UE, since it has deleted the whole UE context earlier in S702.

However, cell B still has the UE context (so that it can recognize the UE) including the stored beam related information. In S706, cell B will realize that the UE was only shortly in cell B, so that there was no chance to initiate a proper handover. Therefore, it will identify cell A as having made a wrong handover decision and sends a handover report (e.g. via the X2 interface) to cell A comprising the beam related information and which may indicate a “too early handover” or a “wrong cell handover”. While cell A may have deleted the UE context at this point in time, cell A receives the beam related information with the handover report.

In S707, cell A can then use the received beam related information in order to adjust one or more beam parameters related to the handover in order to fix the problem on the correct beam, so that such errors are can be in the future.

FIG. 8 shows a flow diagram 800 illustrating a further exemplary embodiment of the present disclosure and dealing with the problem of a handover failure referred to as problem 2 above.

In S801, the source or serving cell A (such as source cell of FIG. 2 or cell 1 of FIG. 3) receives a measurement report (MR) with the information previously stored at the UE and related to the beam which was used by the UE at the time of initiating the time-to-trigger procedure.

In S802, the UE correctly receives a handover command for a handover to target cell B (such as target cell of FIG. 2 or cell 2 or 3 of FIG. 3).

However, in S803, the handover fails, e.g. because the target cell B is still too weak, and the RACH fails.

In S804, the UE sends an RRC connection re-establishment to the target cell B, with or without the stored beam related information.

In S805, the target cell B sends an RLF indication to cell A (e.g. via X2 interface).

In S806, cell A optimize respective parameters, as it still has the UE context including the stored information from the measurement report.

FIGS. 9 and 10 now illustrate two examples for the case of a too late handover, referred to as problem 3 above. While FIG. 9 deals with the case where an RLF occurs before the TTT timer has expired, FIG. 10 deals with the case where the RLF occurs after the TTT timer has expired and a measurement report was successfully received by the network.

FIG. 9 shows a flow diagram 900 illustrating a further exemplary embodiment of the present disclosure pertaining to the case of an RLF during the TTT procedure.

In S901, an RLF occurs while the TTT timer is running in serving cell A (such as source cell of FIG. 2 or cell 1 of FIG. 3).

In S902, the UE sends an RRC connection re-establishment request with the beam related information stored at the UE and relating to the beam in use during the start of the TTT timer to cell B (such as target cell of FIG. 2 or cell 2 or 3 of FIG. 3). Alternatively or additionally, the UE may send an RLF report with the beam related information stored at the UE to cell B. This might be sent out immediately or up to 48 hours later.

In S903, cell B sends an RLF indication message to cell A (e.g. via the X2 interface). The RLF indication message contains the beam related information from the re-establishment request or the RLF report.

In S904, cell A can then use the received beam related information (received in the RLF indication) in order to adjust one or more beam parameters related to the handover in order to fix the problem on the correct beam of cell A.

FIG. 10 shows a flow diagram 1000 illustrating a further exemplary embodiment of the present disclosure pertaining to the case of an RLF after the measurement report was received and thus after the TTT timer has expired.

In S1001, the serving cell A (such as source cell of FIG. 2 or cell 1 of FIG. 3) receives a measurement report from the UE with the beam related information stored at the UE and relating to the beam in use during the start of the TTT timer.

In S1002, an RLF occurs, e.g. because the handover command has not reached the UE since the UE is may already be too far away from the serving cell A.

In S1003, the UE sends an RRC connection re-establishment request to cell B (such as target cell of FIG. 2 or cell 2 or 3 of FIG. 3), which may or may not comprise the stored beam related information.

In S1004, cell B sends an RLF indication to cell A.

In S1005, cell A has still the UE context and can then use the received beam related information (received in the measurement report) in order to adjust one or more beam parameters related to the handover in order to fix the problem on the correct beam of cell A.

In another RLF scenario, the TTT timer expires and a measurement report (including the beam related information) is sent out by the UE, but the network may not receive the measurement report, e.g. because of bad uplink radio conditions. In that case an RLF is very likely, and then the question arises how long the UE will keep the stored beam related information. At some point in time, the information gets outdated and should not be stored forever.

While in one embodiment, the UE deletes the stored information when TTT timer expires, this would however not solve the above described scenario where the measurement report is lost. The CIO in the original beam triggered the measurement report too late and the network would then only be aware of the last connected beam, as the measurement was lost and the stored beam related information would not be available anymore when the RLF happens.

Thus, in another embodiment, the UE instead keeps the beam related information after TTT timer expires and only deletes it in at least one of the following cases:

In case another TTT procedure is started (the previously stored beam related information will be overwritten in this case).

- In case the measurement report is fully acknowledged (then the UE can make sure that the information is in the network).
- In case a predetermined time has passed, e.g. a configurable time period has expired after the TTT procedure (e.g. the UE starts a new timer “Txxx” when the TTT timer expires, and deletes the information when the timer “Txxx” expires. The timer “Txxx” can be stopped when the information is deleted due to any other reason.
- In case a handover command is received.

An example of such an embodiment is illustrated in FIG. 11 pertaining to the scenario of a too late handover or an RLF when the MR is not received.

In S1101, the TTT timer expires and the UE sends out a measurement report, but the MR is not received by the serving cell A (such as source cell of FIG. 2 or cell 1 of FIG. 3). Here it would not be relevant whether or not the stored information is included in the MR, as the MR is lost anyway.

IN S1102, the UE now keeps the stored beam related information and starts a timer “Txxx”.

However, as mentioned, in another embodiment the UE may also delete the stored beam related information when the TTT timer expires.