Patent Description:
Examples of mobile or wireless telecommunication systems may include <NUM> RAT, the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), LTE Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), LTE-A Pro, NR access technology, and/or MulteFire Alliance. <NUM> wireless systems refer to the next generation (NG) of radio systems and network architecture. A <NUM> system is typically built on a <NUM> NR, but a <NUM> (or NG) network may also be built on E-UTRA radio. It is expected that NR can support service categories such as enhanced mobile broadband (eMBB), ultra-reliable low-latency-communication (URLLC), and massive machine type communication (mMTC). NR is expected to deliver extreme broadband, ultra-robust, low latency connectivity, and massive networking to support the Internet of Things (IoT). The next generation radio access network (NG-RAN) represents the RAN for <NUM>, which may provide radio access for NR, LTE, and LTE-A. It is noted that the nodes in <NUM> providing radio access functionality to a user equipment (e.g., similar to the Node B in UTRAN or the Evolved Node B (eNB) in LTE) may be referred to as next-generation Node B (gNB) when built on NR radio, and may be referred to as next-generation eNB (NG-eNB) when built on E-UTRA radio.

Further prior art documents are <CIT> showing a system and method to facilitate radio access point load prediction in a network environment, <CIT> showing a rate adaptation during handoffs, <CIT> showing methods and apparatus for performing HO decisions in a mobile network and <CIT> showing a machine learning-based approach to network planning using observed patterns.

In accordance with some embodiments, there are provided methods, apparatuses, a non-transitory, computer-readable medium, and a computer program product according to the respective claims.

It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of PACHO procedures may train machine-learning models to learn user paths and optimal handover settings, such as cell individual offset (CIO) and time-to-trigger (TTT), for particular paths and related speeds. These optimal handover settings may then factor into evaluations of handover target candidate cells and handover points, using legacy handover processes and/or conditional handover procedures. In addition, PACHO procedures may learn optimal target cell and handover points when configured with high inference frequencies, along with higher signaling and/or computational loads. Learning optimal handover settings, such as CIO and TTT, allows PACHO to evaluate target candidates and handover points using legacy handover logic.

According to some embodiments, optimal triggers may be learned by the ML model post-processing historical reports during training. For example, the ML may be a neural network trained with model parameters offline, and configured with a set of hyper parameters based on data collected from multiple user paths. Such a trained model may then be compressed and transmitted to user devices to perform inferences. User devices may perform any number of inferences by supplying radio measurement and/or user location data to the model, with the model returning parameters, such as optimal CIO and TTT values, customized to the user and the path of the user. In this way, private user location data is not shared with the network when performing inferences.

<FIG> illustrates an example of a signaling diagram depicting path-aware cognitive handover optimization. UE <NUM> and NE <NUM> may be similar to UE <NUM> and NE <NUM>, as illustrated in <FIG>, according to certain embodiments.

At <NUM>, NE <NUM> configures one or more UE, including UE <NUM>, to log location-tagged handover data configured to train at least one ML model. In various embodiments, NE <NUM> may only configure a subset of the UE that NE <NUM> serves, and may randomly select the UE belonging to the subset in order to improve anonymization. In addition, UE <NUM> may opt-out of reporting, but by default, reporting may be enabled on capable devices.

At <NUM>, as shown in <FIG>, UE <NUM> logs, which may then be transmitted to NE <NUM> at <NUM>. UE may anonymize the location-tagged data. The anonymized, location-tagged data may be configured for ML training. In various embodiments, the anonymization may anonymize the identity of UE <NUM>, users of UE <NUM>, and any other data capable of tracking UE <NUM>. For example, in transmitting the data at <NUM>, UE <NUM> may transmit location-identified reports to NE <NUM> at a time that is randomly different from the time at which UE <NUM> compiled the report.

In various embodiments, UE <NUM> may transmit reports when UE <NUM> is not actively in use and/or with a delay between the recording of the report and its upload. For example, UE <NUM> may select a random time to transmit reports. This may further improve user privacy since out-of-date user location or path is not as sensitive information as up-to-date location/path data. Additionally, the anonymized data may be encrypted. Since the communication of reports is not time-sensitive, encryption and/or reporting may be performed in off-hours, when UE <NUM> and/or NE <NUM> is not heavily in use. Since reported paths and related location coordinates are not quantized, exact GPS values are used, leaving the selection of granularity to the ML model.

