WO2023052010A1

WO2023052010A1 - Trajectory data collection in mobile telecommunication systems

Info

Publication number: WO2023052010A1
Application number: PCT/EP2022/073812
Authority: WO
Inventors: Hakon Helmers; Anna Pantelidou
Original assignee: Nokia Technologies Oy
Priority date: 2021-09-29
Filing date: 2022-08-26
Publication date: 2023-04-06
Also published as: GB202113879D0; GB2611303A

Abstract

In order to be able to accurately predict the trajectory of a mobile device, data regarding its trajectory should be collected. Embodiments provide a means of doing this by sending trajectory status requests to neighbouring network nodes in UE associated signalling, to determine where a UE has travelled to. There is provided an apparatus, comprising: means for receiving a trajectory status request, the trajectory status request identifying a network node, the trajectory status request requesting information regarding visiting of at least one cell or at least one beam within a cell by at least one user equipment that has visited the network node identified in the trajectory status request. Means for generating a trajectory status report in response to receipt of the trajectory status request, the trajectory status report comprising the information regarding visiting of the at least one cell or the at least one beam by the at least one user equipment, the at least one cell or the cell containing the at least one beam comprising a cell associated with the apparatus; and means for transmitting the generated trajectory status report to the network node identified in the trajectory status request.

Description

TRAJECTORY DATA COLLECTION IN MOBILE TELECOMMUNICATION

SYSTEMS

TECHNOLOGICAL FIELD

Various example embodiments relate to trajectory data collection in mobile telecommunication systems and in particular embodiments in a distributed communication network.

BACKGROUND

Being able to make reliable predictions regarding the trajectory of user equipment within a wireless communication network can be helpful in many areas such as energy saving, load balancing, mobility management and coverage optimisation.

Energy saving, load balancing and mobility management for example, require decisions to be taken which will have an impact on e.g. the upcoming radio conditions or available service for a user equipment, or the upcoming load situation in a cell, in an NG- RAN node or on a frequency layer. These use cases would therefore benefit from reliable predicted information in the network about future UE movements.

In legacy networks, limited trajectory prediction is typically performed by analysis of the UE's mobility history.

Machine Learning and Artificial Intelligence techniques may be used to improve trajectory prediction, but for these to function well, data regarding the trajectory of the UE needs to be available to the machine learning algorithm to enable it to learn. In distributed systems such as a 5G network, it may be difficult to gather the UE mobility data in a central location.

It would be desirable to be able to gather trajectory data of mobile devices within a communication network.

BRIEF SUMMARY

The scope of protection sought for various embodiments of the invention is set out by the independent claims. The [embodiments/ examples] and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention. According to various, but not necessarily all, embodiments of the invention there is provided according to an aspect an apparatus, comprising: means for receiving a trajectory status request, said trajectory status request identifying a network node, said trajectory status request requesting information regarding visiting of at least one cell or at least one beam within a cell by at least one user equipment that has visited said network node identified in said trajectory status request; means for generating a trajectory status report in response to receipt of said trajectory status request, said trajectory status report comprising said information regarding visiting of said at least one cell or said at least one beam by said at least one user equipment, said at least one cell or the cell containing said at least one beam comprising a cell associated with said apparatus; and means for transmitting said generated trajectory status report to said network node identified in said trajectory status request.

Although on visiting a cell the associated network node may be able to determine the user equipment history it is unaware of where the user equipment goes next. Example embodiments allow a trajectory status request to be propagated through a network. The trajectory status request is received at an apparatus and queries whether or not a user equipment that has previously visited a cell associated with the node requesting the information has visited the cell or beam within the cell associated with that apparatus. In this way a query information regarding the trajectory of user equipment may be gathered, but only in response to the trigger of the request. By providing the data only in response to a specific trigger, that is the request the amount of data that is transmitted can be controlled to an effective amount and indeed the data may only be requested in situations where it is required. The request may be received from a user equipment, an operation, administration and maintenance 0AM node or a network node.

In some example embodiments, said means for generating said trajectory status report is configured to generate a true indication as said information regarding visiting of said at least one cell or said at least one beam within a cell, where said at least one user equipment has visited said cell or said at least one beam within said cell associated with said apparatus within a predetermined time period.

In some example embodiments, said trajectory status request comprises an identifying indicator, said means for generating being configured to generate said trajectory status report to include said identifying indicator. In some example embodiments, said trajectory status request comprises additional information, said additional information indicating at least one of: a type of network node that said request is valid for, a number of transitions to new cells that said request remains valid for and a slice identifier indicating a slice of the network that said trajectory status request is valid for.

In some example embodiments, said apparatus further comprises means for transmitting said received trajectory status request to a further network node.

In some example embodiments, said means for transmitting said received trajectory status request to a further network node is configured to transmit said received trajectory status request as part of user equipment associated signalling.

In some example embodiments, said means for transmitting said received trajectory status request is configured to transmit said received trajectory status request as part of history information for said at least one user equipment.

In some example embodiments, said apparatus further comprises means for managing mobility of user equipment, said means for managing mobility being configured to generate a handover preparation message for transmission to a target network node, said means for managing mobility being configured to include said received trajectoiy status request as part of said handover preparation message.

In some example embodiments, said means for transmitting said trajectory status report to said network node identified in said trajectory status request is configured to transmit said trajectory status report as part of network signalling between network nodes and not associated with a user equipment.

In some example embodiments, the apparatus further comprises: means for receiving a user equipment history request, said user equipment histoiy request identifying at least one cell or at least one beam within a cell, said user equipment histoiy request requesting a cell history for user equipment that have visited said identified at least one cell or at least one beam; means for monitoring cell histories of user equipment visiting a cell associated with said apparatus; and means for generating a user equipment history report in response to said means for monitoring determining from said user equipment history that said user equipment has visited said at least one cell or at least one beam identified in said request, said generated user equipment history report indicating cells or beams that said user equipment has visited; means for transmitting said generated user equipment history report to said network node identified in said trajectory status request.

In some example embodiments, said user equipment history request comprises an indication of said at least one cell or said at least one beam and at least one other criteria; and said means for generating said user equipment history report is configured to generate a user equipment history report for user equipment that have visited said indicated at least one cell or at least one beam and meet said at least one other criteria.

In some example embodiments, said user equipment history request comprises data indicating further information required in said user equipment cell history, said means for generating said user equipment history report being configured to generate said user equipment history report to include said further information requested.

In some example embodiments, said apparatus comprises means for transmitting said received trajectory status request to at least one of said at least one user equipment visiting said cell associated with said apparatus.

In some example embodiments, said means for receiving said trajectory status request is configured to receive said trajectory status request from at least one of: a user equipment when said user equipment reconnects to said network via a cell associated with said apparatus; a control network node as part of a user equipment context when said user equipment reconnects to said network via a cell associated with said apparatus; a network node, said trajectory status request being received in user equipment associated signalling; and an operations, administration and maintenance 0AM node.

