Patent Description:
In a communication network, handovers between cells are used to enable devices to have service within the coverage area of the communication network. In some instances, handovers may fail or may cause certain unwanted anomalies, such as ping-pongs, short stays, and remote cell handover anomalies. Therefore, it may be beneficial to develop solutions which enable reducing said handover failures and anomalies. <CIT> (<NUM>-<NUM>-<NUM>), discloses a radio base station configured to store a handover parameter for controlling handover of radio terminals, in association with moving velocity information indicating a moving velocity of a given radio terminal; and configured to detect handover failure and to adjust the handover parameter associated. <CIT> (<NUM>-<NUM>-<NUM>), discloses a method to select a handover policy based on a mobility speed group. Handover parameter values are provided to a mobile communication device through a dedicated signalling message. <CIT> (<NUM>-<NUM>-<NUM>), discloses a method involving retrieving data associated with historical behaviour of user within telecommunication network.

According to an aspect, there is provided the subject matter of the independent claims. Some embodiments are defined in the dependent claims.

In the following some embodiments will be described with reference to the attached drawings, in which.

Embodiments described may be implemented in a radio system, such as in at least one of the following: Worldwide Interoperability for Micro-wave Access (WiMAX), Global System for Mobile communications (GSM, <NUM>), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunication System (UMTS, <NUM>) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), and/or LTE-Advanced.

Another example of a suitable communications system is the <NUM> concept. <NUM> is likely to use multiple input - multiple output (MIMO) techniques (including MIMO antennas), many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates. <NUM> will likely be comprised of more than one radio access technology (RAT), each optimized for certain use cases and/or spectrum. <NUM> mobile communications will have a wider range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applications, including vehicular safety, different sensors and real-time control. <NUM> is expected to have multiple radio interfaces, namely below <NUM>, cmWave and mmWave, and also being integradable with existing legacy radio access technologies, such as the LTE. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and <NUM> radio interface access comes from small cells by aggregation to the LTE. In other words, <NUM> is planned to support both inter-RAT operability (such as LTE-<NUM>) and inter-RI operability (inter-radio interface operability, such as below <NUM> - cmWave, below <NUM> - cmWave - mmWave). One of the concepts considered to be used in <NUM> networks is network slicing in which multiple independent and dedicated virtual sub-networks (network instances) may be created within the same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility. It should be appreciated that future networks will most probably utilize network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or cloud data storage may also be utilized. In radio communications this may mean node operations to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It should also be understood that the distribution of labor between core network operations and base station operations may differ from that of the LTE or even be non-existent. Some other technology advancements probably to be used are Software-Defined Networking (SDN), Big Data, and all-IP, which may change the way networks are being constructed and managed.

<FIG>, and <FIG> illustrate examples of a radio communication system to which some embodiments may be applied. The radio communication system may comprise a cellular communication system or may be a cellular communication system. Such cellular communication system may enable communication according to one or more cellular communication protocols, such as the Long Term Evolution (LTE), the LTE-Advanced (LTE-A), the LTE-Advanced Pro of the 3rd Generation Partnership Project (3GPP), or the <NUM> solutions (i.e. New Radio (NR)). However, the cellular communication system may additionally utilize techniques, such as Wireless Local Area Network (WLAN) (i.e. sometimes referred to as WiFi), e.g. for offloading. Cellular communication networks, such as the ones depicted in <FIG> are typically composed of at least one network element, such as a network element <NUM>, providing a cell <NUM>. The cell <NUM> may be, e.g., a macro cell, a micro cell, femto, or a pico-cell, for example. The network element <NUM> may be an evolved Node B (eNB) as in the LTE and LTE-A, a radio network controller (RNC) as in the UMTS, a base station controller (BSC) as in the GSM/GERAN, gNB as in the <NUM>, or any other apparatus capable of controlling radio communication and managing radio resources within the cell <NUM>. The network element <NUM> may be referred to as a base station or an access node, for example. Also, it is possible that the network element <NUM> provides more than one cell (i.e. two or more cells). As virtualization of the cellular communication systems advances, the cells of the communication network may be controlled by a server or servers utilizing one or more Remote Radio Heads (RRHs). That is, computing and decision making may be performed in one or more virtual or physical servers which control one or more RRHs at the field, for example.

Network element(s) of the cellular communication network may each provide one or more cells for providing radio resources to one or more terminal devices <NUM>. A terminal device may also be referred to as User Equipment (UE) as. As described, the functionality of the network element may be realized in many different ways: e.g. utilizing one physical entity configured to perform all tasks of the network element or utilizing two or more entities configured to interact with each other and provide the functionality of said network element.

The cellular communication networks may be composed of network nodes or elements similar to the network element <NUM>, each network node or element controlling a respective cell or cells. For example, the cellular communication network may comprise a plurality of network elements providing cells and service for a certain area. The network elements may be connected to each other such that data transfer between the network elements is possible. For example, X2-interface between eNBs may be utilized. For example, Xx-interface between gNBs (or gNodeB) may be utilized. However, other solutions may also be possible (e.g. wireless data transfer or some other communication technique). It is also pointed out that not all network elements and/or cells of the cellular communication network necessarily are similar or same, but may wary between implementations. Hence, the cellular communication network may be a heterogeneous network comprising one or more macro and one or more femto cells. Further, the network elements of the cellular communication network may be connected via a core network interface to a core network of the cellular communication network or system. In an embodiment, the core network is called Evolved Packet Core (EPC) according to the LTE terminology. The core network may comprise a mobility management entity (MME), Home Subscriber Server (HSS), Application Server (AS) and a data routing network element. In the context of the LTE, the MME may track mobility of terminal devices <NUM>, and carries out establishment of bearer services between the terminal devices <NUM> and the core network. In the context of the LTE, the data routing network element may be called a System Architecture Evolution Gateway (SAE-GW). It may be configured to carry out packet routing to/from the terminal devices <NUM> from/to other parts of the cellular communication network and to other systems or networks, e.g. the Internet. It needs to be understood that similar entities may be used with different communication solutions, such as <NUM>, but different terms may be used. MME may or may not be called MME in <NUM>. However, a similar entity or interacting entities performing similar functions may still be used.

With reference to <FIG>, UE <NUM> or UEs may in communication (i.e. one or more communication links between the entities) with the cellular communication network as it is known in the art. Communication may comprise unicast, broadcast, multicast, bidirectional communication and unidirectional communication to name a few examples. The UE <NUM> may be a mobile phone, tablet computer, computer and the like. The UE <NUM> may a part of a vehicle or provide a vehicle communication capabilities. Hence, the UE <NUM> may provide a vehicle-related (V2X) communication services. The cellular communication network may thus comprise one or more V2X UEs (V2X UE may mean or refer to a vehicular UE). The cellular communication network may additionally comprise regular UEs, such as mobile phones used by users to perform voice calls and the like.