In various embodiments, reports may be used as input data for training ML models, which may include the time series of locations visited (GPS coordinates) before and after handover, and/or corresponding measured RSRP values of visible cells. The lengths of the time series both before and after the handover may be configured by NE <NUM>, and may be equal. As an example, the time series may be supplemented with the kind and times of HO events registered in relation to the specific handover. Such events may include any of handover initiation, handover failure, radio link failure, and/or ping pong. For each initiated handover, reports may include applied HO trigger conditions, such as A3, A4, etc., and/or applicable RSRP and SINR values at which the handover was initiated. In addition, for handover events, such as handover initiations, reports may include locations at which a HO event was registered, such as geographical coordinates captured, for example using GPS, and/or the speed (or approximation thereof) at which UE <NUM> was moving when the event happened.

At <NUM>, NE <NUM> labels data to train at least one ML model. For example, ML models may be trained by inputting sequences of location and/or reference signal received power (RSRP) measurements, such as in <FIG>. To achieve this, NE <NUM> may identify optimal handover points to minimize unwanted handover events (such as handover failures, radio link failures and/or ping pongs), and/or optimize a specific quality metric, such as service interruption percentage. In various embodiments, optimal handover optimization may account for the speed and direction of UE <NUM>. The sequence of GPS points taken at a fixed frequency may identify both the path on which UE <NUM> was moving and the speed with which it was moving. Thus, GPS coordinates may be collected at a fixed frequency.

In some embodiments, the frequency of measuring these values may be configured by NE <NUM> differently for different user locations. For example, near a highway where UE <NUM> is likely to move at high speed, a higher frequency may be configured to ensure a good characterization of the path. On the other hand, a city's business district may have many paths close to each other, so a high frequency may also be needed there to distinguish the different paths. Conversely, a mountain resort area where most users walk on foot and on a few paths may require only intermittent GPS records to adequately identify the paths and the proper settings on those paths.

In certain embodiments, RSRP measurement sequences for the serving & candidate target cells may be used to identify likely handover events (handover successes, handover failures, radio Link failures, and/or ping pongs) that may occur if different handover settings (e.g., different CIO and/or TTT values) are applied. Labeled data may apply a set of rules configured to evaluate the accuracy of each handover event, such as shown in <FIG>. For each setting applied to the path (and related RSRP sequences), resulting handover events may be graded to compute loss function, resulting in a hash function of {path + handover setting : resulting loss}.

While signal and position sequences may be used to generate proper labels for training, the availability of handover events may further improve the labelling. For example, some embodiments leading to specific handover events (e.g., a sharp blockage that causes handover failures) may be difficult to identify by reverse engineering the signal profiles. Thus, the handover event may be used to identify the point at which the event occurred to train the model to derive the settings that would avoid such an event.

At <NUM>, NE <NUM> trains at least one ML model based upon the labelled data, such as shown in <FIG>. For example, the at least one ML model may be trained as cell-specific, cell-boundary-specific, and/or cell-cluster-specific machine learning models, such as a neural network model. In various embodiments, RLF, HOF and/or successful HO reports may be extended to include the CIO and/or TTT parameter, which may improve the training and further fine-tune the model. However, with UE <NUM> selecting settings according to the path, UE <NUM> may inform NE <NUM> about the settings that were applied to trigger the handover.

In various embodiments, training may be performed in a supervised-learning-form using the sequences of RSRP values before and after the HO event. UE <NUM> may send the data to UE <NUM> which NE <NUM> may aggregate to perform batched learning. The model may then learns the profile of the RSRP values along each path across a given cell-pair boarder. Using the learned RSRP profiles, the solution may compute optimal TTT and CIO values for the different paths, which may then be forwarded to any other UEs to be used to trigger handovers along those paths. Training may also be performed actively, such as with reinforcement learning, based on the feedback of UE <NUM> concerning events observed by UE <NUM>. If an event occurs, UE <NUM> may report the event together with the path or location sequence and RSRP values at which the event occurred. NE <NUM> may then update the model for the specific path or location and/or compute new HO settings (TTT and CIO) for the path/location. These settings may then be transmitted to other UE along a similar path for its handover evaluation.

CNNs may use the layout of the data as additional information in their inference by learning filters that take into consideration neighbour relations between the input features. <NUM>-dimensional CNNs are powerful sequence processing tools which may learn to infer various things from input sequences, such as predicting the next few steps in the sequence, or predicting the optimal CIO and TTT values. In this use, the filters formed by the convolutional layer may consider each input feature's location in a single dimension, the time dimension. With this information, the filters may internally learn to deduce current and future user locations, speed, inertia, and possible paths the user will take, as well as the corresponding radio environment, all improving in the correct prediction of optimal handover parameters. One example topology of a CNN is illustrated in <FIG>.