According to various, but not necessarily all, embodiments of the invention there is provided according to a further aspect an apparatus comprising: means for generating a trajectory status request requesting information regarding visiting of at least one cell or at least one beam within a cell by a user equipment that has also visited a cell or beam within a cell associated with a network node identified in said trajectory status request; means for transmitting said trajectory status request towards a network node; means for receiving a trajectory status report from said network node, said trajectory status report comprising said information regarding visiting of said at least one cell or said at least one beam by said user equipment. In some example embodiments, said apparatus further comprises: means for generating a user equipment history request, said user equipment history request identifying at least one cell or at least one beam, said user equipment history request requesting a user equipment history report for user equipment that have visited said at least one identified cell or beam; means for transmitting said user equipment history request towards a network node; means for receiving a user equipment history report; and means for collating user equipment trajectory information from said received trajectory status report and said received user equipment history report.

In some example embodiments, the apparatus further comprises means for transmitting said collated user equipment trajectory information to a further node.

In some example embodiments, the apparatus further comprises means for generating or updating a trajectory prediction algorithm in dependence upon said received trajectory information.

In some example embodiments, the means comprise: at least one processor; and at least one memory including computer program code, the at least one memory and computer program code being configured to, with the at least one processor, cause the performance of the apparatus.

In some example embodiments, the apparatus comprises an apparatus according to one aspect and according to a further aspect.

According to various, but not necessarily all, embodiments of the invention there is provided according to a further aspect a network comprising at least one apparatus according to a further aspect, and a plurality of apparatus according to one aspect.

According to various, but not necessarily all, embodiments of the invention there is provided according to a further aspect an apparatus comprising: means for receiving a trajectory status request, said trajectory status request requesting information regarding at least one cell at or at least one beam within a cell visited by said apparatus, said trajectory status request identifying a network node; and means for generating a mobility history indicative of cells visited by said apparatus, said means for generating said mobility history being configured to include said trajectory status request within said mobility history; means for determining cells that are camped on during a low power mode and for including said data in said mobility history; and means for storing said mobility history including said trajectory status request; means for transmitting said mobility history including said trajectory status request to a network node on reconnection to a network.

According to various, but not necessarily all, embodiments of the invention there is provided according to a yet further aspect a method comprising: generating a trajectory status report in response to receipt of a trajectory status request at an apparatus, said trajectory status request identifying a network node and requesting information regarding visiting of at least one cell or at least one beam within a cell by at least one user equipment that has visited said network node identified in said trajectory status request, said trajectory status report comprising said information regarding visiting of said at least one cell or said at least one beam by said at least one user equipment, said at least one cell or the cell containing said at least one beam comprising a cell associated with said apparatus; and outputting said generated trajectory status report for transmission to said network node identified in said trajectory status request.

In some example embodiments, said step of generating said trajectory status report comprises generating a true indication as said information regarding visiting of said at least one cell or said at least one beam within a cell where said at least one user equipment has visited said at least one cell or said cell of said at least one beam associated with said apparatus within a predetermined time period.

In some example embodiments, said trajectory status request comprises an identifying indicator, and said step of generating generates said trajectory status report to include said identifying indicator.

In some example embodiments, said trajectory status request comprises additional information, said additional information indicating at least one of: a type of network that said request is valid for, a number of transitions to new cells that said request remains valid for and a slice identifier indicating a slice of the network that said trajectory status request is valid for.

In some example embodiments, the method further comprises: transmitting said received trajectory status request to a further network node.

In some example embodiments, said step of transmitting said received trajectory status request to a further network node comprises transmitting said received trajectory status request as part of user equipment associated signalling. In some example embodiments, said step of transmitting said received trajectory status request transmits said received trajectory status request as part of history information for said at least one user equipment.

In some example embodiments, the method further comprises: generating a handover preparation message for transmission to a target network node, and including said received trajectory status request as part of said handover preparation message.

In some example embodiments, said transmitting of said generated trajectory status report to said network node identified in said trajectory status request comprises transmitting said generated trajectory status report as part of network signalling between network nodes and not associated with a user equipment.

In some example embodiments, the method further comprises: receiving a user equipment history request, said user equipment history request identifying at least one cell or at least one beam within a cell, said user equipment history request requesting a cell history for user equipment that have visited said identified at least one cell or at least one beam; monitoring cell histories of user equipment visiting a cell associated with said apparatus; and generating a user equipment history report in response to said monitoring step determining from said user equipment history that said user equipment has visited said at least one cell or at least one beam identified in said request, said user equipment history report indicating cells or beams that said user equipment have visited; transmitting said generated user equipment history report to said network node identified in said trajectory status request.

In some example embodiments, said user equipment history request comprises an indication of said at least one cell or said at least one beam and at least one other criteria; and said step of generating said user equipment history report comprises generating a user equipment history report for user equipment that have visited said indicated at least one cell or at least one beam and that meet said at least one other criteria.

In some example embodiments, said user equipment history request comprises data indicating further information required in said user equipment cell history, said step of generating said user equipment history report comprising generating said user equipment history report to include said further information requested. In some example embodiments, the method further comprises: transmitting said received trajectory status request to at least one of said at least one user equipment visiting said cell associated with said apparatus.

In some example embodiments, said step of receiving said trajectory status request comprises receiving said trajectory status request from at least one of: a user equipment when said user equipment reconnects to said network via a cell associated with said apparatus; a control network node as part of a user equipment context when said user equipment reconnects to said network via a cell associated with said apparatus; a network node, said trajectory status request being received in user equipment associated signalling; and an operations, administration and maintenance 0AM node.

According to various, but not necessarily all, embodiments of the invention there is provided according to a yet further aspect a method comprising: generating a trajectory status request requesting information regarding visiting of at least one cell or at least one beam within a cell by a user equipment that has also visited a cell or beam within a cell associated with a network node identified in said trajectory status request; outputting said trajectory status request for transmission towards a network node associated with said cell; and receiving a trajectory status report from said at least one network node, said trajectory status report comprising said information regarding visiting of said at least one cell or said at least one beam by said user equipment.

In some example embodiments, the method further comprises: generating a user equipment history request, said user equipment history request identifying at least one cell or at least one beam, said user equipment history request requesting a user equipment history for user equipment that have visited said at least one identified cell or beam; transmitting said user equipment history request towards a network node; receiving said user equipment history; and collating user equipment trajectory information from said received trajectory status report and said received user equipment history.

In some example embodiments, the method further comprises: transmitting said collated user equipment trajectory information to a further node.

According to various, but not necessarily all, embodiments of the invention there is provided according to a yet further aspect a method comprising; in response to receipt at an apparatus of a trajectory status request, said trajectory status request identifying a network node and requesting information regarding at least one cell at or at least one beam within a cell visited by said apparatus, generating a mobility history indicative of cells visited by said apparatus and including said trajectory status request within said mobility history and storing said mobility history; entering a low power mode; determining cells that are camped on during said low power mode and storing data indicative of said cells in said mobility history; on reconnection to a network and outputting said mobility history including said trajectory status request for transmission to a network node.