Now with reference to <FIG>, a communication link <NUM> may be established between the network element <NUM> and the UE <NUM>, wherein the communication link may be used to provide services, such as V2X services, to the UE <NUM>. The UE <NUM> may move away from cell <NUM> to another cell <NUM> (i.e. trajectory <NUM>; UE's <NUM> initial position is indicated with a dash line object). The cell <NUM> may, for example, be controlled by different network element <NUM> or by the same network element <NUM>. In the example, the cellular communication network (or simply referred to as a network) may perform a handover of the UE <NUM> from cell <NUM> to cell <NUM>. This may require communication <NUM> between the network elements <NUM>, <NUM>. Said communication may refer to one or both direct communication between the network elements <NUM>, <NUM>, and communication via some other entity of the network. The handover may enable the UE <NUM> to be server by the cell <NUM> and be in communication with the network element <NUM> via link <NUM>. Thus, the service to the UE <NUM> may be maintained even though the UE <NUM> has left the cell <NUM>.

Vehicle communication is an enabler for various connected car use cases, such as broadcasting situation awareness messages for assisted driving, sending emergency alerts (e.g., braking, vulnerable road user detection) to increase safety, executing cooperative manoeuvres such as lane merging or platooning and more. Vehicular connectivity over 3GPP cellular technology is termed as C-V2X and is being standardized starting with LTE-A and its evolution into <NUM>. One particular V2X communication pattern is called vehicle to infrastructure, when the vehicles are connected to base stations (e.g., LTE eNBs, <NUM> gNBs) and exchange data with backend servers or other vehicles through the cellular communication network (e.g. RAT) (as opposed to device-to-device communication, where the data is exchanged directly between the UEs without going through the network). Vehicle to infrastructure communication is thus prone to handover related degradations as they move along their trajectories and the serving base station or cell changes. However, as shown in <FIG>, handovers may be used to provide continued service along the trajectory <NUM>. In general, handovers in cellular networks may initiated, by the network element <NUM>, based on radio measurements collected from the UEs (V2X or C-V2X context a vehicle may be referred to as an UE). the UE <NUM> may periodically report the received or measured power or quality of the current serving cell and nearby neighbour cells to the network, which may use the received information to decide when and to which target cell a handover is initiated (e.g. in <FIG> from cell <NUM> to cell <NUM>). Normally, handover triggers are based on a set of radio parameters (radio quality thresholds, offsets and hysteresis) defined at each network element between its own cells and all potential neighbouring cells. The handover parameters may be defined on the cell pair level; therefore, the same parameters may apply to all UEs that are connected to a given cell.

Connected vehicles using C-V2X technology may require stable and reliable connectivity to the cellular network to comply with the stringent quality and safety standards for assisted and automated driving use cases. Cellular connectivity may be disrupted even by successful handovers as the UE's radio connection (e.g. communication link <NUM>) to the current serving (source) cell <NUM> is terminated and then re-established to the target cell <NUM> (e.g. link <NUM>). During handover, the UE may have no connectivity with the network, i.e., it cannot send or receive any data (no communication with backend servers, no message exchange with nearby vehicles through the infrastructure). Vehicles may be more exposed to such events due to their higher speed than, e.g., pedestrian users; also, the impact of a handover interruption on a vehicular application may be higher than, e.g., on a web page download.

For example, in certain complex terrains and geographical situations, radio signal quality may change very abruptly as a function of the UE location and speed in a way unforeseen during radio planning. Therefore, a UE moving fast along a trajectory (e.g., road lane) may experience different handover anomalies. Referring once again to <FIG>, one such anomaly may a ping-pong handover anomaly. That is, if the trajectory <NUM> of the UE <NUM> would come back within cell <NUM>, the UE <NUM> may be handed over back to network element <NUM>. For example, the handover from cell <NUM> to cell <NUM> may have been unnecessary in such case if the cell <NUM> could have been used all the time to provide the needed service.

Another handover anomaly may be experienced in the example of <FIG> and referred to as short stay handover anomaly. For example, the UE <NUM> along its trajectory <NUM> moves through cell <NUM> provided by a network element <NUM>. Hence, the UE <NUM> may first be handed over to cell <NUM> and then to cell <NUM>, although one handover from cell <NUM> to cell <NUM> would have been sufficient. For example, due to high speed of the UE <NUM>, the stay within cell <NUM> is so short that it may not be beneficial to be used at all by the UE <NUM>. However, for stationary UEs and/or slow moving UEs, cell <NUM> may provide needed service and provide benefits for the network (e.g. cell offloading and the like).

A further anomaly may be seen in <FIG> showing cell <NUM> provided by network element <NUM>. In this case, the anomaly may be remote cell handover anomaly caused by, for example, unconventional radio environment. That is, cell <NUM> may not necessarily be configured to extend to area of the trajectory <NUM>, but due to some environmental cause, the UE <NUM> may measure said cell <NUM>, and possibly the network may determine that a handover from cell <NUM> to cell <NUM> is needed. For example, such unconventional radio environment may be caused by a water surface or structures (e.g. signals bouncing). Handover to remote cells may be problematic because the handover procedure execution (including C-plane negotiation between the source and target network elements <NUM>, <NUM>) may take longer than usual.

It is pointed out that such handovers may be successful from control plane procedural point of view but they may represent anomalies as they may cause degradation on the vehicular application level communication and functionality (e.g., increased delays and delay variation in vehicular control loops, inability to exchange messages required for safe cooperative manoeuvre completion, etc.) due to repeated connectivity disruption. The apparent success of the handovers themselves may make these anomalies invisible to traditional handover success based Key Performance Indicators (KPIs) and Operations Support System (OSS) tools, and thus they may trigger no optimization action or alarm. Therefore, even carefully planned and well operated networks today may contain significant amount of such hidden anomalies (e.g., concentrated at coverage areas with challenging radio propagation environment), that may cause issues to vehicular applications.

In addition to invisible anomalies, handovers may also fail due to unsuccessful procedural execution, e.g., interrupted by Radio Link Failure (RLF) due to too early or too late handover, or handover to wrong cell. Such failures may be visible through alarms or failure counters and may even be input to Self-Organizing Network (SON) functions (Automatic Neighbour Relation (ANR), Mobility Robustness Optimization (MRO)) with the objective to optimize the cell level handover parameters and reduce handover related connectivity failures. Still, as the handover parameters may be defined on the cell level, changing the parameters may consequently apply to all UEs attached to the same cell. On the other hand, the optimal handover point (or, ultimately, the decision whether certain handovers should be enabled at all) may be specific to individual UEs and their real-time mobility context or condition, i.e., motion trajectory, velocity, current and predicted future locations, antenna capabilities, etc. Even the same individual UE moving along the same mobility trajectory may benefit from different handover conditions depending on its actual context. Applying the same parameters to all UEs (even if the parameters are optimized by a SON or other function) means that there could still be individual UEs or certain mobility situations for which the common cell level configuration is not favourable. Such UEs may experience RLFs, handover failures or handover anomalies (e.g. ping-pong, short stay), disrupting the vehicular communication and possibly jeopardizing functionality and safety. Therefore, it may be beneficial to provide solutions which reduce such interruptions.

<FIG> illustrate a flow diagram according to an embodiment. Referring to <FIG>, a method in a cellular communication network (e.g. a vehicular network or comprising a vehicular network) comprises, upon detecting that a terminal device has or is going to have a mobility condition previously determined to be associated with a handover anomaly or failure, determining (block <NUM>) terminal device specific handover parameters for said terminal device to avoid said handover anomaly or failure; and causing utilizing (block <NUM>) said terminal device specific handover parameters in one or more handovers associated with the terminal device.

Block <NUM> may refer to different things explained later in more detail. However, causing utilizing the terminal device specific handover parameters (also referred to as UE specific handover parameters) may comprise, for example, transmitting said parameters to the terminal device for the terminal device to use said parameters. For example, the terminal specific handover parameters may comprise and/or indicate terminal device and/or cell pair specific handover threshold, handover hysteresis, handover time to trigger, and/or handover enablement/disablement. Hence, the terminal device and/or the network may use said parameters to perform one or more handovers related to the terminal device. Thus, for example, both the network and the terminal device may be aware which cell(s) are excluded as a possible target cell.

Said terminal device described with reference to <FIG> may be or comprise the UE <NUM>, for example. The handover anomalies may refer to different situations described with respect to <FIG>. Handover failure may refer to failure of the handover as generally understood by the skilled person. The cellular communication network may refer to cellular communication network(s) described with respect to <FIG> and the like. Hence, for example, the cellular communication network may comprise vehicular network(s). Utilizing said terminal device specific handover (HO) parameters may mean that said parameters are used in a handover (HO) or HO event regarding said terminal device. For example, said HO may refer to H0 from cell <NUM> to cell <NUM>. For example, utilizing said parameters detected HO anomalies may be avoided (e.g. network has previously detected that HO from cell <NUM> to cell <NUM> is not beneficial when the predicted trajectory is according to trajectory <NUM>; instead direct HO from cell <NUM> to cell <NUM> may be caused by said parameters).

So, in general, the cellular communication network (or simply network) may detect handover anomalies and/or failures, and use these detections in determining in determining the UE specific handover parameters. Determining and/or detecting one or more mobility conditions associated with handover anomalies or failures may be performed, by the network, in a separate step before detecting that a certain UE has such mobility condition. Said separate step, however, may be performed continuously and/or periodically to determine mobility condition(s) which are related to handover anomalies or failures. Therefore, the network may, based on determining a mobility condition of a UE, determine whether said mobility condition is associated with handover anomaly or failure based on previously detected mobility conditions of UE(s) (i.e. one or more UEs) which are already determined to be associated with handover anomaly or failure.

As one example with reference to <FIG>, the network may determine that trajectory <NUM> is related to and/or causes handover anomaly. Hence, once it detects such trajectory associated with a UE, the network may act accordingly. For example, the network may decide to exclude cell <NUM> or <NUM> as possible target cells. Hence, handover anomalies of <FIG> and <FIG> may not happen. It is noted that there may be many different ways to detect that the UE <NUM> has a certain mobility condition that is associated with a certain anomaly or failure. It is also pointed out that different UEs may have different mobility conditions and thus it may be beneficial to determine UE specific handover parameters. For example, a V2X UE may move with a higher speed than a mobile phone used by a pedestrian. These conditions may be indiated by the mobility condition. Hence, the network may utilize different handover parameters for one or more V2X UEs compared with other UEs (e.g. mobile phones) in the network.

As used in this application, mobility condition may refer to a certain context regarding mobility of the UE. Hence, for example, the mobility condition may comprise and/or be determined based on UE's trajectory, speed, and/or location(s) (e.g. current and/or future). On the other hand, the mobility condition may indicate or comprise sequence of serving cells. For example, referring to <FIG>, such sequence could be or comprise cell <NUM>, cell <NUM>, and cell <NUM> when a UE <NUM> is on trajectory <NUM>. Hence, detecting/predicting such cell sequence pattern can be used to trigger determining UE specific parameters that avoid detected anomaly (e.g. short stay in cell <NUM>). For example, the network may receive information on the UE <NUM> and determine, based on said information, UE's <NUM> mobility condition. Mobility condition may be indicated in many different ways, but the purpose may be to associate certain mobility conditions with handover anomalies or failures, and use such association to avoid certain handovers. if a mobility condition of the UE <NUM> matches a mobility condition associated with an anomaly or failure, the network may take certain action(s) to avoid said detected anomaly or failure. Action(s) may include excluding possible target cells and/or scheduling one or more handovers (e.g. delaying a handover or causing a handover to be performed earlier than normally). These actions may be controlled using the UE specific handover parameters. The use of UE specific handover parameters enables the network to customize handovers on the UE level. For example, such may cause reducing the number/intensity of handovers while maintaining full cellular service continuity. One possible use case of the provided solution may be to improve cellular V2X communications by eliminating or at least reducing handover anomalies such as ping-pongs, short stays and handover failures for individual vehicular UEs. The UE specific handover parameters may comprise and/or indicate UE and cell pair specific handover threshold, handover hysteresis, handover time to trigger, and/or handover enablement/disablement.

<FIG> illustrates an embodiment. Referring to <FIG>, the solution may utilize two different analytics engines <NUM>: long term analytics <NUM> and real-time analytics <NUM>. These analytics engines may be realized by the cellular communication network, e.g. by a network element or network elements of the network. For example, said analytics engines may be Virtual Networking Functions (VNFs), but can also be provided by physical entities. In an embodiment, each engine is realized by specific circuitry. In an embodiment, the engines are realized by a processing circuitry cooperating with memory and included software code.

The long term analytics <NUM> may be configured to collect and correlate handover data <NUM> (including but not limited to: cell IDs, UE identity, time, and/or handover success/failure, etc.) and/or mobility data <NUM> (including but not limited to: location, speed, trajectory including future path/locations, UE capabilities such as model, and/or radio/antenna parameters, etc.) from a plurality of UEs (e.g. all UEs or all detected UEs) within a coverage area of the cellular communication network over a certain time period. For example, the network may store mobility data <NUM> and handover data <NUM> regarding one or more handovers performed in the network. Said stored information may be referred to as history data, for example. The long term analytics <NUM> may analyse the collected data to detect and learn the mobility conditions that usually cause handover anomalies or failures, i.e. associate certain mobility conditions with handover anomaly or failure.

The handover data <NUM> may comprise data on performed handovers in the network. That is, when a handover regarding a UE is performed, the network may store information about said handover, and the context based handover analytics <NUM> may use said information when detecting possible mobility conditions associated with handover anomalies and/or failures. The mobility data <NUM> may comprise data which may indicate the mobility condition of the UE before, during and/or after the handover, i.e. mobility condition associated or regarding the handover. Hence, the network may correlate the mobility data <NUM> with the handover data <NUM>, and use said data to detect mobility conditions which are associated with handover anomalies and/or failures. Additionally or alternatively, the network may determine mobility conditions which are associated with successful handovers and/or successful handovers without anomalies. This information may be used to determine possible UE specific handover parameters which avoid anomalies and/or failures.

According to an embodiment, the long term analytics <NUM> is further configured to calculate handover sequences that would eliminate or reduce the detected anomalies or failures (e.g., by excluding certain cells from the handover sequences, or changing the conditions when handover is triggered between certain cells). The desired handover sequences may need to comply with the condition of service continuity (e.g., a cell may only be excluded from a handover sequence if the remaining ones still provide continuous coverage). For example, with reference to <FIG>, cell <NUM> may be excluded as trajectory <NUM> is all the time within cell <NUM>, cell <NUM> or within both cells <NUM>, <NUM>. Hence, the network may determine that cell <NUM> is not needed, the cell <NUM> may be excluded, and thus the anomaly may be avoided. In general, according to an embodiment, the network is configured to determine the HO parameters for each UE such that they fulfil the service continuity requirement. Hence, for example, cell or cells are not excluded as targets cells if the excluding may cause discontinuity in service (e.g. within certain area).

The real-time analytics and/or optimization <NUM> may be configured to monitor mobility and/or cellular connectivity of individual UEs (e.g. UE <NUM>) to detect and/or predict if a UE is or is going to be in a mobility condition that causes handover anomalies or failures. For example, this may be determined by comparing current trajectory with known trajectories associated with handover anomalies or failures. As known, trajectory may refer a path that a moving object (i.e. UE in this case) follows through space or coverage area as a function of time. Hence, both speed and location may be of relevance.

In an embodiment, the real-time analytics and/or optimization <NUM> may further be configured to calculate the desired or needed handover sequence of the UE that does not contain the problematic handovers. Such calculation may comprise determining which cell(s) should be excluded from the handover sequence and/or determining when handovers should be executed, for example. The UE specific handover parameters may then be calculated or determined based on the desired or needed handover sequence to avoid the detected handover anomalies and/or failures.

In an embodiment, the network (i.e. the real-time analytics and/or optimization function or engine <NUM>) changes the UE specific handover parameters in real-time. This may enable the UE to avoid the problematic handovers (i.e. which are determined to cause anomalies or failures). The calculation may considers both the usual (i.e. long-term) handover sequences and the current cell states to ensure that the desired handover sequence still provides access to all cells that are required for continuous connectivity for the UE. Hence, the optimization, for example, by excluding target cells is performed such that the connectivity for the UE is tried to always be ensured. cell may not be excluded if it substantially increases possibility of connectivity and/or service failure even though, for example, some handover anomaly is detected. Hence, when determining the UE specific handover parameters, the network may try to ensure that the connection between the UE and the network is maintained (e.g. no RFLs are accepted).

Accordingly, UE specific handover execution <NUM>, <NUM> may be obtained using the UE specific handover parameters. Hence, for example, a handover of a first UE may be performed according to block <NUM> and a handover of a second UE may be performed according to block <NUM>, wherein both UEs are subject to different UE specific handover parameters. So, for example, the first UE associated with a certain speed or velocity is handed over from cell <NUM> to cell <NUM> of <FIG>, whereas second UE associated with higher speed or velocity is handed over from cell <NUM> to cell <NUM> to avoid the short stay anomaly. So, in this example, a speed or velocity over certain threshold may trigger the network to determine UE specific handover parameters which cause the network to perform the handover as described above. It may also be possible that the network utilizes some UE specific handover parameters for a certain number or UEs, but also manages cell specific handover parameters for rest of the UEs as will be disclosed later in more detail. Hence, the cell specific handover parameters may be applied to the first UE in some examples. Another example may be a route trigger. For example, the network may determine that vehicular UEs (i.e. V2X UEs) are moving on a certain route. Hence, for said vehicular UEs the network may utilize certain handover parameters which may, for example, cause excluding of one or more target cells. In an embodiment, the network utilizes both the route and speed triggers (e.g. trajectory trigger(s)).

In an embodiment, the mobility condition comprise speed or velocity. For example, if a speed or velocity of an UE exceeds a threshold, the UE specific HO parameters may be determined by the network for said UE. That is, the network may associate speed at or over certain threshold to be associated with handover anomaly or failure. In such case, exceeding the speed or velocity threshold may cause the network to exclude one or more target cell candidates. According to an embodiment, small cells, such as pico, femto and/or micro cells, are excluded. In an embodiment, the speed or velocity threshold is used in addition with a location requirement or criterion. That is, speed or velocity within certain area or areas exceeding the threshold may trigger the network to determine UE specific HO parameters.

According to an embodiment, the network determines, based on collected data about one or more handovers, one or more mobility conditions associated with one or more handover anomalies or failures. In an embodiment, said collected data about one or more handovers comprises the mobility data <NUM> and/or the handover data <NUM>. In an embodiment, said collected data comprises handover data <NUM> correlated with the mobility data <NUM> of a plurality of terminal devices. So, handover data <NUM> of plurality of UEs and corresponding mobility data <NUM> of plurality of UEs may be used in determining the handover anomalies and failures, and associating said handover anomalies and failures with certain mobility condition or conditions.

According to an embodiment, the network determines, based on said collected data (i.e. mobility data <NUM> and/or handover data <NUM>) about one or more handovers, one or more handover sequences that reduce a risk of handover anomalies or failures; utilizes said determined one or more handover sequences when determining the terminal device specific handover parameters (e.g. UE specific handover execution in block <NUM>, <NUM>). Reducing the risk of handover anomalies or failures may refer to generally reducing said risk, or at least reducing a risk of detected anomaly or failure. That is, if certain mobility condition is determined to be associated with certain anomaly or failure with respect to certain handover or handovers, said handover or handovers may be avoided with UEs having said mobility condition. For example, a different kind of handover (i.e. different target cell) may be used instead.

According to an embodiment, the network takes into account said collected data about the one or more handovers when determining the terminal device specific handover parameters. So, as said, certain handover(s) may be avoided regarding UE or UEs with certain mobility condition.

According to an embodiment, the network takes into account mobility data and/or cellular connectivity data regarding an UE when determining the terminal device specific handover parameters. So, for example, two or more UEs may have same mobility condition, but may have different cellular connectivity (e.g. different antenna causing different connectivity). Hence, the determination about possible handover anomaly or failure may be different. Purely as an example with respect to <FIG>, a first UE may detect (i.e. measure) cell <NUM> whereas a second UE may not detect the cell <NUM>. For example, the UEs may have different antenna sensitivity. Hence, although both UEs would have the same mobility condition (e.g. trajectory <NUM>), the UE specific handover parameters may be different. That is, for the first UE, cell <NUM> may be excluded from possible target cells, whereas for the second UE there may be no such need as the cell <NUM> cannot be the target cell due to non-detection. For example, the non-detection may additionally or alternatively be caused by the second UE not supporting the RAT of the cell <NUM> (e.g. <NUM> UE, but cell <NUM> is <NUM>). In general, the network may further use UE specific data, such as UE capability information (e.g. model, radio parameters and/or antenna parameters) when determining the UE specific handover parameters.

According to an embodiment, the network determines the UE specific handover parameters in real-time. For example, the parameters may be determined, generated and/or changed in response to determining that the mobility condition of the UE is associated with a certain handover anomaly and/or failure.

According to an embodiment, the terminal device specific handover parameters indicate exclusion of one or more cells as one or more target cell candidates. cell <NUM> may be excluded as a target cell when UE <NUM> is handed over from cell <NUM>, and follows trajectory <NUM>.

According to an embodiment, the terminal device specific handover parameters have an effect on when one or more handovers are performed. That is, the handover parameters may comprise handover trigger (e.g. A3 A2, A3, A4), offset, hysteresis and/or time-to-trigger parameters. That is, said parameter(s) may be used to adjust and/or define when the one or more handovers are initiated and/or performed. the parameters may indicate when the one or more handovers are performed.

According to an embodiment, the terminal device specific handover parameters are determined if the following condition is additionally fulfilled: a current or predicted cellular communication network status (e.g. vehicular network status) is substantially similar compared with a cellular communication network status at the time of the handover anomaly or failure. So, basically block <NUM> of <FIG> is initiated once the current or predicted network status is substantially similar compared with the network status at the time of the handover anomaly or failure and detecting that the terminal device has or is going to have a mobility condition previously determined to be associated with the handover anomaly or failure. So, in this embodiment, both conditions may need to be fulfilled before performing actions of block <NUM> and consequently block <NUM>. Network state may refer to status of the network and may include parameters such as network load, indication of operative cells, available capacity, and the like. Purely as an example, there may be no need to exclude cell <NUM> of <FIG> if said cell is not operational at the moment when the UE <NUM> is on the trajectory <NUM>. Other way around, it may be beneficial to exclude said cell <NUM> if it is operational. So, in general, the network may take into account operational status of at least a sub-part of the network when determining the UE specific HO parameters.

Let us then discuss some embodiments in more detail. <FIG> illustrates an embodiment showing different functions of the described solution. That is, UE specific handover functions <NUM>, <NUM> that may enable UE level handover differentiation in the Radio Access Network (RAN) and a handover analytics function <NUM> that monitors and analyses the UEs and handovers, computes UE specific handover parameters and dynamically configures the UE specific handover functions. The handover analytics function <NUM> may interact with multiple UE specific handover functions <NUM>, <NUM>, as shown in <FIG>, e.g. command different functions <NUM>, <NUM>. The UE specific handover functions <NUM>, <NUM> may control the handovers of the respective UEs according to the commands (e.g. H0 parameters) from the handover analytics function <NUM>.

According to an embodiment, the UE specific handover function <NUM>, <NUM> is implemented at the radio access nodes (e.g., LTE eNBs or <NUM> gNB) extending the current cell pair specific handover implementation. Currently, for example, in LTE, eNB side handover implementation relies on neighbour relation tables present in each eNB. The Neighbour Relation Table (NRT) at a given eNB may specify the list of potential handover target cells for each of the eNB's own cells. A target cell may be a cell at the same eNB or a cell at a different eNB; the source and target cells may operate at the same frequency or at different frequencies. For each source-target cell pair, the conditions for handovers may also be defined at the eNB, including the handover trigger (e.g., A2, A3, A4 measurement), the corresponding measurement offset, hysteresis and time to trigger. The handover trigger may define the unit that the UEs are measuring and reporting to the eNB (e.g. Reference Signal Received Power (RSRP) / Reference Signal Received Quality (RSRQ) of the current serving cell and that of a limited number of neighbour cells). The measurement offset and hysteresis together with the trigger may define how much the measured unit of the current serving cell and that of a neighbour cell needs to differ from each other or from preconfigured absolute threshold values so that a handover condition is considered by the eNB from the current source cell to the neighbour cell (e.g., the neighbour cell's RSRQ should be higher than the current cell's RSRQ by no less than <NUM> dB). The time to trigger defines how long the handover condition needs to be continuously fulfilled before the handover from the source cell to the neighbour cell is initiated by the eNB. It is noted that eNB and LTE are used as examples of implementation. However, it needs to be understood that similar or same solution may be applicable to other systems utilizing handover procedure.

Currently, the eNB may apply the same handover trigger, measurement offset, hysteresis and time to trigger regardless of the identity of the UE that is reporting the measurements, therefore all UEs may go through the same decision process and handovers under the same circumstances. To further enhance the presented solution per-UE handover operation, additional UE specific neighbour relation tables (UE-NRT) may be implemented. Example of this may be shown in <FIG> showing UE specific NRT <NUM> for UE <NUM> and UE specific NRT <NUM> for UE <NUM>. Each UE specific NRT (or sometimes referred to simply as UE-NRT) may be associated with a given UE identity and it may indicate or list potential source-target cell pairs valid for that UE along with the UE specific handover measurement and conditions corresponding to each source-target cell pair. The list of cell pairs in the UE-NRT may be the same, subset of, superset of, partially overlapping with or disjoint from the cell pairs in the network element level NRT <NUM> (e.g. eNB level NRT). For each source-target cell pair that exists in both the eNB level NRT and an UE-NRT, the handover parameters in the eNB level NRT and the UE-NRT may be the configured with the same or different values.

With reference to <FIG>, the network may use UE specific NRTs <NUM>, <NUM> while retaining the existing network element level NRT <NUM>. For example, the network element level NRT <NUM> may indicate first source cell <NUM> and its one or more target cell pairs <NUM>, <NUM>, <NUM>. Similarly, a second source cell <NUM> and its target cells <NUM>, <NUM>, <NUM> may be indicated. Hence, one or more source cells <NUM>, <NUM>, <NUM> and their corresponding pair candidates may be indicated (candidates for cell <NUM> are not shown in <FIG>, but may still be used).

Similar logic may apply to the UE specific NRTs <NUM>, <NUM>, but instead of being for all UEs, the NRTs <NUM>, <NUM> may be specific for certain UE or a group of UEs. For example, the network may group UEs based on UE capability information, and associated the group with certain UE specific NRT <NUM>, <NUM>. For example, NRT <NUM> for UE <NUM> indicate one or more source cells <NUM>, <NUM> and their corresponding target cell candidates <NUM>, <NUM>, <NUM>, <NUM> (i.e. candidates when cell <NUM> is the source cell). Similarly, NRT <NUM> for UE <NUM> may indicate source cell <NUM> and its target candidates <NUM>, <NUM>. So, the number of target candidates may be the same, more or less compared with the network element level NRT <NUM>. The handover parameters <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may indicate applicable handover parameters for certain source cell/target cell pair. In the presented solution, this can be made per UE whereas the known solutions may only enable such configuration on cell/network element level. It is noted that UE-NRTs <NUM>, <NUM> may indicate target candidates for the same cells as are indicated in NRT <NUM>. That is, a first source cell <NUM> may mean same cell as first source cell <NUM> and first source cell <NUM>. However, these are illustrated in <FIG> with different reference numbers for clarity reasons. So, basically NRTs <NUM>, <NUM>, <NUM> may actually indicate, at least in some examples, same source cells and their candidates (which may be different per NRT) and additional HO parameters regarding each source-target cell pair candidate.

So, according to an embodiment, the network causes creating or modifying a terminal device specific table (e.g. UE-NRT <NUM>, <NUM>) based on the terminal device specific handover parameters. For example, the network element <NUM> may update and/or create the NRT(s) <NUM>, <NUM> according to the determined handover parameters. The modification of an existing UE-NRT may include changing the list of source-target cell pairs and/or the handover parameters of one or more source-target cell pairs. One example of this may be seen in <FIG> illustrating a process according to an embodiment. Referring to <FIG>, the network obtains (block <NUM>) UE specific handover configuration information. Said information may include potential source-target cell pairs (e.g. source: cell <NUM>, targets: <NUM>, <NUM>) and source-target cell pair specific handover parameters (e.g. threshold for handovers and the like). In block <NUM>, the network may create (if such UE NRT does not exists) or modify (if already exists) UE specific NRT based on the information obtained in block <NUM>. For example, the functions of blocks <NUM> and <NUM> may be performed in a UE specific handover function <NUM>, <NUM>.

<FIG> illustrates a flow diagram according to an embodiment. Referring to <FIG>, in block <NUM>, the network (e.g. network element <NUM>) may receive measurement reports from one or more UEs (e.g. UE <NUM>) about neighbour cells of the UE. In block <NUM>, the network may look for UE specific NRT for an UE that has sent report(s) in block <NUM>. In block <NUM>, the network may determine whether the UE specific NRT for said UE exists: if yes, the process may continue to block <NUM>. If not, the process may continue to block <NUM>. In block <NUM>, the network may determine to perform handovers according to the network element level NRT (e.g. NRT <NUM>). In block <NUM>, the network may determine to perform handovers according to the UE specific NRT (e.g. NRT <NUM>, <NUM>) corresponding to the specific UE. So, for example, when an eNB evaluates the measurement reports received from a given UE, it checks whether the UE has a corresponding UE-NRT: if yes, the UE-NRT may take precedence over the eNB level NRT and the eNB level NRT is disregarded; otherwise the eNB level NRT may be regarded as valid. The UE-NRT mechanism may therefore be capable of selective handover specialization targeting individual UEs (i.e., those for which UE-NRT tables exist), whereas for the rest of the UEs the operation defaults to the eNB level NRT, or generally network element level NRT if some other technique than LTE or LTE-A is used.

According to an embodiment, the network element may cause receiving (block <NUM>) of a one or more measurement reports from a terminal device; cause determining (blocks <NUM>, <NUM>) whether the terminal device is associated with a terminal device specific table (i.e. UE specific NRT); and upon determining that the terminal device is associated with the terminal device specific table, causing utilizing (block <NUM>) said terminal device specific table in one or more handovers triggered based on said one or more measurement reports, otherwise causing utilizing (block <NUM>) a cell specific table in one or more handovers triggered based on said one or more measurement reports.

The UE-NRT <NUM>, <NUM> may specify, by listing the source-target cell pairs, which handovers are enabled for the corresponding UE and for each potential handover it may define the conditions for initiating the handover. Accordingly, the UE may not be eligible to handover from a source cell to a target cell if the source-target cell pair is not listed in the UE-NRT. According to some embodiments, the network may have at least two alternatives to enforce that only eligible handovers are executed for a UE according to its UE-NRT.

First option is that that the implementation is transparent to the UE. That is, the network enables the UE or UEs to measure and report all detected cells including the cells which are not listed as potential target cells (i.e. are excluded or not listed as target cell candidates). The network may not need to take any action regarding configuring the measurements. However, the network may ignore measurement reports regarding target cells which are not listed in the UE specific NRT, and take said measurement reports forward for handover condition evaluation that indicate a valid target cell. Therefore, the networks handover decision process may select eligible handover targets for the UE. The benefit of this alternative is that no further signalling between the network and the UE may be needed to enforce the restrictions in the UE-NRT.

Second option is that the implementation involves signalling between the network and the UE. Accordingly, in an embodiment, the network causes indicating one or more cells to the UE or UEs in order to enable the UE to perform measurements regarding one or more target cell candidates of the terminal device specific table. For example, the network may configure the UE to only collect and report measurements on neighbour cells that are potential handover targets listed in the UE-NRT. For example, the configuring may comprise transmitting one or more control messages to the UE. The control messages may be UE specific, i.e. targeted to a certain UE or in some cases to a plurality of UEs. wherein the same measurement configuration is applicable to plurality of UEs. The network may then consider all measurement reports for handover evaluation without filtering with respect to the UE-NRT (i.e. UE specific NRT). The advantage of this alternative may be that the UE does not spend resources for measuring neighbour cells that would be later discarded by the network.

Different methods for identifying the UEs may be used. One may be the use of subscriber identity. Alternatively or additionally, a valid implementation may use UE terminal type (e.g., International Mobile Equipment Identity (IMEI), or coarse terminal category such as vehicle/non-vehicle, etc.) as UE identity to differentiate handovers per UE type/category. Identification by any other UE or subscriber attribute as well as any attribute collectible from the current UE's behaviour or generated traffic (e.g., active applications) may also be used. For scalability, an implementation may share the same UE-NRT between multiple UEs in case the same specialized handover conditions would apply to them, e.g., using memory pointers from different UE identities to the same memory location where the shared UE-NRT instance is stored. In case a shared UE-NRT needs to be changed only for a subset of the UEs sharing the UE-NRT, the Copy on Write (COW) memory object instantiation method may be used. So, for example, the UE specific NRT could be utilized for all detected V2X UEs, whereas some other table (e.g. NRT <NUM>) could be utilized for all other UEs. It is also pointed out that the UE specific NRTs may be configured on network element level, i.e. said UE specific NRTs may also differ from network element to network element.

Let us then reflect on the handover analytics function <NUM> which may be a logically centralized entity that is responsible for managing UE specific handover within a geographical or administrative area. The Handover analytics function <NUM> may be implemented as a software entity running on existing network elements or in clouds or data centres (e.g., as a VNF similarly as the UE specific handover functions <NUM>, <NUM> may be VNFs). The handover analytics function <NUM> may monitor and collect real time UE context information and real time handover information from its responsibility area. The UE context information (e.g. mobility data <NUM>) may include but is not limited to: UE identity, timestamp of information, position, speed, trajectory, and/or future locations, etc. For vehicular UEs, the context information is available from the Cooperative Awareness Message (CAM) or Decentralized Environmental Notification Message (DENM) messages generated by each vehicle periodically or under certain road/traffic events. Future locations may be collected from navigation application containing the planned trajectory of the vehicle. The handover information (e.g. also refer to as handover data <NUM>) includes but is not limited to: UE identity, source/target cells, timestamp, handover success/failure, cause code, time spent disconnected from the network. The handover information may be available from control plane network elements such as the MME or from attached data collection functions/products such as Nokia Traffica.

<FIG> illustrates three different databases <NUM>, <NUM>, <NUM> maintained by the handover analytics function <NUM> according to an embodiment. Referring to <FIG>, the handover analytics function <NUM> may maintain three databases:.

The network, e.g. the handover analytics function <NUM>, may utilize said one or more databases <NUM>, <NUM>, <NUM> when determining the UE specific HO parameters. <FIG> and <FIG> illustrate some embodiments regarding maintaining and/or utilizing database(s) <NUM>, <NUM>, <NUM>. Referring first to <FIG>, in block <NUM> the handover analytics function <NUM> may receive real time mobility data (e.g. mobility data <NUM>) regarding an UE or UEs, such as UE ID, time, positon, speed, trajectory, and/or, future locations and the like. In block <NUM>, the handover analytics function <NUM> may determine or compose UE context (e.g. context C) based on the mobility data. In block <NUM>, the handover analytics function <NUM> may update the database <NUM> based on the determined UE context. In block <NUM> real time optimization on context C may be triggered.

Referring to <FIG>, in block <NUM>, the handover analytics function <NUM> may receive real time handover event data (e.g. handover data <NUM>). In block <NUM>, the handover analytics function <NUM> may update UE specific handover sequence database (database <NUM>) based on the handover event data. Further, in block <NUM>, the handover analytics function <NUM> may analyse one or more UE specific handover sequences and determine in block <NUM> whether there is handover anomaly or failure associated with the specific sequence or sequences. If there is, the process may continue to block <NUM>, and if not the process may continue directly to block <NUM>. In block <NUM>, the handover analytics function <NUM> may retrieve context of the UE in question from database <NUM> (e.g. based on UE ID), and update handover anomaly/failure database <NUM> by storing a data entry indicating certain UE context (e.g. mobility condition) associated with a handover anomaly or failure. context C is associated with anomaly A and/or failure F. Handover anomalies such as ping-pongs or short stays may be detected based on the repeating cell sequence and/or the amount of time elapsed between consecutive handovers. Handover to remote cell may be detected based on the amount of time the UE spent disconnected from the network during handover (i.e., between detaching from the source cell until attaching to the target cell). Handover failures and corresponding cause codes may be available from control plane protocol results directly. In case any handover anomaly or failure is detected, the UE's context along with the type of handover problem is recorded in the long-term handover anomaly/failure database <NUM>, as described. In block <NUM>, real time optimization may be triggered (e.g. UE specific H0 parameter determination) may be triggered by the network for the UE in question.

Referring to <FIG>, the process comprised in or after block <NUM>, <NUM> may be shown. The real time optimization procedure may be triggered for a UE both after updating its context (<FIG>) or its handover sequence (<FIG>) as any change in the UE's state (such as mobility/speed change, new serving cell) may trigger a need for targeted handover configuration (e.g. determining handover parameters for said UE). The objective of the procedure of <FIG> may be to (<NUM>) evaluate if the UE is approaching a location or is in a state that is usually impacted by handover anomaly/failure (according to the long-term handover anomaly/failure database <NUM>); (<NUM>) calculate and store possible resolutions (UE specific handover parameters and reconfigurations) for handover anomalies/failures; (<NUM>) execute the resolutions if needed to avoid such anomalies/failures; (<NUM>) maintain the validity of the resolutions by monitoring if the reconfiguration successfully solved the handover problem and that it did not introduce service discontinuity or coverage problems.

In block <NUM> UE's context may be inputted. In block <NUM>, UE's future context may be predicted. For example, UE's trajectory may be predicted. In block <NUM>, the network may determine whether the current or predicted context is found from database <NUM>: i.e. is there any recorded anomalies or failures associated with said context(s). Block <NUM>: if there is, the process may continue to block <NUM> in which the network may determine whether a resolution for said anomaly or failure exists (e.g. excluding some cell as target cell). Otherwise, the process may end (i.e. 'Done'). the process may end if no anomaly or failure is detected regarding one or more contexts (e.g. C, C', C"). For example, C' and C" may refer to predicted UE contexts. In block <NUM>: if no valid resolution exists (i.e. is not found based on block <NUM>), the process may continue to block <NUM>. If a valid resolution or resolutions is found, the process may continue to block <NUM>.

In block <NUM>, the network may at least try to calculate or determine a valid resolution for said context or contexts. the network may try to determine a new valid resolution for said context(s) to avoid one or more detected handover anomalies and/or failures. In block <NUM>, if a new valid resolution is computed successfully and/or found, the process may continue to block <NUM>. However, if no valid resolution is found, the process may continue to block <NUM> in which the network may store 'no resolution' to the database <NUM> with respect to said context(s). New resolution may mean a potential resolution, as said resolution may not have been tested as it has just now been calculated. In block <NUM>, the network may execute the found resolution (e.g. stored in to the database or calculated in block <NUM>) by configuring the UE specific handover parameters in UE specific handover function(s) <NUM>, <NUM>.

In block <NUM>, the network may monitor the performed resolution. In block <NUM>, based on block <NUM>, the network may determine whether said resolution was successful or not. This may comprise performing one or more measurements and/or monitoring one or more handovers performed on the basis of the indicated UE specific handover parameters. If yes, the action may be recorded as valid resolution in database <NUM> (block <NUM>). If not, the action may be recorded as invalid solution in database <NUM> (block <NUM>). So, for example, the calculated resolution in block <NUM> may be stored as a valid resolution if the handover anomaly and/or failure is determined to be avoided using the calculated resolution.

In an embodiment, the network monitors the one or more handovers performed on the basis of said terminal device specific handover parameters; and based on the monitoring, if said handover anomaly or failure is avoided by utilizing said terminal device specific handover parameters, stores an indication about said UE specific handover parameters avoiding said handover anomaly or failure with respect to said mobility condition (e.g. user context C, C', and/or C").

In an embodiment, upon detecting that a second UE has or is going to have said mobility condition associated with said handover anomaly or failure, the network determines UE specific handover parameters for said second terminal device to avoid said handover anomaly or failure on the basis of the stored indication. So, by storing a determined valid resolution into a database, the network may use the same resolution for other UEs having same or similar mobility condition.

As described above, the UE specific configuration action described in <FIG> may adjust handover trigger, offsets, hysteresis, and/or time to trigger (e.g., to prevent ping-pong anomalies) or remove certain handover relations completely (e.g., to prevent short stay or remote site anomalies). For example, if the UE is likely to experience ping-pong handover (e.g., as previously UEs moving along the same trajectory with the same speed experienced it), the handover hysteresis can be increased between the source-target cells prone to ping-pong so that once a handover is executed there the UE is not handed back any more. In another example, the handover to a certain cell may be prohibited selectively for UEs currently moving with high speed (e.g. speed or velocity exceeding certain threshold) to avoid short stay or handover to remote cell problem. Note, however, that such handovers to remote cells (or short stays) may be eliminated in case the cells reachable via the remaining handover possibilities are currently providing contiguous and good coverage for the UE. To some extent the validity of a new handover configuration may be evaluated in advance during its calculation phase (e.g., by monitoring the RSRP/RSRQ measurement reports sent by the UE for all potential neighbour cells and considering the quality of the cells that would remain accessible after the handover reconfiguration). If the UE reports good RSRP/RSRQ for all cells that would remain reachable after blocking a certain short stay or remote cell handover, it may be safe to block the anomalous handover; otherwise, the handover possibility may be kept as continuous service may be more important than optimizing out anomalous handovers at the risk of creating a coverage hole. After calculating a new resolution for a handover problem or executing an already known resolution (block <NUM>), its success and efficiency may be monitored (block <NUM>). Success may mean whether the action removed the handover anomaly/failure and efficiency may mean that the action did not introduce additional problems such as discontinuous coverage. Resolutions along with their validity (based on the success and efficiency) may be recorded in the handover anomaly/failure database <NUM> to avoid the need for recalculation in the same context and to avoid probing for a solution that has failed previously. In case the network deployment changes (e.g., cell radio parameters such as transmission power or positioning such as tilting or azimuth change, or new cells are added to the network), the profiling of the handover anomalies/failures as well as the corresponding resolutions is updated by taking into account the new environment. This may include re-evaluating previously invalid resolutions or forgetting anomalies/failures that do not exist anymore.

<FIG> provides apparatus <NUM> comprising a control circuitry (CTRL) <NUM>, such as at least one processor, and at least one memory <NUM> including a computer program code (software) <NUM>, wherein the at least one memory and the computer program code (software) <NUM>, are configured, with the at least one processor, to cause the respective apparatus <NUM> to carry out any one of the embodiments of <FIG>, or operations thereof.

Referring to <FIG>, the memory <NUM> may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memory <NUM> may comprise a database <NUM> for storing data. For example, the database <NUM> may comprise one or more of databases <NUM>, <NUM>, <NUM>. In more general terms, the database <NUM> may be used to store information on mobility conditions associated with handover anomalies and/or failures. The database <NUM> may additionally comprise information about valid and/or invalid resolutions to said anomalies and/or failures.

The apparatus <NUM> may further comprise radio interface (TRX) <NUM> comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the apparatus with communication capabilities to access the radio access network, for example. The TRX may comprise standard well-known components such as an amplifier, filter, frequency-converter, (de)modulator, and encoder/decoder circuitries and one or more antennas. For example, the TRX may enable communication between the UE <NUM> and the network element <NUM>. Further, the TRX may provide access to the X2-interface and/or Xx-interface by the network element <NUM>, for example. The TRX may thus be used to realize wired and/or wireless communication according to one or more communication protocols.

The apparatus <NUM> may comprise user interface <NUM> comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface <NUM> may be used to control the respective apparatus by a user. For example, the network element <NUM> may be configured using the user interface comprised in said network element. The user interface <NUM> may be configured to enable remote access and/or remote controlling of said device.

In an embodiment, the apparatus <NUM> may be or be comprised in a base station (also called a network element, an access node, a base transceiver station, a Node B, a radio network controller, an eNB, or a gNB, for example). The apparatus <NUM> may be the network element <NUM>, for example. Further, the apparatus <NUM> may be configured to perform the steps of <FIG> and embodiments thereof. In an embodiment, the apparatus <NUM> is comprised in the network element <NUM>. In an embodiment, the apparatus <NUM> is comprised in or realizes functionality of fixed network architecture. Fixed network architecture may refer to parts of the network that are used to provide cellular services to terminal devices.

Referring to <FIG>, according to an embodiment, the control circuitry <NUM> comprises a determining circuitry <NUM> configured to determine terminal device specific handover parameters for a terminal device to avoid a handover anomaly or failure upon detecting that said terminal device has or is going to have a mobility condition previously determined to be associated with said handover anomaly or failure; and a utilizing circuitry <NUM> configured to cause utilizing said terminal device specific handover parameters in one or more handovers associated with the terminal device. Embodiments of such operation are described above in more detail.

In an embodiment, at least some of the functionalities of the apparatus <NUM> may be shared between two physically separate devices, forming one operational entity. Therefore, the apparatus <NUM> may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes. Thus, the apparatus <NUM> utilizing such shared architecture, may comprise a remote control unit (RCU), such as a host computer or a server computer, operatively coupled (e.g. via a wireless or wired network) to a remote radio head (RRH) located in the base station or network element. In an embodiment, at least some of the described processes may be performed by the RCU. In an embodiment, the execution of at least some of the described processes may be shared among the RRH and the RCU.

In an embodiment, the RCU may generate a virtual network through which the RCU communicates with the RRH. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization may involve platform virtualization, often combined with resource virtualization. Network virtualization may be categorized as external virtual networking which combines many networks, or parts of networks, into the server computer or the host computer (i.e. to the RCU). External network virtualization is targeted to optimized network sharing. Another category is internal virtual networking which provides network-like functionality to the software containers on a single system. Virtual networking may also be used for testing the terminal device.

In an embodiment, the virtual network may provide flexible distribution of operations between the RRH and the RCU. In practice, any digital signal processing task may be performed in either the RRH or the RCU and the boundary where the responsibility is shifted between the RRH and the RCU may be selected according to implementation.

Hence, as at least some of the steps of the presented solution are described as performed by the network or some specific entity of the network, it is pointed out that at least the apparatus <NUM> may be configured to perform such method steps according to the description. This may mean, for example, that the apparatus <NUM> realizes the functions <NUM>, <NUM>, <NUM>. For example, the apparatus <NUM> may realize the functions <NUM>, <NUM>, <NUM>. As said, the apparatus <NUM> may be realized as centralized unit or as utilizing shared resources, and thus realized as a plurality of interacting and/or interconnected entities performing the functions of the apparatus <NUM>.

<FIG> illustrates a flow diagram from the UE (e.g. UE <NUM>) perspective according to an embodiment. Referring to <FIG>, a method in a UE comprises: performing one or more cell measurements (block <NUM>); transmitting, based on said one or more cell measurements, one or more measurement reports to the cellular communication network for determining handover parameters (block <NUM>); and utilizing terminal device specific handover parameters in one or more handovers associated with the terminal device to avoid a handover anomaly or failure, wherein the terminal device specific handover parameters are determined based on detecting that the terminal device has or is going to have a mobility condition previously determined to be associated with the handover anomaly or failure (block <NUM>).

As described above, according to an embodiment, the UE performs measurements on one or more cells indicated by the cellular communication network (e.g. one or more control messages from the network to the UE), said one or more cells indicated as target cell candidates in a terminal device specific neighbour relation table. So, for example, the network may instruct the UE to only perform measurements on potential target cell candidates and not on cells which are not on the UE-NRT table. As described earlier, the configuration may be UE specific by using UE specific control message(s), for example. In other words, the cellular network may instruct the UE to perform measurements on one or more cells and/or instruct the UE to exclude one or more cells as cells which should be measured by the UE. Said cell measurements may comprise, for example, measuring cell power (i.e. signal quality) of a cell or cells. The UE may indicate said measurement(s) to the network.

<FIG> provides an apparatus <NUM> comprising a control circuitry (CTRL) <NUM>, such as at least one processor, and at least one memory <NUM> including a computer program code (software) <NUM>, wherein the at least one memory and the computer program code (software) <NUM>, are configured, with the at least one processor, to cause the respective apparatus <NUM> to carry out any one of the embodiments of <FIG> and <FIG>, or operations thereof of the UE.

Referring to <FIG>, the memory <NUM> may be similar as the memory <NUM>, for example. The apparatus <NUM> may further comprise radio interface (TRX) <NUM> comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The apparatus <NUM> may comprise user interface <NUM> comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc..

In an embodiment, the apparatus <NUM> may be or be comprised in a UE (e.g. UE <NUM>). The apparatus <NUM> may be the UE performing steps of <FIG>.

Referring to <FIG>, according to an embodiment, the control circuitry <NUM> comprises a performing circuitry <NUM> configured to perform operations of block <NUM>; a transmitting circuitry <NUM> configured to perform operations of block <NUM>; and a utilizing circuitry <NUM> configured to perform operations of block <NUM>.

In an embodiment, at least some of the processes described in connection with <FIG> and <FIG> may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry. In an embodiment, the at least one processor, the memory, and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of <FIG> and <FIG> or operations thereof.

According to yet another embodiment, the apparatus carrying out the embodiments comprises a circuitry including at least one processor and at least one memory including computer program code. When activated, the circuitry causes the apparatus to perform at least some of the functionalities according to any one of the embodiments of <FIG> and <FIG>, or operations thereof.

The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus(es) of embodiments may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chip set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with <FIG> and <NUM> may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium, for example. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art. In an embodiment, a computer-readable medium comprises said computer program.

Claim 1:
A method performed by a base station of a cellular communication network, the method comprising:
collecting handover data correlated with mobility data of a plurality of terminal devices;
determining, based on the collected data, one or more trajectories associated with one or more handover anomalies;
monitoring mobility and/or cellular connectivity of terminal devices by receiving measurement report from the terminal devices;
detecting that a terminal device has or is going to have a trajectory previously determined to be associated with a handover anomaly, wherein the handover anomaly is a ping pong handover anomaly or a short stay handover anomaly;
determining terminal device specific handover parameters for said terminal device to avoid said handover anomaly;
causing the terminal device to utilize said terminal device specific handover parameters in one or more handovers associated with the terminal device;
monitoring the one or more handovers performed on the basis of said terminal device specific handover parameters; and
based on the monitoring, if said handover anomaly is avoided by utilizing said terminal device specific handover parameters, storing an indication about said terminal device specific handover parameters avoiding said handover anomaly with respect to said trajectory.