If a neural network is used as the ML model, the model may be compressed by quantizing the weights. For example, the quantization process may occur after training, where the weights and activations (stored as floating points) of the net may be converted into a much simpler <NUM>-bit integer representation. Quantized neural networks may provide certain benefits. For example, memory requirements of quantized neural networks are significantly lower than their non-compressed counterparts. In the case of PACHO, transferring this model to UE <NUM> may also save network resources, as well as resources on UE <NUM> when running inference. In addition, inferences using these networks may require less computing power, and may be much quicker than their non-compressed counterparts. This aspect may be especially relevant on lower-end devices which may struggle to infer at the required rate if the model is complex. Just as importantly, fewer computational requirements use less energy.

At <NUM>, NE <NUM> transmits to UE <NUM> the at least one ML model, as shown in <FIG>. In various embodiments, in order to minimize the inference-related computation load in UE <NUM> and conserve network resources, rather than transferring the complete ML model, NE <NUM> may transfer a compressed version of the model to UE <NUM>. For example, the compression may be performed using quantization of neural network weights. Alternative compression mechanisms may also be used, such as hash functions.

In various embodiments, PACHO may separate ML model training from related inference calculations based on the trained model. The model may be trained in the network, e.g., in NE <NUM> and/or the OAM. When fully trained, the trained ML model is signaled to UE <NUM> for use in deciding the appropriate HO settings. To enable/ease inference in UE <NUM>, the ML model may be simple and small to minimize computational resources required by UE <NUM> to compute the inference from the model. Such a model may, for example, be a quantized neural network.

Furthermore, the trained model may be sent to UE <NUM> in the form of a set of parameters that may be used to infer the outcome for a given path and radio network characteristics. Such a model may be specific for each path, e.g. turning right at the junction or for each location, identified by e.g. a physical feature (like a train station, a park, etc.). Alternatively, it may be a general to a wider area (e.g., a radio cell), but with path and location information, (e.g., sequence of) GPS coordinates, as one of the inputs that are taken to compute the correct TTT and CIO values and from those the correct HO trigger point.

For inference, UE <NUM> applies its specific characteristics into the model to infer the point at which to trigger the handover (i.e., to infer TTT and/or CIO values). The inference is characterized by easing the computational cost UE <NUM> may initiate the computation only if certain events occur, e.g., only if the RSRP in the target cell becomes equal to that in the source cell, in which case UE <NUM> seek the point at which the target is better than the source to be the server. Additionally or alternatively, the input data during inference may include the user path and its derivatives, such as direction, speed, or acceleration. Optionally, the RSRP and SINR measurements as observed by UE <NUM> may also be included as inference input data. Furthermore, the output during inference may be a tuple of the CIO and TTT values that UE <NUM> should apply to evaluate whether and when to initiate a handover. Optionally, the model may also output the time that should elapse before the next inference/update is executed. UE <NUM> may log events related to the success of the parameters computed by the model. These may then be used to tune the model as needed. In case of active learning for example, UE <NUM> may report the event, path, and RSRP values with which NE <NUM> may update the model for the specific path, which may in future then be sent to another UE in along a similar path for its handover evaluation.

At <NUM>, UE <NUM> calculates optimal CIO and/or TTT values based upon the optimal handover points, which may indicate that handovers may occur at these optimal points when the calculated CIO and/or TTT values are applied, as shown in <FIG>. In various embodiments, the calculated optimal CIO and/or TTT values may be configured as labels for the user paths in the training data. For example, UE <NUM> may determine at least one possible path across handover boundaries and/or models of radio conditions and handover performance along these possible paths. Additionally or alternatively, NE <NUM> may determine optimal HO settings (i.e. the optimal TTT and CIO values) for each path along the handover boundary and for the particular UE mobility profile. In this way, user privacy may be protected, and the risk of tracking the user may be minimized. Since the ML model is received from NE <NUM>, UE <NUM> performs inference, as opposed to UE <NUM> sending its locations and/or paths to NE <NUM> for NE <NUM> to infer the optimal handover settings. For inference, UE <NUM> inputs its path, such as a sequence of GPS coordinates, and/or other radio measurements; thereafter, UE <NUM> may use the received ML models to compute appropriate CIO and/or TTT values that UE <NUM> should apply for handover procedures. In various embodiments, where UE <NUM> has received a neural network, UE <NUM> may feed the model with its own path, generating optimized path and/or mobility-profile-specific handover parameters. UE <NUM> may then perform at least one handover procedure, such as CHO. In various embodiments, where UE <NUM> has received a compression of the neural network, UE <NUM> may match its path with at least one applicable identifier of paths with the model compression. Then, when matched, UE <NUM> may apply the parameters corresponding to that path identifier. UE <NUM> may then perform at least one handover procedure, such as CHO.