According to various, but not necessarily all, embodiments of the invention there is provided according to a further aspect a computer program which when executed by a processor on an apparatus is operable to control said apparatus to perform a method according to one of the yet further aspects.

In some example embodiments, the means for receiving may comprise circuitry configured to receive or a receiver. The means for generating a trajectory status report may comprise circuitry configured to generate a trajectory status report. The means for generating a trajectory status request may comprise circuitry configured to generate trajectory status request. The means for managing mobility of user equipment may comprise circuitry configured to manage the mobility of user equipment. In all of the above cases the circuitry may comprise a processor programmed for that function. The means for transmitting may comprise circuitry configured to transmit or a transmitter. The means for monitoring cell histories may comprise circuitry configured to monitor cell histories of user equipment, while the means for generating a user equipment history report may comprise circuitry configured to generate the user equipment history report. The means for generating a user equipment cell history request may comprise circuitry configured to generate the user equipment cell history request. Again this circuitry may comprise a processor configured to perform these functions.

The means for generating a mobility history may comprise circuitry configured to generate a mobility history. The means for determining cells may comprise circuitry configured to determine the cells while the means for storing may comprise circuitry configured to store or a data store. The means for collating user equipment trajectory information may comprise circuitry configured to collate user equipment trajectory information. Further particular and preferred aspects are set out in the accompanying independent and dependent claims. Features of the dependent claims may be combined with features of the independent claims as appropriate, and in combinations other than those explicitly set out in the claims.

Where an apparatus feature is described as being operable to provide a function, it will be appreciated that this includes an apparatus feature which provides that function or which is adapted or configured to provide that function.

BRIEF DESCRIPTION

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

FIG. 1 illustrates a trajectory prediction example in which the Recorded Trajectory Ti is illustrated with a solid line while the predicted trajectory T2p is illustrated with a dashed line;

Fig. 2 illustrates examples of different UE trajectories;

Fig. 3 illustrates example signalling of trajectory status requests and reports according to an example embodiment;

Fig.4 illustrates example signalling of user equipment history requests and reports according to an example embodiment;

Fig 5 schematically shows base stations, user equipment and an 0AM node according to an example embodiment;

Fig. 6 shows steps performed at a network node according to an example embodiment;

Fig. 7 schematically shows steps in a method performed at a UE according to an example embodiment; and

Fig.8 shows steps of a method performed at the originating network node according to an example embodiment.

DETAILED DESCRIPTION

Before discussing the example embodiments in any more detail, first an overview will be provided.

Embodiments provide techniques for collecting user equipment trajectory data from distributed nodes such that the data is available at one location thereby enabling trajectory prediction circuitry which may employ machine learning to have access to this data. In this regard a network node that serves a UE will know its cell history and the target cell, but there is no knowledge of what happens next. Embodiments seek to collect data regarding these subsequent steps such that the data can be used to generate and enhance a trajectory prediction algorithm. Embodiments also seek to increase the data available regarding the cells visited by a UE and in some cases by a UE also in idle or inactive mode. In this regard many UEs are in idle mode much of the time, so collecting data regarding idle mode UE’s trajectory is important if an accurate prediction algorithm for the UE trajectory is to be generated and maintained. Example embodiments also provide control of the amount of data collected, by triggering the sending of data using a trajectory status or user equipment history request and where the data is no longer required may halt the sending of data by no longer generating trajectory status requests or by cancelling the user equipment history reporting.

Example embodiments transmit trajectory status requests through the network, in some cases between network nodes, the trajectory status requests query whether user equipment that have previously visited a cell or beam associated with the network node generating the request have arrived at a cell of another network node. The “another” network node can respond with a true indication when it receives the trajectory status request conveyed by a network node that earlier served the UE via UE associated signalling, or from the UE when it connects to the "another" network node. The "another" network node may also subsequently provide a status update by generating a false indication indicating that no user equipment that has visited the cell associated with the requesting node has visited that "another" network node within a predetermined observation period.

The trajectory status requests may in some embodiments comprise an identifying indicator that maybe used by the originating apparatus that requests this information to correlate the later message with the original request. This may be a local UE ID or it may be information identifying conditions under which the UE was served.

In some embodiments, the trajectory status request may comprise additional information that may act as a filter to the data received such that only data that is considered particularly relevant is collected. This additional information may specify a type of cell whether it is a small or larger cell, for example a coverage or capacity cell, it may specify a number of hops that the request is valid for so that it only collects information where the user equipment has visited the originating cell within a certain number of hops or it may indicate a slice of the network that the trajectory status request is valid for. Where the number indicates beams rather than cells this information is generally most useful close to the requesting node, so in this case it may be that the number of hops indicated is smaller than where cells are indicated.

This number may be larger if it indicates a number of hops with respect to beams than if it indicates a number of hops with respect to cells.

The trajectory status request may be transmitted between nodes as part of the user equipment’s associated signalling, for example it may be included as part of history information for the user equipment that is transmitted between the network nodes and it maybe part of the handover preparation message such that the request is transmitted to the target network node of the user equipment. In this way, requests can be transmitted between network nodes with the UE associated signalling and data collected accordingly.

Although the request may be propagated through the network with user equipment associated signalling, the transmission of the trajectory status report with the requested information may be done as part of network signalling between network nodes not associated with the user equipment. For example, it may be part of one of a Xn setup message or a NG_RAN node configuration update message or indeed as some other network signalling message. In addition to transmitting requests requesting subsequent network nodes the user equipment has visited to report back with a trajectory status report, additional requests may be generated for example a user equipment history request. This request may be transmitted to network nodes that have responded with trajectory status reports and these network nodes when they receive the history request will transmit user equipment history information back to the network node that initiated the user equipment history request, which is the same network node that initiated and is identified in the trajectory status requests. The user equipment history information will include a list of cells visited and these will include cells that the user equipment camped on when in idle mode or indeed when it was inactive. User equipment are in a lower power mode for much of the time and thus, being able to collect information regarding their trajectory in this mode can be significant. Embodiments use information collected from user equipment in the active mode using the trajectory status requests to identify potential trajectories of user equipment and then use the user equipment history request to gather more information and in particular information regarding UEs that camped on the network node that initiated the user equipment history request in idle or inactive mode. In some cases the user equipment history request may include a certain criteria to limit the amount of data collected, this may indicate a certain maximum number of hops that the request is interested in. The hops may be at the cell or the beam level. It may also indicate a particular network slice that information is required for. Furthermore, the user equipment history request may in some cases comprise data indicating further information that is required, the further information may indicate whether the full user history cell and/or beam is required or whether an abbreviated history is required. It may also indicate whether additional information such as the time camped on a cell or a reason for a handover is wanted. The user equipment history requests and corresponding reports are transmitted between network nodes.

The node that generates the original trajectory status request maybe a network node in the network or it may an 0AM node that transmits either a request or a signal indicating that a request should be generated to a network node for further transmission. The originating node will collect the data from the trajectory status reports and the user equipment and may collate this data for use in a machine learning algorithm for the prediction of the trajectory of user equipment. Collated data may be used in an algorithm on the node itself or it may be forwarded to a 0AM node that performs this function.

Artificial Intelligence (Al) including machine learning (ML) algorithms are considered to provide a powerful tool to help operators to improve the network management and the user experience by providing insights based on autonomous analysis and processing of collected data. Embodiments seek to provide the current NG- RAN architecture and interfaces with means for collecting data to enable Al support for 5G deployments. The NG- RAN is a distributed architecture without any central node such that the use of such analysis is challenging.

In legacy networks, limited trajectory prediction is typically performed by analysis of the UE's mobility history, e.g. gathered information about past UE mobility in idle (RRC idle) and connected (RRC connected) mode, as well as locally available information (in particular radio measurements provided by the served UE). The UE's mobility history is uploaded from the UE to the network when the UE enters RRC connected mode, and is forwarded to further serving base stations (during handover preparation signalling) in case of connected mode mobility. This information contains a list of earlier serving cells (which also identifies the base stations controlling these cells), and a list of cells on which the UE has camped (also this list of cells identifies the base stations controlling these cells). The list also contains associated (per-cell) information elements, including time spent in the cell.

A base station may select the first target node/ cell for handovers based on this information but will not have visibility of whether it performed an optimal choice taking into account further UE mobility beyond this first target cell. Trajectory prediction information enhanced beyond the first target cell could therefore also improve the choice of the first target cell, e.g. in order to reduce the total number of handovers if the UE has a high probability of staying just a short time in a given candidate target cells. Furthermore, such enhanced trajectory prediction could enable the network, including other base stations, to anticipate specific traffic distributions by performing traffic steering and/or energy saving actions, which all are part of the use cases agreed by RAN3 as mentioned above. Enhanced trajectory prediction can also be valuable in some slicing specific scenarios e.g., to determine whether slice remapping should be performed (if a UE is expected to stay longer in a cell or area not supporting the current allowed slice).

An ML algorithm may be used for such enhanced trajectory prediction. There are three main categories of ML algorithms, namely a) Unsupervised Learning, b) Supervised Learning and c) Reinforcement Learning. Unsupervised learning is typically used for clustering of a certain population in groups since the algorithm operates without any feedback on what the expected target/estimate should be. Supervised learning is different in that there exists a “target variable” which needs to be predicted from a set of independent variables. Prediction happens by mapping of those variables to the desired target variable while tiying to reach as close as possible to it with a high probability. Namely the training process in supervised learning completes when a variable is predicted with a high accuracy. Both supervised and unsupervised learning have 2 phases, the training phase and the inference phase. In supervised and unsupervised learning, training and inference are independent processes that can run in the same or different host (entity). Reinforcement Learning (RL) is different in that it is based on a control loop where training and inference take place at the same time. Specifically, Reinforcement Learning comprises a system where an agent taking an action interacts with a stochastic environment by switching a state and receiving a reward.

It would be desirable to be able to collect UE trajectory data that may provide enhanced data availability for an AI/ML training phase, or enable running the control loop between training and inference in case of Reinforcement Learning. Example embodiments increase UE trajectory data availability that allows AI/ML to be used in predicting the UE trajectory.

In the training phase the ML algorithm may be exposed to data transposed from real- world observations corresponding to what will become input data as well as output data of the trained ML algorithm. The data may correspond to information locally available in the node performing the training, or it may correspond to information received e.g. on network interfaces. For a UE trajectory prediction problem the information to be transposed into data provided to the input layer of the ML algorithm in inference phase could be the observed UE's trajectory until the UE reaches a point A (recorded trajectory information Ti). Information Ti could comprise a list of visited cells (on which the UE camped in idle mode or inactive mode, or to which the UE was connected), and the information could also include other information like the beams measured by the UE or serving the UE, radio measurements reported by the UE or performed by the network, and/or other characteristics like the UE speed. Another part of the information needed in the training phase would typically correspond to actual observations of the UE's trajectory beyond the point A (trajectory information T2), typically composed of a list of cells/beams. In the inference phase the output information of the ML algorithm will correspond to prediction information relative to T2, which we hereafter name T2p. This is illustrated in Fig. 1.

Fig.i shows base station 20 within a network with UE 50 moving to base station 20 from base station 20E. UE 50 then moves to base station 20F. Base station 20 is aware that UE 50 has come from base station 20E from its cell history, thus, that trajectory Ti is known, however, where UE 50 goes next (trajectoryT2p to base station 20F) is not known at base station 20. This information would be useful to any algorithm used to predict UE trajectories, and thus, example embodiments seek to collect this information by transmitting a trajectory status request from base station 20 to base station 20F asking whether the UE that has visited it, has visited this cell, It seeks to determine T2.

As an example, if the ML algorithm is based on a Neural Network (NN), both the information Ti and the information T2 would be transposed into the data format used for respectively input data and output data of the NN. The data would be exposed to the NN, and a method known as backpropagation (backward propagation of errors) would then be used to train the NN by adjusting the weight and bias values of the NN. In another example the ML algorithm may use pattern recognition techniques, first determining, based on Ti and T2, e.g. to which extent UEs in the coverage area follow specific paths, identify these paths and also possibly identify intersections of such paths with a certain probability where trajectories could fork. In coverage areas where such paths exist (e.g. in urban area with preponderant traffic following the streets, or rural areas crossed by roads), Markov-based models for example may then use Ti to infer T2p (e.g. the probability that a given path will be followed) after a training phase similar to the one described for NN above.

Enhanced trajectory prediction could be addressed by a machine learning algorithm but only if data regarding the observed historic trajectory Ti and the actual trajectory of a predicted trajectory T2 was available for the training phase of the ML algorithm. In the absence of a centralized node the collection of such data is challenging.

It can be noted that the problem of enhanced trajectory prediction can be solved by current state of the art if the ML algorithm is executed within a centralized RAN node, considering that such a node can directly collect the observed trajectory information (Ti and T2) from each underlying node for the training phase of the ML algorithm. If the centralized node also hosts the ML algorithm during the inference phase, it can forward T2p to underlying nodes in need of such information. However, there is no such centralized node in the distributed NG- RAN architecture. 0AM can be assumed to have some amount of centralization, though in several cases of interest there may be multiple OAMs managing different sets of gNBs in which case there is no unique central entity in the system.

Example embodiments seek to address these issues in a distributed architecture by:

• Seeking to make T2 available in a node (e.g. gNB) in a distributed RAN architecture, for the needs of the training phase of an ML algorithm.

• Seeking to increase the quantity of Ti information available in a node (e.g. gNB), in a distributed RAN architecture, e.g. to ensure a quantity of data sufficient to achieve statistical reliability of the training of an ML algorithm or for collecting statistical information regarding different trajectories at a gNB e.g., a probability with which a certain fraction/number/percentage of UEs follow a certain trajectory.