<FIG> illustrates an example of a flow diagram of a method that may be performed by a UE, such as UE <NUM> illustrated in <FIG>, according to various embodiments. At <NUM>, the UE receives, from a NE similar to NE <NUM> in <FIG>, at least one instruction to log location-tagged handover data configured to train at least one ML model. In various embodiments, the NE may only configure a subset of the UE that the RAN serves, and may randomly select the UE belonging to the subset in order to improve anonymization.

In addition, the UE may opt-out of reporting, but by default, reporting may be enabled on capable devices.

At <NUM>, as shown in <FIG>, the UE logs location-tagged data, which may then be transmitted to the NE at <NUM>. The UE may anonymize the location-tagged data. The anonymized, location-tagged data may be configured for ML training. In various embodiments, the anonymization may anonymize the identity of the UE, users of the UE, and any other data capable of tracking the UE. For example, in transmitting the data at <NUM>, the UE may transmit location-identified reports to the NE at a time that is randomly different from the time at which the UE compiled the report.

In various embodiments, the UE may transmit reports when the UE is not actively in use and/or with a delay between the recording of the report and its upload. For example, the UE may select a random time to transmit reports. This may further improve user privacy since out-of-date user location or path is not as sensitive information as up-to-date location/path data. Additionally, the anonymized data may be encrypted. Since the communication of reports is not time-sensitive, encryption and/or reporting may be performed in off-hours, when the UE and/or the NE is not heavily in use. Since reported paths and related location coordinates are not quantized, exact GPS values are used, leaving the selection of granularity to the ML model.

In various embodiments, reports may be used as input data for training ML models, which may include the time series of locations visited (GPS coordinates) before and after handover, and/or corresponding measured RSRP values of visible cells. The lengths of the time series both before and after the handover may be configured by the NE, and may be equal. As an example, the time series may be supplemented with the kind and times of HO events registered in relation to the specific handover. Such events may include any of handover initiation, handover failure, radio link failure, and/or ping pong. For each initiated handover, reports may include applied HO trigger conditions, such as A3, A4, etc., and/or applicable RSRP and SINR values at which the handover was initiated. In addition, for handover events, such as handover initiations, reports may include locations at which a HO event was registered, such as geographical coordinates captured, for example using GPS, and/or the speed (or approximation thereof) at which the UE was moving when the event happened.

At <NUM>, the UE receives at least one ML model, as shown in <FIG>. In various embodiments, in order to minimize the inference-related computation load in the UE and conserve network resources, rather than transferring the complete ML model, the NE may transfer a compressed version of the model to the UE. For example, the compression may be performed using quantization of neural network weights. Alternative compression mechanisms may also be used, such as hash functions.

In various embodiments, PACHO may separate ML model training from related inference calculations based on the trained model. The model may be trained in the network, e.g., in NE <NUM> and/or the OAM. When fully trained, the trained ML model is signaled to the UE for use in deciding the appropriate HO settings. To enable/ease inference in the UE, the ML model may be simple and small to minimize computational resources required by the UE to compute the inference from the model. Such a model may, for example, be a quantized neural network.

Furthermore, the trained model may be sent to the UE in the form of a set of parameters that may be used to infer the outcome for a given path and radio network characteristics. Such a model may be specific for each path, e.g. turning right at the junction or for each location, identified by e.g. a physical feature (like a train station, a park, etc.). Alternatively, it may be a general to a wider area (e.g., a radio cell), but with path and location information, (e.g., sequence of) GPS coordinates, as one of the inputs that are taken to compute the correct TTT and CIO values and from those the correct HO trigger point.