Training can be located in the RAN at a gNB (gNB-CU in case of split architecture). As another alternative, (offline) training can be located in the 0AM that manages a gNB. Note that it is possible that different gNBs may be managed by different 0AM systems. By forwarding the collected information by a gNB to the managing 0AM, it enables different 0AM systems to train independently an ML Model for trajectory prediction. A Trained ML Model in the 0AM can be subsequently deployed in the RAN for use and retraining, at gNBs managed by the 0AM.

One potential solution that takes advantage of the existing mechanism for collection of UE history, might be to mandate each of the base stations serving a given UE to inform other earlier serving base stations or base stations controlling cells on which the UE has camped about the list of cells/beams visited by the UE as per recorded information (UE History Information). Although this may address the problem there is an overhead associated with it of extensive signalling, and much of this signalling may not be required in a network where some nodes do not support ML. Another drawback is that the signalled information (Ti, T2) is only needed during the ML algorithm training phase, and such signalling would therefore be a waste of network resources if done permanently.

Example embodiments therefore propose the use of a specific trigger (which could originate either in the gNB or in the 0AM system) and could be related to e.g., an ML algorithm training phase of a given base station or simply upon observation of Handover performance reduction at the gNB which creates the need for the latter to obtain statistical information about its handovers or when e.g. the operator wants to monitor a certain condition e.g., if there was a slice configuration change. This trigger will enable a base station A serving a UE 1 to send a request to future serving base stations of UE 1 to send back T2 information. In some embodiments an additional histoiy request could be sent to cells identified in the T2 information for any UE history information of any UE they are serving that has earlier camped (in RRC idle mode) on a cell under base station A as per the UE histoiy uploaded from the UE, or was previously served by base station A as per UE history transferred by the network. This solution would address both the above described problems relating to collecting additional Ti and T2 data.

Alternatively, the request may be limited to sending back UE history information for UE 1 only, in which case the request may be associated with an ID or bit string local to base station A enabling later analysis in base station A (similar to XnAP Mobility Information IE). The request is included in the UE history information transmitted on network interfaces. This solution specifically addresses the problem of increasing the amount of Ti information available. In some example embodiments, the request may also be transmitted to the UE for inclusion in its own UE mobility history. The information will in that case be stored in the UE during transition to idle mode, and uploaded to the network upon later connection. Another alternative to enable the request to survive idle mode transitions would be to store the information in the UE context of the core network, for retrieval by the RAN when the UE reconnects. These enhancements will therefore further improve the collection of data by increasing the number of base stations that will report back UE mobility history, and enabling trajectory information reporting from even more distant nodes.

Fig. 2 provides some examples with three different UE trajectories all going via base station 5. Relative to the issue of making the T2 information available, if there is a first UEi (or UE2) being in RRC connected mode while under coverage of base station 5, example embodiments enable base station 5 to become aware of future UE trajectories, including UEs in RRC idle mode, which go via this base station and continue via neighbour base stations and further to base station 9 (or base station 10).

If the technique is based on reporting of specific UE only (UE 1 described above), the technique will be limited to providing increased information for UEs served under the specific conditions of UEi or UEs that have followed the same or similar trajectory Ti. The conditions under which the specific UE (UEi) is served are identified by inclusion of information similar to XnAP Mobility Information IE in the trajectory status request and corresponding report.

The trajectory of UE3 may illustrate a trajectory prediction use case relative to e.g. slice offered in a very specific geographical area.

In some cases the information collected maybe beam specific as opposed to cell specific, such that the originating base station may specify both a cell and a beam that the UE has visited and request information on both a cell and a beam that the UE then visits.

However, while the above mechanism all provide ways of increasing Ti and/ or T2 data in some example embodiments techniques are provided that enable the base stations to control the quantity that is reported back by introducing the following filtering steps: Main step 1: A serving base station A identifies other base stations covering areas that a UEi will go through by requesting these further serving base stations of UEi to report back presence of the UE. This request is propagated in UE associated signalling from source base station to target base station.

Main step 2: The serving base station A requests, stops or refines the inter-BS reporting of UE history information according to its needs for training of the ML algorithm for trajectory prediction.

Description of Main step 1:

In more detail, the main step 1 should enable a BS A to identify base stations covering areas that a UE it is currently serving will later go through. For this purpose, BS A includes an indicator carrying its own identification in information forwarded to future serving base stations. In order to enable this information to survive transition via RRC idle mode, this indicator can also be sent to the UE for later upload to the network, or stored in the UE context of the core network.

A practical approach to carry this indicator would be to include it in the UE History Information IE already carried over X2 and Xn interfaces, as well as on Si/NG interfaces in case of handover signalled via the core network. This may be done as follows (the IE relative to NR cells is defined in 3GPP TS 38.413 (NGAP)):

Last Visited NG- RAN Cell Information

This IE contains information about a cell. In case of NR cell, this IE contains information about a set of NR cells with the same NR ARFCN (absolute radio frequency channel number) for reference point A, and the Global Cell ID IE identifies one of the NR cells in the set. The information is to be used for RRM (radio resource management) purposes.

When detecting presence of the Trajectory Information Request IE, a receiving base station B should send back information to the requesting node (as identified by information contained in the Global Cell ID already present) that it is serving the UE. BS A and B may not be direct neighbours, and an Xn interface may therefore not exist.

However, the purpose of the present signalling is to enable further information exchange between BS A and B, which would justify setting up an Xn (X2) interface. The signalling procedure could therefore be Xn Setup, or NG- RAN Node Configuration In the case where an Xn interface already exists then the newly added information could be included in the Served Cell Information NR IE and/or Served Cell Information E-UTRA (evolved universal terrestrial radio access) IE, and a simple indicator would be sufficient (3GPP TS 38.423 clauses 9.2.2.11, 9.2.2.12):

As can be understood from the proposed semantics description, this signalling may also provide support for e.g. changes in urban environment or network topology reconfigurations changing the UEs' trajectories.

Another option is to introduce a new message to convey this information, illustrated as Trajectory Status Transfer message in Fig. 3. In this example also a UE Info IE is included as part of the Trajectory Status Req in UE History, and this information is returned to the requesting BS2 in the Trajectory Status Transfer message, enabling the BS2 to correlate the latter message with the initial Trajectory Status Req. UE Info IE may consist of e.g. a local UE ID or other information identifying e.g. conditions under which the UE was served.

In the example call flow of Fig. 3, the UE is first served by cell 11 and 12 controlled by BSi, 20E. BSI, 20E does not support AI/ML, or is not in AI/ML learning phase, and therefore provides UE History information as per legacy functionality (including cell 12, 11 as well as earlier cells visited by the UE). The call flow further shows mobility from BS2 20 to BS3 20F1. BS220 supports AI/ML and needs information for training of a trajectory prediction ML model and is the originating base station for the trajectory status requests. 11 can be seen that the Trajectory Status Req IE corresponding to BS2 20's request is propagated from BS3 20F1 further to BS420F2 and BS5 20F3. These nodes will send back confirmation to BS220 using the Trajectory Info Transfer message or other option described above. However such information (e.g. Trajectory Status Transfer message) sent from BS3 20F1 to BS2 20 would not serve any particular purpose because the BS2 20 is already aware of BS3 20F1 being on the path of the UE.

Fig. 3 provides an example call flow for Main step 1 - that is the reporting of base stations on a UE's trajectory beyond the requesting base station. The HO Preparation procedure is composed of the HANDOVER REQUEST message (where in this embodiment the additional information in the form of a trajectory status request is introduced) and HANDOVER REQUEST ACKNOWLEDGE message. The Xn Setup procedure is composed of the XN SETUP REQUEST message (where the new information in the form of a trajectory status report is transmitted) and the XN SETUP RESPONSE message. The NG-RAN Configuration Update procedure is composed of the NG- RAN CONFIGURATION UPDATE message (where the additional information in the form of a trajectory status report is transferred) and the NG-RAN CONFIGURATION UPDATE ACKNOWLEDGE message. The Trajectory Status Transfer procedure is a new signalling procedure, and could be standardized using a single TRAJECTORY STATUS TRANSFER message.

In Fig.3 the UE starts at BSi 20E base station and travels to BS2 base station 20. BS2 is aware that the UE has visited BSi 20E but wants to know where it may go next and thus, generates a trajectory status request requesting network nodes that receive a visit from a UE that has also visited BS220 to report this visit to BS220 in a trajectory status report. BS2 20 transmits the trajectory status request in UE associated signalling, in this embodiment in the handover preparation message that it transmits to target base station BS3 20F1. This handover preparation signal comprises the UE history and the new trajectory status request. BS3 20F1 will transmit the trajectory status request further to a subsequent base station as part of its handover signalling and in this way the request reaches BS420F2 which in turn forwards the request to BS5 20F3. Also, upon reception of the trajectory status request originating at BS2 20, BS420F2 transmits this trajectory status information as a trajectory status report via network signalling back to the requesting base station BS2 20. Similarly also BS5 20F3 transmits this information via network signalling back to BS220. In this way BS2 20 receives T2 trajectory information and can determine that BS420F2 and BS5 20F3 are located on this trajectory.

Example embodiments also provide the following change in UE History Information from the UE message and in particular in its corresponding NR Mobility History Report IE. Embodiments enhance the timeSpent parameter indicating the duration of stay in the cell or in any cell selection state and/ or camped on any cell state in NR or E-UTRA to reflect time spent in RRC Idle/RRC Inactive and in RRC Connected states respectively. For this purpose, two new parameters are used that can be used to capture those times individually as shown below:

By keeping track of the time spent by a UE in a cell while being in RRC Idle/Inactive and RRC Connected states separately it helps the network keep track in more detail of the UE’s movement and allows it to determine whether the mobility decision was taken by the UE or by the network. As an example, the network can obtain information on those trajectories that crossed the base station's coverage area in RRC idle or inactive mode and can further be aware for how long a UE stayed in a given cell when the UE was in idle, inactive or connected state.

Description of Main step 2:

This step enables the base stations to request, stop or refine inter-BS reporting according to the needs for training of the ML algorithm for trajectory prediction. BS A triggers a procedure similar to legacy X2AP/XnAP Resource Status Reporting Initiation procedure towards base stations B, C, etc. The base stations are selected based on already known information (BS3) or information gathered in Main step 1, i.e. among the base stations (BS4, BS5) that report back confirmation information (trajectory status report) as per Fig. 3. These base stations then report back UE history information in a procedure similar to the X2AP/X11AP Resource Status Reporting procedure (event-triggered reporting). The BS A can also stop or refine the reporting according to the needs created by training of the ML algorithm for trajectory prediction. A preferred option is that the BS B provides the full UE History information available in its context for the UE, which also includes information from earlier idle mode mobility if this information was uploaded from the UE during the ongoing RRC connection. Other alternatives are possible in the reporting, e.g. by including beam related information i.e. by including the beam identities (SSBs or CSI- RSs) serving a UE in the visited 1 ist of cells. Other options that might be used include reporting on a coarser level, e.g. an unordered lists of visited cell as opposed to the ordered list of cells (finer reporting granularity) currently recorded in UE history.

An example call flow is provided in Fig. 4. BS A initiates UE History reporting by sending UE History Report Request message to BS B, which confirms the request using UE History Report Response message. When the BS B then serves a UE that has earlier been served by BS A, the UE History Information relative to the UE is reported back to BS A.

Fig. 4 shows how additional Ti data maybe retrieved by transmitting a UE history request. UE history request is transmitted to base stations that have appeared in the trajectory status report as being those that the UE has travelled to from the originating base station and the UE history request requests information regarding the cell history of UE’s that have visited these cells and have also visited the originating base station. In this way, UE’s that are in idle mode or inactive mode and visit these base stations may be captured and thus, additional Ti data can be determined and collated in the user equipment trajectory data for use in the machine learning algorithms.

In some example embodiments, a base station serving a UE may be able to use specific information for this UE that the BS has gathered while serving the UEs (e.g. measurement reports, served beams, estimated speed, ...) that is not reflected in the UE history. Such locally available UE-specific information can be retrieved with trajectory information reported back from further serving BSs. This can be done by an additional update of the last visited cell information, e.g. as indicated below:

Last Visited NG- RAN Cell Information

This IE contains information about a cell. In case of NR cell, this IE contains information about a set of NR cells with the same NR ARFCN for reference point A, and the Global Cell ID IE identifies one of the NR cells in the set. The information is to be used for RRM purposes.

Upon reception of the UE Specific Trajectory Information Request IE, the BS B should signal back the provided information (bit string) to BS A using non UE-associated signalling. Setup of an Xn interface may be needed for this purpose, or signalling can be performed via the core network. BS A will then use the information (bit string) to identify the UE or identify the conditions specific to handling of this UE. UE Specific Trajectory Information Request corresponds to UE Info in Fig. 3.

A gNB can send to its 0AM the information received by neighbouring gNBs and 0AM can use this information to locally train a trajectory prediction algorithm or to obtain statistical information regarding trajectories followed by different UEs in the cells/beams of the gNBs under the control of 0AM.

UE History per beam granularity

Legacy UE History information is conveyed on a per cell granularity. Future 3GPP releases may convey this information also with a per beam granularity. Embodiments are able to provide the information on either a per beam or a per cell basis. Where a hop count is used as a criteria in the request, the hop count information could also indicate the number of beams visited by the UE (Beam Hop Count), however counting the number of visited cells would also convey relevant information. With UE History Information on a per beam granularity, trajectory information from the closest neighbour cell (Cell Hop Count = 1) is also relevant information.

In summary example embodiments enable trajectory prediction in distributed radio access networks by addressing problems related to data collection that can be used for example for the ML training phase. Important use cases for which trajectory prediction is an essential building block are energy saving, load balancing, mobility management, slice remapping.