For inference, the UE may apply its specific characteristics into the model to infer the point at which to trigger the handover (i.e., to infer TTT and/or CIO values). The inference is characterized by easing the computational cost the UE may initiate the computation only if certain events occur, e.g., only if the RSRP in the target cell becomes equal to that in the source cell, in which case the UE seek the point at which the target is better than the source to be the server. Additionally or alternatively, the input data during inference may include the user path and its derivatives, such as direction, speed, or acceleration. Optionally, the RSRP and SINR measurements as observed by the UE may also be included as inference input data. Furthermore, the output during inference may be a tuple of the CIO and TTT values that the UE should apply to evaluate whether and when to initiate a handover. Optionally, the model may also output the time that should elapse before the next inference/update is executed. The UE may log events related to the success of the parameters computed by the model. These may then be used to tune the model as needed. In case of active learning for example, the UE may report the event, path, and RSRP values with which the NE may update the model for the specific path, which may in future then be sent to another UE in along a similar path for its handover evaluation.

At <NUM>, the UE calculates optimal CIO and/or TTT values based upon the optimal handover points, which may indicate that handovers may occur at these optimal points when the calculated CIO and/or TTT values are applied, as shown in <FIG>. In various embodiments, the calculated optimal CIO and/or TTT values may be configured as labels for the user paths in the training data. For example, the UE may determine at least one possible path across handover boundaries and/or models of radio conditions and handover performance along these possible paths. Additionally or alternatively, the NE may determine optimal HO settings (i.e. the optimal TTT and CIO values) for each path along the handover boundary and for the particular UE mobility profile. In this way, user privacy may be protected, and the risk of tracking the user may be minimized. Since the ML model is received from the NE, the UE performs inference, as opposed to the UE sending its locations and/or paths to the NE for the NE to infer the optimal handover settings. For inference, the UE inputs its path, such as a sequence of GPS coordinates, and/or other radio measurements; thereafter, the UE may use the received ML models to compute appropriate CIO and/or TTT values that the UE should apply for handover procedures. In various embodiments, where the UE has received a neural network, the UE may feed the model with its own path, generating optimized path and/or mobility-profile-specific handover parameters. The UE may then perform at least one handover procedure, such as CHO. In various embodiments, where the UE has received a compression of the neural network, the UE may match its path with at least one applicable identifier of paths with the model compression. Then, when matched, the UE may apply the parameters corresponding to that path identifier. The UE may then perform at least one handover procedure, such as CHO.

<FIG> illustrates an example of a flow diagram of a method that may be performed by a NE, such as NE <NUM> illustrated in <FIG>, according to various embodiments. At <NUM>, the NE configures one or more UE to log location-tagged handover data configured to train at least one ML model. In various embodiments, the NE may only configure a subset of the UE that the NE serves, and may randomly select the UE belonging to the subset in order to improve anonymization. In addition, the UE may opt-out of reporting, but by default, reporting may be enabled on capable devices.

At <NUM>, the NE receives location-identified reports from the UE at a time that is randomly different from the time at which UE <NUM> compiled the report.

In various embodiments, the NE may receive reports when the UE is not actively in use and/or with a delay between the recording of the report and its upload. For example, the UE may select a random time to transmit reports. This may further improve user privacy since out-of-date user location or path is not as sensitive information as up-to-date location/path data. Additionally, the anonymized data may be encrypted. Since the communication of reports is not time-sensitive, encryption and/or reporting may be performed in off-hours, when the UE and/or the NE is not heavily in use. Since reported paths and related location coordinates are not quantized, exact GPS values are used, leaving the selection of granularity to the ML model.

At <NUM>, the NE labels data to train at least one ML model. For example, ML models may be trained by inputting sequences of location and/or reference signal received power (RSRP) measurements, such as in <FIG>. To achieve this, the NE may identify optimal handover points to minimize unwanted handover events (such as handover failures, radio link failures and/or ping pongs), and/or optimize a specific quality metric, such as service interruption percentage. In various embodiments, optimal handover optimization may account for the speed and direction of the UE. The sequence of GPS points taken at a fixed frequency may identify both the path on which the UE was moving and the speed with which it was moving. Thus, GPS coordinates may be collected at a fixed frequency.

In some embodiments, the frequency of measuring these values may be configured by the NE differently for different user locations. For example, near a highway where the UE is likely to move at high speed, a higher frequency may be configured to ensure a good characterization of the path. On the other hand, a city's business district may have many paths close to each other, so a high frequency may also be needed there to distinguish the different paths. Conversely, a mountain resort area where most users walk on foot and on a few paths may require only intermittent GPS records to adequately identify the paths and the proper settings on those paths.