Fig. 5 schematically shows some component devices within a network according to an embodiment. This network comprises an 0AM node 10 which in this embodiment has trajectory prediction circuitry 12 that uses machine learning within it and transmitting/ receiving circuitry 14. Trajectory prediction circuitry 12 may send a request via transmitting circuitry 14 to base station 20 requesting trajectory data for UEs 50 passing through a cell or a beam associated with the cell of base station 20. In response to this, trajectory status request generating circuitry 22 will generate a trajectory status request and will transmit it with UE associated signalling to a neighbouring base station 20F using transmitting/ receiving circuitry 26. The neighbouring base station will transmit this request further with UE associated signalling. Base station 20 will receive via network signalling trajectory status reports from base stations that UEs that have visited base station 20 later visit, via network signalling and data collating circuitry 24 within the base station 20 will collate this information with other UE trajectory history information that it receives and will transmit it to the 0AM. User Equipment history request generating circuitry 28 within base station 20 will determine from the received trajectory status reports the base stations that UEs that have visited base station 20 visit and will transmit user equipment history requests to these base stations. In this way trajectory data regarding the trajectory of additional UEs will be received. In some cases the trajectory status request may be transmitted to a UE 50 which may store the request with its mobility data and the request and that data may be transmitted to the network as part of the UE context on reconnection to the network.

Neighbouring base station 20F that receives the trajectory status request using a transmitting/ receiving circuitry 26 will, using UE history monitoring circuit 25 monitor UEs that pass through the cell or the beam indicated by the request to determine whether they have previously visited a cell associated with base station 20. If they have then trajectory report generating circuitry 27 generates a response to the UE trajectory status request that will be sent to base station 20 via network signalling.

Furthermore, if after a predetermined observation period there have been no such UEs to report, a further response may be sent with an indication that no UE has passed by that have previously visited a cell associated with base station 20. In some embodiments, the trajectory status request may comprise further criteria or additional information. The further criteria may specify for which cells the request is valid. That is, it may specify a certain number of hops or a particular network slice or a particular size of cell. It may also comprise some identifying means that identifies the request to the originating base station and in this case this identifier will be included in the response.

Base station 20F will forward the trajectory status request with UE associated signalling to a subsequent base station not shown. The subsequent base station will process this trajectory status request in the same way that base station 20F did and return information to base station 20. Base station 20F will also receive the user equipment history requests and will generate user equipment history reports using user equipment history report generating circuitry 29 where the user equipment has visited the cell of base station 20 and will transmit these reports to base station 20.

In some embodiments, base station 20 or 20F may transmit the trajectory status request to UE50. UE50 may store the trajectory status request with cell history data generated using circuitry configured to generate a mobility history 54 in the data store 52 within the UE. It may retain this information while it is in idle or in inactive mode and when reconnecting to the network will transmit to the connecting base station the cell history and the trajectory status request using transmitting/ receiving circuitry 56. In this way, information regarding cells visited in idle or inactive mode will be received by the network node along with an indication that a network node 20 identified in the trajectory status request requires some trajectory status information.

Figs 6 and 7 show flow diagrams of methods performed at a network node and mobile apparatus respectively.

In the method performed at the network node shown schematically in Fig. 6 at step S10 a trajectory status request is received at the base station. At D5 it is determined whether a UE that has visited this cell has also visited the cell associated with the node identified in the request. If it has, then at step S20 a trajectory status report is generated with a true indication, whereas if it has not then at step S30 a trajectory status report with a false indication is generated.

The respective reports are then transmitted to the network node identified in the request at step S40 and the trajectory status request that was received is forwarded to a further network node in UE associated signalling at step S50. This step is conditional on the UE handing over to the further network node and not entering idle mode beforehand. In some embodiments there is an additional step S60 where the trajectory status request is transmitted to the UE. This additional step allows the status request to remain active and not expire even if the UE goes to idle mode before the next handover.

In some embodiments step S70 may be performed where a UE that reconnects to the network at this base station has a mobility history comprising the trajectory status request. Where this is the case step S80 is then performed where data indicative of the mobility history is uploaded from the UE and is transmitted to the network node identified in the report. This mobility history may contain idle mode cell history data. In this way information regarding future T2 trajectories from the originating base station that generated the request are sent to it along with additional history data that includes trajectory data of UEs in idle or inactive mode.

Fig. 7 shows an example embodiment of a method performed at a mobile apparatus such as a UE. In this example embodiment at step S110 a trajectory status request is received at a UE. The UE updates its mobility history report indicative of the cells visited ateach change of cell and includes the trajectory status request or an indication of it within the mobility history at step S120. The UE then stores this information in step S130 and enters low power mode, this may be an idle or inactive mode at step S140. During this low power mode the UE may determine the cells that it camps on and add them to the mobility history at step S150. At step S160 the UE reconnects to the network and transmits the mobility history including the trajectory status request to the network node that it reconnects with.

Fig.8 shows steps of a method performed at the originating network node according to an example embodiment. In this embodiment the trajectory prediction algorithm is located in the 0AM and it is the 0AM that triggers the collection of data by transmitting a signal to the network node. In other embodiments the trajectory prediction algorithm may be on or associated with the network node itself in which case there will not be an initial step S200. In this embodiment the network node receives the signal at step S200 and in response generates a trajectory status request at step 210 and transmits this to a neighbouring network node in UE associated signalling at step S220. The network node receives a trajectory status report at step S230 and generates a user equipment history request and transmits the request to the network node indicated in the trajectory status report at step S240. At step S250 one or more user equipment history reports are received. Steps S210 to S250 may be repeated many times until it is determined that no more data is currently required, perhaps in response to a further signal from the 0AM.

At step S260 the received trajectory data is collated and at step S270 is transmitted to the entity in charge of trajectory prediction, which in this example embodiment is the 0AM, but in other embodiments, may be a processor on or associated with the network node.

The above-described methods can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of said above-described methods. The program storage devices maybe, e.g., digital memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. The embodiments are also intended to cover computers programmed to perform said steps of the above-described methods.

As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable):

(i) a combination of analog and/or digital hardware circuit(s) with software/firmware and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

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

Although embodiments of the present invention have been described in the preceding paragraphs with reference to various examples, it should be appreciated that modifications to the examples given can be made without departing from the scope of the invention as claimed.

Features described in the preceding description maybe used in combinations other than the combinations explicitly described.

Although functions have been described with reference to certain features, those functions may be performable by other features whether described or not.

Although features have been described with reference to certain embodiments, those features may also be present in other embodiments whether described or not.

Whilst endeavouring in the foregoing specification to draw attention to those features of the invention believed to be of particular importance it should be understood that the Applicant claims protection in respect of any patentable feature or combination of features hereinbefore referred to and/ or shown in the drawings whether or not particular emphasis has been placed thereon.

Claims

1. An apparatus, comprising: means for receiving a trajectory status request, said trajectory status request identifying a network node, said trajectory status request requesting information regarding visiting of at least one cell or at least one beam within a cell by at least one user equipment that has visited said network node identified in said trajectory status request; means for generating a trajectory status report in response to receipt of said trajectory status request, said trajectory status report comprising said information regarding visiting of said at least one cell or said at least one beam by said at least one user equipment, said at least one cell or the cell containing said at least one beam comprising a cell associated with said apparatus; and means for transmitting said generated trajectory status report to said network node identified in said trajectory status request.