At <NUM>, the NE trains at least one ML model based upon the labelled data, such as shown in <FIG>. For example, the at least one ML model may be trained as cell-specific, cell-boundary-specific, and/or cell-cluster-specific machine learning models, such as a neural network model. In various embodiments, RLF, HOF and/or successful HO reports may be extended to include the CIO and/or TTT parameter, which may improve the training and further fine-tune the model. However, with the UE selecting settings according to the path, the UE may inform the NE about the settings that were applied to trigger the handover.

In various embodiments, training may be performed in a supervised-learning-form using the sequences of RSRP values before and after the HO event. The NE may receive the data from the UE which the NE may aggregate to perform batched learning. The model may then learns the profile of the RSRP values along each path across a given cell-pair boarder. Using the learned RSRP profiles, the solution may compute optimal TTT and CIO values for the different paths, which may then be forwarded to any other UEs to be which may struggle to infer at the required rate if the model is complex. Just as importantly, fewer computational requirements use less energy.

At <NUM>, the NE transmits to the UE the at least one ML model, as shown in <FIG>. In various embodiments, in order to minimize the inference-related computation load in UE <NUM> and conserve network resources, rather than transferring the complete ML model, the NE may transfer a compressed version of the model to the UE. For example, the compression may be performed using quantization of neural network weights. Alternative compression mechanisms may also be used, such as hash functions.

In various embodiments, PACHO may separate ML model training from related inference calculations based on the trained model. The model may be trained in the network, e.g., in the NE and/or the OAM. When fully trained, the trained ML model is signaled to the UE for use in deciding the appropriate HO settings. To enable/ease inference in the UE, the ML model may be simple and small to minimize computational resources required by the UE to compute the inference from the model. Such a model may, for example, be a quantized neural network.

For inference, the UE may apply its specific characteristics into the model to infer the point at which to trigger the handover (i.e., to infer TTT and/or CIO values). The inference is characterized by easing the computational cost UE <NUM> may initiate the computation only if certain events occur, e.g., only if the RSRP in the target cell becomes equal to that NE <NUM> and/or UE <NUM> may include at least one processor, respectively indicated as <NUM> and <NUM>. Processors <NUM> and <NUM> may be embodied by any computational or data processing device, such as a central processing unit (CPU), application specific integrated circuit (ASIC), or comparable device. The processors may be implemented as a single controller, or a plurality of controllers or processors.

At least one memory may be provided in one or more of the devices, as indicated at <NUM> and <NUM>. The memory may be fixed or removable. The memory may include computer program instructions or computer code contained therein. Memories <NUM> and <NUM> may independently be any suitable storage device, such as a non-transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory may be used. The memories may be combined on a single integrated circuit as the processor, or may be separate from the one or more processors. Furthermore, the computer program instructions stored in the memory, and which may be processed by the processors, may be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language.

Processors <NUM> and <NUM>, memories <NUM> and <NUM>, and any subset thereof, are configured to provide means corresponding to the various blocks of <FIG>. Although not shown, the devices may also include positioning hardware, such as GPS or micro electrical mechanical system (MEMS) hardware, which may be used to determine a location of the device. Other sensors are also permitted, and may be configured to determine location, elevation, velocity, orientation, and so forth, such as barometers, compasses, and the like.

As shown in <FIG>, transceivers <NUM> and <NUM> may be provided, and one or more devices may also include at least one antenna, respectively illustrated as <NUM> and <NUM>. The device may have many antennas, such as an array of antennas configured for multiple input multiple output (MIMO) communications, or multiple antennas for multiple RATs. packets, user plane quality of service (QoS) processing, buffering of downlink packets, and/or triggering of downlink data notifications. The application function (AF) may primarily interface with the core network to facilitate application usage of traffic routing and interact with the policy framework.

Claim 1:
A method, comprising:
transmitting (<NUM>, <NUM>), by a network element, at least one instruction to at least one user equipment to log location-tagged handover data, wherein the location-tagged handover data comprise one or more of at least one path, at least one observed reference signal received power associated with at least one cell, and at least one global positioning system coordinate;
receiving (<NUM>, <NUM>), by the network element from the at least one user equipment, the location-tagged handover data;
labelling (<NUM>, <NUM>) the received location-tagged handover data by computing, by the network element, at least one loss function based upon at least one handover event evaluation rule of the received location-tagged handover data, thus generating labelled data; and
training (<NUM>, <NUM>), by the network element, at least one handover optimization model with the location-tagged handover data,
wherein the handover optimization model is a machine learning model;
transmitting (<NUM>, <NUM>), to the at least one user equipment, the trained machine learning model.