2. An apparatus according to claim 1, wherein said means for generating said trajectoiy status report is configured to generate a true indication as said information regarding visiting of said at least one cell or said at least one beam within a cell, where said at least one user equipment has visited said cell or said at least one beam within said cell associated with said apparatus within a predetermined time period.

3. An apparatus according to claim 1 or 2, wherein said trajectory status request comprises an identifying indicator, said means for generating being configured to generate said trajectory status report to include said identifying indicator.

4. An apparatus according to any preceding claim, wherein said trajectory status request comprises additional information, said additional information indicating at least one of: a type of network node that said request is valid for, a number of transitions to new cells that said request remains valid for and a slice identifier indicating a slice of the network that said trajectory status request is valid for.

5. An apparatus according to any preceding claim, said apparatus further comprising means for transmitting said received trajectory status request to a further network node.

6. An apparatus according to claim 5, wherein said means for transmitting said received trajectory status request to a further network node is configured to transmit said received trajectory status request as part of user equipment associated signalling.

7. An apparatus according to claim 5 or 6, wherein said means for transmitting said received trajectory status request is configured to transmit said received trajectory status request as part of user equipment history information for said at least one user equipment.

8. An apparatus according to any one of claims 5 to 7, said apparatus further comprising means for managing mobility of user equipment, said means for managing mobility being configured to generate a handover preparation message for transmission to a target network node, said means for managing mobility being configured to include said received trajectory status request as part of said handover preparation message.

9. An apparatus according to any preceding claim, wherein said means for transmitting said trajectory status report to said network node identified in said trajectory status request is configured to transmit said trajectory status report as part of network signalling between network nodes and not associated with a user equipment.

10. An apparatus according to any preceding claim, further comprising: means for receiving a user equipment history request, said user equipment history request identifying at least one cell or at least one beam within a cell, said user equipment history request requesting a cell history for user equipment that have visited said identified at least one cell or at least one beam; means for monitoring cell histories of user equipment visiting a cell associated with said apparatus; and means for generating a user equipment history report in response to said means for monitoring determining from said user equipment history that said user equipment has visited said at least one cell or at least one beam identified in said request, said generated user equipment history report indicating cells or beams that said user equipment has visited; means for transmitting said generated user equipment history report to said network node identified in said trajectory status request.

11. An apparatus according to claim io, wherein said user equipment history request comprises an indication of said at least one cell or said at least one beam and at least one other criteria; and said means for generating said user equipment history report is configured to generate a user equipment history report for user equipment that have visited said indicated at least one cell or at least one beam and meet said at least one other criteria.

12. An apparatus according to claim io or 11, wherein said user equipment history request comprises data indicating further information required in said user equipment history report, said means for generating said user equipment history report being configured to generate said user equipment history report to include said further information requested.

13. An apparatus according to any preceding claim, said apparatus comprising means for transmitting said received trajectory status request to at least one of said at least one user equipment visiting said cell associated with said apparatus.

14. An apparatus according to any preceding claim, wherein said means for receiving said trajectory status request is configured to receive said trajectory status request from at least one of: a user equipment when said user equipment reconnects to a network via a cell associated with said apparatus; a control network node as part of a user equipment context when said user equipment reconnects to a network via a cell associated with said apparatus; a network node, said trajectory status request being received in user equipment associated signalling; and an operations, administration and maintenance 0AM node.

15. An apparatus, comprising: means for generating a trajectory status request requesting information regarding visiting of at least one cell or at least one beam within a cell by a user equipment that has also visited a cell or beam within a cell associated with a network node identified in said trajectory status request; means for transmitting said trajectory status request towards a network node; means for receiving a trajectory status report from said network node, said trajectory status report comprising said information regarding visiting of said at least one cell or said at least one beam by said user equipment.

16. An apparatus according to claim 15, said apparatus further comprising: means for generating a user equipment history request, said user equipment history request identifying at least one cell or at least one beam, said user equipment history request requesting a user equipment history report for user equipment that have visited said at least one identified cell or beam; means for transmitting said user equipment history request towards a network node; means for receiving a user equipment history report; and means for collating user equipment trajectory information from said received trajectory status report and said received user equipment history report.

17. An apparatus according to any one of claims 15 or 16, comprising means for transmitting collated user equipment trajectory information to a further node.

18. An apparatus according to any one of claims 15 or 16, comprising means for generating or updating a trajectory prediction algorithm in dependence upon received trajectory information.

19. An apparatus according to any one of claim 15 to 18, said apparatus further comprising said apparatus according to any one of claims 1 to 14.

20. A network comprising at least one apparatus according to any one of claims 15 to 19, and a plurality of apparatus according to any one of claims 1 to 14.

21. An apparatus comprising means for receiving a trajectory status request, said trajectory status request requesting information regarding at least one cell at or at least one beam within a cell visited by said apparatus, said trajectory status request identifying a network node; and means for generating a mobility history indicative of cells visited by said apparatus, said means for generating said mobility history being configured to include said trajectory status request within said mobility history; means for determining cells that are camped on during a low power mode and for including said data in said mobility history; and means for storing said mobility history including said trajectory status request; means for transmitting said mobility history including said trajectory status request to a network node on reconnection to a network.

22. A method comprising: generating a trajectory status report in response to receipt of a trajectory status request at an apparatus, said trajectory status request identifying a network node and requesting information regarding visiting of at least one cell or at least one beam within a cell by at least one user equipment that has visited said network node identified in said trajectory status request, said trajectory status report comprising said information regarding visiting of said at least one cell or said at least one beam by said at least one user equipment, said at least one cell or the cell containing said at least one beam comprising a cell associated with said apparatus; and outputting said generated trajectory status report for transmission to said network node identified in said trajectory status request.

23. A method comprising: generating a trajectory status request requesting information regarding visiting of at least one cell or at least one beam within a cell by a user equipment that has also visited a cell or beam within a cell associated with a network node identified in said trajectory status request; outputting said trajectory status request for transmission towards a network node associated with said cell; and receiving a trajectory status report from said at least one network node, said trajectory status report comprising said information regarding visiting of said at least one cell or said at least one beam by said user equipment.

24. A method comprising; in response to receipt at an apparatus of a trajectory status request, said trajectory status request identifying a network node and requesting information regarding at least one cell at or at least one beam within a cell visited by said apparatus, generating a mobility history indicative of cells visited by said apparatus and including said trajectory status request within said mobility history and storing said mobility history; entering a low power mode; determining cells that are camped on during said low power mode and storing data indicative of said cells in said mobility history; on reconnection to a network and outputting said mobility history including said trajectory status request for transmission to a network node.

25. A computer program comprising computer readable instructions which when executed by a processor are operable to control said processor to perform a method according to any one of claims 22 to 24.