System, method and apparatus for mobility management in mobile networks

Abstract

A wireless communication system 100 comprises a first network entity 101, e.g. a 5G / 6G gNB, comprising a transceiver and signal processor 108 and configured to support a plurality of wireless communic

Description

Technical Field The technical field relates generally to a system, methods and apparatus to mobility information to different entities and functions in mobile network. In particular, example implementations include a system, methods and apparatus to optimize or improve mobility management in mobile networks using radio access network (RAN) data latent space-based data collections. Background In recent years, there has been a rapid development in communications technologies that are compliant with third generation partnership project (3GPP™) standards. A 4th generation (4G) wireless communication standard (sometimes referred to as long term evolution (LTE) was designed to support mobile internet and higher speeds for activities, such as video streaming and gaming. The 3GPP™ standards then developed a fifth generation (5G) of mobile wireless communications, which provides a step change in the delivery of better and faster communications, for example powering businesses, improving communications within homes and spearheading advances such as driverless cars. These 5G networks have also brought about a wide range of new services, each with its own unique set of requirements categorized under three main categories: Ultra-Reliable Low-Latency Communication (URLLC), massive Machine-Type Communication (mMTC), and Enhanced Mobile Broadband (eMBB). However, as the industry looks toward the future, it is clear that 5G networks are just the beginning. A sixth generation (6G) wireless communication standard is currently under development, as the planned successor to 5G, and will likely be significantly faster. Like its predecessors, 6G networks will likely be broadband cellular networks, in which the service area is divided into small geographical areas called cells. 6G networks are expected to be even more diverse than their predecessors and are likely to support applications beyond current mobile use scenarios, such as virtual and augmented reality (VR / AR), ubiquitous instant communications, pervasive intelligence and the Internet of Things (loT). It is expected that mobile network operators will adopt flexible decentralized business models for 6G, with local spectrum licensing, spectrum sharing, infrastructure sharing, and intelligent automated management underpinned by mobile edge computing, artificial intelligence (AI), short-packet communication and blockchain technologies. To meet these demands, network densification and millimeter wave (mmw) communications have been proposed as two key technological enablers [1], Densifying the network with small cells like Pico and Femto cells allows for more efficient use of available resources and enables better coverage and capacity. Meanwhile, mmw communications can enhance the capacity of cellular networks by exploiting the abundant bandwidth available in the mmw frequency spectrum. However, while these technologies offer significant benefits in terms of capacity and coverage, they also create new challenges for mobility management. Densifying the network and deploying small cells with very low signal coverage results in an increasing number of handovers between frequencies, cells, and base stations. This can negatively impact the overall user experience, causing unwanted service interruptions during handovers and degrading the Quality of Service (QoS). To address this problem, the research community has been focused on devising novel techniques to prevent and minimize unwanted handover scenarios. Handover is a critical component of mobility management in mobile networks, and the accuracy of handover prediction and execution has a significant impact on the overall user experience. Inaccurate handover prediction can lead to dropped calls, poor voice quality, and slow data transfer rates, resulting in dissatisfied users and a negative impact on the operator's reputation. Traditional handover prediction techniques rely on the collection and transmission of data (Reference Signal Received Power (RSRP), radio signal strength (RSS), radio signal strength indicator (RSSI), Reference Signals Received Quality (RSRQ), etc.). Moreover, the large amount of data generated by modern mobile networks can result in high transmission costs and storage requirements. These challenges are particularly relevant in 5G and beyond networks, which are expected to generate an unprecedented amount of data. Thus, traditionally, handover management has been performed using predefined rules that determine when and how a handover should occur. However, these rules may not always result in the best handover decision, especially under dynamic network conditions or when a mobile device is moving at high speeds. As a result, there has been a growing interest in developing data-driven handover solutions that use machine learning techniques to predict and optimize handover decisions. Data-driven models that predict user behaviour and mobility patterns based on data collected from both end-users and the network itself have become the foundation for many solutions [2], 3GPP™ supports the collection of UE specific radio measurements using minimisation of drive test (MDT) [3], There are two modes of MDT measurements: Immediate MDT and Logged MDT Immediate MDT procedure is used to report RRCCONNECTED state measurements. The user equipment (UE) sends measurement reports to the network at a pre-determined reporting interval or when certain events occur. The reports include information about radio conditions, such as signal strength, signal quality, and interference levels. The reporting interval and the type of events that trigger a report can be configured by the network operator. Logged MDT measurements are taken over a period of time and stored in a buffer on the UE. The buffer can hold a certain amount of data, which is determined by the MDT buffer size limit. Once the buffer is full, the measurements are uploaded to the network, typically upon gNB request after entering RRC CONNECTED state. The reported latency is longer than Immediate MDT since the measurements are not reported immediately but rather stored in the buffer and uploaded later. The inventors have recognised and appreciated that one of the key challenges in developing data-driven handover solutions is the need for large amounts of data to train and validate the machine learning models. Data compression and latent space representation have become increasingly important in various fields, including telecommunications, computer vision, and natural language processing. In the field of telecommunications, data compression techniques are used to reduce the amount of data that needs to be transmitted over the network, thereby reducing network traffic and improving the overall efficiency of the network. 18 07 25 Summary In a first aspect, a wireless communication system is described that comprises: a first network entity comprising a transceiver operably coupled to a signal processor and configured to support 5 wireless communication for a plurality of wireless communication units; and a radio access network, RAN, device operably coupled to the first network entity that is configured to collect RAN mobility data of the plurality of wireless communication units and provide the RAN mobility data to the RAN device; wherein the RAN device comprises or is operably coupled to a latent space representation circuit configured to generate and transmit compressed, low- 10 dimensional latent space-based representation of the RAN mobility data; and a RAN data analytics device operably coupled to the RAN device and comprising a database that is configured to receive and the store a received compressed, low-dimensional latent space-based representation of the RAN mobility data, wherein the RAN data analytics device comprises or is operably coupled to a RAN data generation circuit that is configured to generate additional RAN 15 data samples using the stored compressed, low-dimensional latent space-based representation of the RAN mobility data obtained from the database. In a second aspect, a radio access network, RAN, data analytics device located in a Core Network, CN, is described that comprises: a receiver configured to receive, from a RAN device, compressed, low-dimensional latent space-based representation of RAN mobility data generated 20 from collected RAN mobility data of a plurality of wireless communication units; and a database configured to receive and store the received compressed, low-dimensional latent space-based representation of the RAN mobility data and configured to be accessible by at least one of: a plurality of RAN entities, at least one other CN entity, wherein the RAN data analytics device comprises a RAN data generation circuit that is configured to generate additional RAN data 25 samples using the stored compressed, low-dimensional latent space-based representation of the RAN mobility data obtained from the database. In a third aspect, a method for a radio access network, RAN, data analytics device located in a Core Network, CN, is described, wherein the method comprises: receiving, from a RAN device, compressed, low-dimensional latent space-based representation of RAN mobility data generated 30 from collected RAN mobility data of a plurality of wireless communication units; storing the received compressed, low-dimensional latent space-based representation of the RAN mobility data in a database; and allowing access to the compressed, low-dimensional latent space-based representation of the RAN mobility data in the database by at least one of: a plurality of RAN entities, at least one other CN entity; and generating, by a RAN data generation circuit, 5 additional RAN data samples using the stored compressed, low-dimensional latent space-based representation of the RAN mobility data obtained from the database. 18 07 25 In an optional example, the RAN device may be a radio access network, RAN, data collector, RDC, device. In an optional example, the RAN data analytics device may be a RAN data analytics network function, RDANF. 5 In an optional example, the network entity the RAN data analytics device may be located in the RAN or a core network, CN, in the wireless communication system. In an optional example, the RAN data generation circuit may be configured to generate additional RAN data samples for a specific user equipment, UE, or group of UEs, based on a set of desired features or conditions of the generated additional RAN data samples. 10 18 07 25 In an optional example, the set of desired features or conditions of the generated additional RAN data samples may comprise at least one of: a desired Reference Signal Received Power, RSRP, a desired radio signal strength, RSS, a desired radio signal strength indicator, RSSI, a desired Reference Signals Received Quality, RSRQ, global positioning system, GPS, coordinates for a specific UE; and the RAN data generation circuit is configured to generate data samples that match the additional RAN data samples. In an optional example, the generated additional RAN data stored in the database may be accessed by a RAN device in performance of at least one of: training a machine learning processor with RAN data; inference of RAN data; a comparison with monitored RAN data, a Life-Cycle-Management, LCM, model. In an optional example, the RAN data generation circuit may be configured to generate additional RAN data samples in advance of a potential handover of an user equipment, UE. In an optional example, the database may be configured to be accessible to at least one of: a plurality of RAN entities, at least one CN entity. In an optional example, the RAN data analytics device may comprise or may be operably coupled to a mobility management prediction circuit operably coupled to the database and configured to train the mobility management prediction circuit using the additional RAN data samples. In an optional example, the first network entity may be configured to initiate a subscription procedure with the RAN device that is responsible to generate the compressed, low-dimensional latent space-based representation of the RAN mobility data prior to obtaining RAN mobility data for a user equipment, UE, or group of UEs. In an optional example, the RAN mobility data may comprise one or more of the following information details / elements: a specific set of user equipment, UE, unique identifiers, IDs; a priority level of requested data; a RAN mobility data collection session ID; a unique identifier of the first network entity; one or more data fields; a TimeStamp for requested RAN mobility data; authentication and authorization information; network topology information; Quality of Service requirement; at least one RAN mobility data privacy and security policy; a RAN mobility data collection purpose; a RAN mobility data validity indication; an indication of a granularity of the RAN mobility data; and an expected data size. In this manner, a number of limitations with the current approaches when using MDT procedures to obtain UE information in general, and for handover purposes in particular, may be alleviated. Brief Description of the Drawings Further details, aspects and embodiments will be described, by way of example only, with reference to the drawings. In the drawings, similar reference numbers are used to identify like or functionally similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. FIG. 1 illustrates a block diagram of an 5G / 6G network entity (e.g., in a form of a gNB) communicating with a RAN data collection device (RDC), adapted in accordance with some example embodiments. FIG. 2 illustrates an example of a simplified message sequence chart of a purposed data exchange procedure, termed RANCollectionWriting, between a given UE (or a group of UEs), source NG-RAN and / or RDC, in accordance with some example embodiments. FIG. 3 illustrates an example of a simplified message sequence chart of a RANLatentWritingRequest message exchange, in accordance with some example embodiments. FIG. 4 illustrates an example of a simplified message sequence chart of a RAN Data transmission message exchange, in accordance with some example embodiments. FIG. 5 illustrates an example of a simplified message sequence chart for a procedure for information exchange of HO use case, in accordance with some example embodiments. FIG. 6 illustrates an example of a neural network that may be employed as an artificial intelligence-based learning processor architecture for improved handover optimization, according to some example embodiments. Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and / or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various example embodiments. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments. It will be further appreciated that certain actions and / or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein. Detailed Description Examples herein described propose a new interface and procedure for the collection, processing and exchange of latent space representation for radio access network (RAN) data from the RAN to either the core network (CN) or another RAN entity. In the context of the RAN, the inventors have recognised and appreciated that data compression and latent space representation may be used to improve the efficiency and performance of the network. Obtaining latent space representations are useful in that they can be utilized for generating synthetic data, which in some examples may be employed, say in other network domains, to produce realistic data for training purposes. By obtaining the latent space representation of the data, it is possible to improve the efficiency and performance of the network, as sending raw measurements will incur too much transmission and storage overhead. Also, by compressing data before it is transmitted over the network, it becomes possible to reduce the amount of bandwidth required, which can be particularly useful in situations where network resources are limited. Similarly, by representing the data in a lower-dimensional space, it may be possible to extract useful features that can be used to improve handover management, reduce latency, or optimize network resources. Furthermore, traditional handover management algorithms operate on raw network data, which can be highly complex and difficult to interpret. Latent space representation, on the other hand, involves mapping the raw network data into a lower-dimensional space that captures the underlying features and patterns of the data. This approach has been shown to improve the accuracy and efficiency of handover management. In particular, examples described herein propose gathering RAN samples, storing them in an efficient manner on an accessible entity for distinct NF / logical Functions / ML solutions to use them. Examples herein described utilise a combination of the following features: data collection, latent space representation, latent space transmission and data generation. Data Collection: The RAN collects measurements data (e.g. raw data) related to the network conditions, for example, radio measurements including but not limited to, Radio Signal Strength (RSS), Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), Signal to Interference plus Noise Ratio (SINR), UE context information, etc., from at least one network entity (e.g., base station (BS), NG-RAN, gNB, gNB, other naming), RUs, DUs, etc., using a new (or existing) network function (NF) that is referred to as RAN data collector (RDC). In one example, the new NF may be part of (or co-located with) a new (or existing) network entity (or a set of network entities). Latent space representation: The RDC maps the obtained compressed data to a latent space representation, which is a lower-dimensional representation, of the original data, that captures the data’s essential features. The compressed data is then ready to be provided / delivered to the CN and / or shared amongst CUs. A definition of ‘latent space’ is an abstract multi-dimensional space that encodes a meaningful representation of observed events. Thus, samples that are similar may be positioned close to each other in the latent space. In the context herein described, latent space encompasses a way of obtaining a low dimensionality version of samples, for example which could be a probability density function (PDF), and then generating new samples using that pdf. Latent Space Transmission: The RAN provides / delivers the latent space representation to the CN through the newly defined interface or procedure for the purpose of exchanging latent space representations between the RAN and CN. Latent Space Storage: The CN is in charge of storing historical latent-space data using a new (or existing) NF(s), which hereinafter is referred to as RAN data analytics network function (RDANF). Enabling efficient collection and storage of RAN. In one example, the new NF may be part of (or co-located with) a new (or existing) network entity (or a set of network entities). Data generation: Once the latent space representation is received, the RDANF can use it to generate new data samples, for a specific UE (or group of UEs), by inserting a set of desired features or conditions that the generated data samples should meet (include / contain). For example, the NF can input the desired RS SI, RSRP, and global positioning system (GPS) coordinates for a specific UE and the generative model can generate new data samples that match these conditions / parameters. This approach can be useful for various types of applications, such as data augmentation for machine learning models, synthetic data generation for testing and validation, and enhancing the accuracy of mobility prediction models by generating additional training data using a RAN data generation circuit. Using the above combination of concepts, examples herein described propose a novel approach for leveraging latent representations of RAN data to assist mobility management operations in wireless networks. The improved mobility management can be achieved by supporting AI / ML model training at the RAN and / or CN by providing a means to generate data related to / suitable for a specific UE (or a group of UEs) model, UE functionality, scenario, UE configuration and / or condition, a use case and / or application of the UE. The improved mobility management can be achieved by complementing RAN mobility data with the mobility data available at the CN, for example, but not limited to, information related to the UE location, UE mobility (e.g., trajectory, velocity, etc.), UE handover process, call drop statistics, etc. The improved mobility management can be achieved by providing mobility management artificial intelligence (AI) / machine learning (ML) models (e.g., as described with respect to FIG. 6) at the RAN and / or CN with sufficient amounts of data, even for newly arrived UEs. In other words, new models can obtain sufficient data for proper training or monitoring and / or other AI / ML operations or life-cycle management (LCM) purposes, or inference based on stored historical latent-space data, for example leveraging stored latent-space data to generate enough data samples to train them. Historical latent-representation data can be used by a NF at the CN or RAN to generate synthetic RAN measurements for AI / ML-based analytics solutions, for example, these involved in mobility management. This approach leverages the latest advancements in ML in order to provide more accurate and reliable data for AI / ML-based mobility management solutions. This can lead to more accurate and reliable predictions of UE mobility and, for example, help simplify the handover process, reducing overhead and interruption time whilst improving QoS. In addition, in some examples, models for inference that require historical backlog data may require a UE to be ON for a period of time, e.g., 1 min. With this approach, in some examples, synthetic data may be generated and used, thereby removing a need for a cold start of the ML model. Furthermore, stored historical latent-space data may be used for other applications, for example monitoring and / or other AI / ML operations or Life-Cycle-Management (LCM) purposes, for example as enough samples of freshly obtained data can be used to detect a data distribution shift. Thus, in some examples, the generated additional RAN data stored in a database may be accessed by a RAN device in performance of at least one of: training a machine learning processor 699 with RAN data; inference of RAN data; a comparison with monitored RAN data, a Life-Cycle-Management, LCM, model purposes, such as activation, deactivation, fallback, switching, selection of model, etc. Examples herein described provide a novel method and apparatus for enhancing AI / ML-assisted mobility management in mobile networks through latent space-based RAN data collection, storage, and transmission. The proposed system comprises a Radio Access Network (RAN) and a Core Network (CN) that communicate through a new interface or procedure designed to exchange latent space representations. Specifically, the RAN includes a sophisticated RAN data collection device that collects raw RAN data, as well as a latent space representation circuit that converts the raw data into a compact and meaningful latent space representation, i.e., to be able to generate samples that follow a similar distribution, so that the properties of the original samples are kept in the generated samples. Meanwhile, the CN comprises a database / storage device(s) that maintain(s) a comprehensive record of historical RAN samples and a RAN data generation circuit that leverages the latent space-based representation to re-construct or generate additional RAN data. The CN also holds some mobility management data, such as UE trajectory, that are specific to the CN and cannot be accessed in the RAN. Hence, in some examples, the purpose here is not only to use RAN data, but to also complement data available in the CN. This additional RAN data can be combined with the available mobility data in the CN and used as input to the AI / ML or RAN Data Analytics Function (or RAN Data Analytics device or circuit) to significantly enhance the accuracy and efficiency of machine learning models, e.g., the analytics circuits or functions performing mobility management predictions. Although examples are described herein with regard to an RDC and an RDANF, for example for a 3 GPP™ implementation, it is envisaged that the concepts herein described are equally applicable to a RAN device (not necessarily a RDC) and / or a RAN data analytics device (not necessarily a RDANF). FIG. 1 illustrates a block diagram of a communication system 100 that comprises an 5G / 6G network entity (in this example illustrated as a 5G / 6G gNB) 101 communicating with a RAN data collection (RDC) device 151, adapted in accordance with some example embodiments. The 5G / 6G network entity 101 contains an antenna 102, for receiving transmissions, coupled to an antenna switch and / or duplexer 104 that provides isolation between receive and transmit chains within the 5G / 6G network entity 101. One or more receiver chains, as known in the art, include receiver front-end circuitry 106 (effectively providing reception, filtering and intermediate or base-band frequency conversion). The receiver front-end circuitry 106 is coupled to a signal processor 108 (generally realized by a digital signal processor (DSP)). A skilled artisan will appreciate that the level of integration of receiver circuits or components may be, in some instances, implementation-dependent. The controller 114 maintains overall operational control of the 5G / 6G network entity 101. The controller 114 is also coupled to the receiver front-end circuitry 106 and the signal processor 108. In some examples, the controller 114 is also coupled to a frequency generation circuit 117 and a memory device 116 that selectively stores operating regimes, such as decoding / encoding functions, synchronization patterns, code sequences, and the like. A timer 118 is operably coupled to the controller 114 to control the timing of operations (e.g., transmission or reception of time-dependent signals) within the 5G / 6G network entity 101. As regards the transmit chain, this essentially includes an input circuit 120, coupled in series through transmitter / modulation circuitry 122 and a power amplifier 124 to the antenna 102, antenna array, or plurality of antennas. The transmitter / modulation circuitry 122 and the power amplifier 124 are operationally responsive to the controller 114. The signal processor 108 in the transmit chain may be implemented as distinct from the signal processor in the receive chain. Alternatively, a single processor may be used to implement a processing of both transmit and receive signals, as shown in FIG. 1. Clearly, the various components within the 5G / 6G network entity 101 can be realized in discrete or integrated component form, with an ultimate structure therefore being an application-specific or design selection. The processor 108 and transceiver (e.g., transmitter / modulation circuitry 122 and receiver frontend circuitry 106) of the 5G / 6G network entity 101 are configured to facilitate transfer of mobility data to a RDC device 151. Examples of some communications are illustrated in accordance with the approach described in one of FIG. 2, FIG. 4, and FIG. 5. FIG. 1 also shows a high-level block diagram of a RDC device 151. In this example, the RDC device 151 is illustrated as a wireless device with either a wireless connection 153 to the 5G / 6G network entity 101 or a wired connection 155 to the 5G / 6G network entity 101. In other examples, it is envisaged that the RDC device 151 may be a fixed (non-wireless) non-wireless RAN data collection device. In this example, the RDC device 151 contains an antenna 152, for receiving RAN data transmissions from the 5G / 6G network entity 101. The antenna 152 is coupled to one or more receiver chains, as known in the art, include receiver front-end circuitry 156 (effectively providing reception, filtering and intermediate or base-band frequency conversion). The receiver front-end circuitry 156 is coupled to a signal processor 158 (generally realized by a digital signal processor (DSP)). A skilled artisan will appreciate that the level of integration of receiver circuits or components may be, in some instances, implementationdependent. The controller 164 maintains overall operational control of the RDC device 151. The controller 164 is also coupled to the receiver front-end circuitry 156 and the signal processor 158. In some examples, the controller 164 is also coupled to a frequency generation circuit 167 and a memory device 166 that selectively stores operating regimes, such as decoding / encoding functions, synchronization patterns, code sequences, and the like. A timer 168 is operably coupled to the controller 164 to control the timing of operations (e.g., reception of time-dependent signals) within the RDC device 151. In accordance with examples herein described, once the collected RAN data is received by the RDC 151 and processed, this data is passed through a latent space representation circuit 159 (shown here as being located within the RDC 151 but can be implemented at other locations within the RAN in other envisaged examples). In this example, latent space representation circuit 159 generates a compressed, low-dimensional latent space-based representation of the RAN data. A latent space representation refers to a lower-dimensional representation of a dataset that captures its most important features or patterns. For example, this representation can be obtained using deep neural nets (variational auto-encoders, transformers, etc), or using manifold approximation techniques among other solutions. The signal processor 158 and / or latent space representation circuit 159 can be realized in discrete or integrated component form, with an ultimate structure therefore being an application-specific or design selection. Once the compressed, low-dimensional latent space-based representation of the RAN data is obtained, this information has to be transmitted to an entity (e.g., network function (NF)) in charge of the storage of such RAN data. In some examples, it is envisaged that this NF may reside at the RAN side, in the CN or at any other network side, and hereafter will be referred to as a RAN data analytics network function (RDANF) 170. In contrast to current mobility management data gathered in the RAN that is solely for a specific purpose (typically used for handover predictions) and available only for a very short time granularity, the examples herein described propose a RDANF 170 that, for example, resides at the CN, whereby the mobility data available at the CN can be used to complement the data available within the RAN as the compressed, low-dimensional latent space-based representation of the RAN data 175 is useful for long term predictions. Thus, in this example, the signal processor 158 of the RDC device 151 is operably coupled (e.g., by a wireline connection) to RDANF 170 to relay the compressed, low-dimensional latent spacebased representation of the RAN data to the CN, in accordance with some examples. Within the RDANF 170, a database 171 is used to store the compressed, low-dimensional latent space-based representation of the RAN data, which is made accessible to other RAN entities and CN entities. In accordance with some examples, a RAN data generation circuit 172 is operably coupled to database 171 and configured to generate additional RAN data samples using the stored compressed, low-dimensional latent space-based representation of the RAN data obtained from the database 171. In some examples, the additional RAN data samples may also be stored in the database 171. In this example and located within the RAN and coupled to RDANF 170, a mobility management prediction circuit 173 is operably coupled to the database 171 and optionally operably coupled to the RAN data generation circuit 172. However, in other examples, it is equally envisaged that the mobility management prediction circuit 173 may be located within the core network (CN), and configured to store the compressed, low-dimensional latent space-based representation of the RAN data in the database 171. In examples herein described, the mobility management prediction circuit 173 employs a mobility management prediction model (e.g., handover prediction model, which in some examples is AI / ML processor 699) that is provided with sufficient training data as well as, optionally, recently obtained data valid for prediction, i.e., using latent-space representation data that the system is able to generate. In one example, as many samples as needed / wanted can be obtained, including the created synthetic data by the RAN data generation circuit 172. Leveraging the mobility management prediction circuit 173, which in some instances comprises a HO prediction circuit that is available at the CN (or RAN) in accordance with the examples described herein, and assuming an accurate handover model, most of the handover procedure can now advantageously be performed in advance. In this manner, a predicted target network entity may be instructed to reserve resources for a UE in advance of any potential handover opportunity or decision. Furthermore, it is also envisaged that the serving network entity may also start exchanging parameters with the predicted target network entity in advance of any potential handover opportunity or decision, following instructions based on an output from the mobility management prediction circuit 173. Thus, when the UE meets the criteria for HO, it sends measurement reports to the serving network entity. If the predicted target network entity matches the one reported by the UE, a fast and smooth HO operation may be performed. In cellular networks, UEs periodically send measurement data that are configured by its serving NG-RAN (or serving network entity / serving gNB). This data includes various measurements performed on the serving cell and neighbouring cells over a certain period of time, such as RSS, RSRP, RSRQ, SINR, etc. The serving gNB can utilize this information to predict the future target NG-RAN (or network entity / gNB) that the UE may move to, and if possible reserve resources in advance on the target NG-RAN to ensure a smooth and seamless handover for this UE. However, exchanging or sharing such a large amount of data among different NG-RAN (gNBs or BSs) will present a significant challenge in wireless networks, especially so in the case of high number of connected UEs in 5G and 6G networks. Inserting Data to the RAN data: To address the aforementioned challenge, examples herein described propose sharing of data available in RAN (e.g., collected from a UE or a group of UEs or collected from a NG-RAN or a group of NG-RANs (gNBs or base stations (BSs))) using a latent-based approach. In some examples, it is also noted that RAN data is not currently shared outside of the RAN. It is known that RAN data may, in some specific instances, be shared within the RAN e.g., for handover purposes. Thus, in accordance with some examples, it is envisaged that a general sharing of RAN data to the CN (not restricted to latent-based data) may be also beneficial in some scenarios. FIG. 2 illustrates an example of a simplified message sequence chart 200 of a purposed data exchange procedure, termed RANCollectionWriting, between a given UE (or a group of UEs), source NG-RAN 101 and RDC 151, in accordance with some example embodiments. Message sequence chart 200 shows an example flow of a data subscription procedure for collecting data from the RAN Data Collector (RDC) 151 by a given NG-RAN 101 (or BS). The message sequence chart 200 shows message exchanges in relation to the RAN measurement workload subscription request and response procedure. When a new NG-RAN 101 wants to provide RAN data information of a UE 210 (or group of UEs), it initiates a subscription procedure with an existing and / or new NF (e.g., RDC 151) that is responsible for collecting and storing the RAN data. At 220, the RAN (or NG-RAN 101) configures measurements for the UE 210. At 230, the UE 210 performs the data measurements as configured by the NG-RAN 101 and reports the measurements to the NG-RAN 101 (or RAN). At 240, the NG-RAN 101 submits a RANCollectionWritingRequest to the RDC 151. In some examples, it is envisaged that the RANCollectionWritingRequest message (or any other suitable naming convention) may contain, for example, one or more of the following information details / elements: UE(s) ID(s), for example a specific set of UE(s) unique identifier(s) of which it wants to provide information; a priority level of the requested data (e.g., high priority for urgent use cases or low priority for less critical use cases; a data collection session ID (e.g., the session collection unique identifier); a NG-RAN ID (e.g., the NG-RAN unique identifier that is providing the data); data fields (e.g., the distinct data types of which the NG-RAN can provide information, e.g., RSS, RSRP, RSRQ, GPS coordinates, etc.); a TimeStamp for the requested data (e.g., data collected hour, day, week, year, etc.); authentication and authorization information (e.g., credentials and permissions required to access the data); network topology information (e.g., the location and identity of neighbouring cells); Quality of Service requirements (e.g., minimum data rate, maximum latency, etc.); data privacy and security policies (e.g., restrictions on how the data can be used or shared); a data collection purpose (e.g. for training, inference, monitoring, training, etc.); a data validity indication (e.g., location, time, etc.); an indication of the granularity of the data (e.g., how often the data will be provided); an expected data size (e.g., what is the expected data size for each new data entries); any other parameter related to the collected data; and / or any other assistance information related to RAN data workload creation and / or handling. In some examples, it is envisaged that upon sending the RANCollectionWritingRequest, the NG-RAN 101 may initiate a count-down timer, e.g., a RAN data subscription response timer. At 250, after receiving the RANCollectionWritingRequest, the RDC 151 assesses whether it has the computation capabilities in order to process the data. In response to a positive determination at 250, the RDC 151 at 260 acknowledges the message and a data transmission pipeline is created. Otherwise, in response to a negative determination at 250, the RDC 151 rejects the NG-RAN 101 (or BS) request at 240 and sends a failure cause value, for example, NoComputationCapabilities (or any other suitable naming). At 270, collected RAN data transmission occurs from the NG-RAN 101 to the RDC 151. In order to stop the data transmission at 270, it is envisaged that either of the parties (NG-RAN 101 or RDC 151) can send a RANCollectionWritingCancellation message 280. It is envisaged that similar and related communications can be used to replace or be added to the concepts and communications described above, with only example messages and communications being used above to describe a possible example exchange between the UE 210, NG-RAN 101 (BS) and RDC 151. Thus, it is envisaged that other implementations may employ similar messages and / or communications performed independently, combined, modified, and / or performed in any order. As mentioned previously, the RDC 151 at the RAN collects RAN data, such as, but not limited to, RSS, RSRP, RSRQ, SINR, UE speed, UE location, UE direction, UE context, and / or other data related to measurement configured by the network (e.g., RAN and / or CN) and / or any other data collected by the network itself (e.g. RAN and / or CN). Once the collected RAN data is inserted into the RDC 151, this data is passed through a latent space representation circuit 159 (located at the RAN), which generates a compressed, low-dimensional latent space-based representation of the RAN data. A latent space representation refers to a lower-dimensional representation of a dataset that captures its most important features or patterns. For example, this representation can be obtained using deep neural nets (variational auto-encoders, transformers, etc), or using manifold approximation techniques among other solutions. In some examples, it is envisaged that the compressed, low-dimensional latent space-based representation of the RAN data located in RDC 151, for example, can be accessed by a large number or all other NG-RANs or NFs at the RAN. Thus, RAN data is now collected independently of the purpose of use, and placed in a centralized entity, e.g., RDC 151. Thereafter, the compressed, low-dimensional latent space-based representation of the RAN data located in RDC 151 can be used to obtain specific features or combinations of features that were not available prior to the development of the examples herein described. Latent-based RAN Data transmission: Referring now to FIG. 3, an example of a simplified message sequence chart 300 of a RANLatentWritingRequest message exchange is illustrated, in accordance with some example embodiments. One example to insert the compressed, low-dimensional latent space-based representation of the RAN data into the database 171 in the RDANF 170 comprises the following messaging exchange procedure. At 310, the RDC 151 at the RAN initiates a communication with the RDANF 170 (residing at the CN or RAN) in order to transmit the compressed, low-dimensional latent space-based representation of the RAN data 175. To do so, in this example, the RDC 151 sends a RANLatentWritingRequest to the RDANF 170. At 320 in this example, upon receiving the RANLatentWritingRequest request from the RDC 151, the RDANF 170 assesses its available resources, and at 330 responds with an RANLatentWritingResponse if enough resources are ready. Then it establishes a connection with the RDC 151 (over a new interface in examples where the RDC 151 resides at the CN). In some examples, the RANLatentWritingResponse may include one or more of the following fields that the data coming from the RDC 151 may contain. It is envisaged that these fields may be, for example, one or more of the following: UE(s) ID(s) of an unique identifier for the user equipment (UE) that generated the RAN data; a Timestamp that indicates a time at which the RAN data was collected; a location ID that indicates a geographical location ID of the UE at the time of data collection; and any other fields, for example any other components that might be necessary for the RDANF 170 to store the compressed, low-dimensional latent space-based representation of the RAN data 175. At 340, the compressed, low-dimensional representation of the RAN data 175 that is generated by the RAN's latent space representation circuit 159 of the RDC 151 is transmitted and inserted in the historical database 171 of the RDANF 170. At 340, the RDANF 170 may also be configured to check whether (or not) the received compressed, low-dimensional latent spacebased representation of the RAN data 175 corresponds to a new sample or an update to an existing sample in the historical latent space database 171. If the sample is new, it is added to the historical latent space database 171. At 270 in some examples, a RAN data generation circuit 172 in the RDANF 170 may use the compressed, low-dimensional latent space-based representation of the RAN data 175 to generate additional RAN data and pre-store the generated additional RAN data for faster information retrieval. At 280, after completing the data exchange and storage process, the connection between the RDC 151 and the RDANF 170 may be terminated via a RANLatentTermination message sent by the RDC 151. In this manner, the message sequence chart 300 of FIG. 3 ensures that the RAN latent space representations of data measurements are efficiently collected, compressed, transmitted, and stored in a comprehensive database 171, where it can be used by RAN data generation circuit 172 to generate additional RAN data to, for example, assist on AI / ML-based mobility management assistance. It is envisaged that similar and related communications can replace or be added to the concepts and communications described above, with only example messages and communications used to describe a possible example exchange between the RDC 151 and the RDNAF 170. Thus, it is envisaged that other implementations may employ similar messages and / or communications performed independently, combined, modified, and / or performed in any order, in particular with the example communication exchanges added to the message sequence chart 200 of FIG. 2. Pre-generate RAN data: Storing RAN data generated from the compressed, low-dimensional latent space-based representation of the RAN data 175 in the RDANF 170 has the benefit of faster future queries. In one example, let us assume that the latent space representations are obtained at the RDC and that the data being saved follows a Gaussian distribution. Instead of storing the data, examples herein described propose just storing a mean and a variance of that distribution (e.g., a latent-space representation), and use the mean and the variance in the future to generate data. Thus, once that mean and variance are stored, it is possible to also generate and store the additional RAN data by RAN data generation circuit 172, so that when a request comes it can be served by just reading from the database 171. If no data has been stored, it is envisaged that a data generation process may be triggered. This process takes a certain amount of time, which can be crucial for applications with a latency constraint. By generating such additional RAN data in advance and storing it in the database 171 in the RDANF 170, the latency involved in generating new RAN data can be avoided when the RDANF 170 is queried. This can reduce the response time of the system, making it more efficient and responsive to the needs of the NFs, applications, analytics circuits or functions, etc. In some examples, it is envisaged that generating additional RAN data by the RAN data generation circuit 172 may be performed on demand when the RDANF 170 is queried, which can help mitigate any risk of stale data. By generating new RAN data when needed, the communication system 100 can be more responsive to changes in the RAN environment. This approach can also reduce the resource consumption of the system, as RAN data is only generated when needed. In summary, noting that the RDC 151 only sends the latent space representation, for example, the mean and variance values of an fdp, some examples provide an option for the RAN data generation circuit 172 to generate the additional RAN data in advance and storing it in the RDANF 170 and / or generate the additional RAN data on demand when the RDANF 170 is queried, where it is envisaged that the selection of the most appropriate option depends on the specific requirements and constraints of the communication system 100. Each approach has its benefits and drawbacks, and the most appropriate approach will depend on factors such as resource availability, system latency requirements, and the need for up-to-date data. RAN Data transmission: When a new NG-RAN 151, other RAN device or component, or NF wants to access UE (RAN) data or a group of UE (RAN) data available at the RDANF 170, it is envisaged in some examples that the following steps may be followed (noting that the data gathering in current systems is performed only for purposes known beforehand. Referring now to FIG. 4, an example of a simplified message sequence chart 400 of a RAN Data transmission message exchange is illustrated, in accordance with some example embodiments. The simplified message sequence chart 400 includes communications between source NG-RAN 101 and RDANF 170. The message sequence chart 400 starts at 410, with the NG-RAN (which can be a RAN component, or NF, or any other logical function) sends a RANSubscriptionRequest message containing, for example, relevant information, such as: UE(s) ID(s): where the specific set of UE unique identifiers of which its data is requested; a Location ID: which can be null and represents a specified network location ID for where the data was obtained; a latest timestamp indicating that the latent space representation was obtained no earlier than this specific time stamp; and any other assistance information. At 420, upon receiving the RANSubscriptionRequest, the RDANF 170 selects a list of possible data points and features from its database that match the requirements. At 430, if the pool of such data points is available, the RDANF 170 retrieves and pre-processes it for transmission. The RDANF 170 then responds with a RANSubscriptionResponse, confirming the availability of historical data for the requested UE or group of UEs. In some examples, the response may include one or more of the following fields: UE(s) ID(s), for example the specific set of UE unique identifiers of which data is available; data type: for example, the type of data that can be retrieved, e.g., RSS, RSRP, RSRQ, GPS coordinates, etc., sent on a per UE ID and location ID (if specified) basis as it can vary from UE to UE; Data time stamps indicative of when the data was obtained; a recommended list of desired data features and labels that the mobility management functions want the input data to have, and upon which the model is to be based, and its associated labels; and a number of available data points that can be generated. Alternatively, in contrast to 430, the RDANF 170 may respond with a RANSubscriptionCancellation if no data matching the criteria has been found. At 440, once the interested party receives the response, it can select the desired features and labels for data transfer via, say, a RANUpdatedResponse. At 450, the data transfer may trigger the sample generation process, if it has not happened beforehand. Finally, the data transmission occurs. In this manner, efficient data collection and storage may be enabled for a longer duration of time because the data is compressed, the transmission overhead is minimized because the data is compressed, and personalized mobility management solutions based on historical mobility patterns are enabled because the historical data may be used to train an AI / ML processor or may be used for inference in case there is need for a batch of samples (avoiding the cold start problem of some ML solutions). It is noteworthy that the above message sequence chart 400 shows an example of the proposed solution / method for creation / execution of an RAN latent-based workload, and that other steps, states, messages and / or signalling could also be included in the above description / figure, however, were removed above for simplicity of description. It is noted that the message sequence chart in FIG. 4 only shows examples of possible messages and / or steps to describe a possible example of exchange between the NG-RAN 151, a RAN NF and / or RDC. However, other messages and / or steps may be added to the message sequence chart 200 of FIG. 2. Moreover, the steps maybe performed independently, combined, modified, and / or in any order. Use case - ML Model to use Data for Prediction: As previously described, the RDANF 170 stores the latent space-based RAN data collected by the source NG-RAN 101, which may include information about the UE's RAN metrics such as RSS, RSRP, RSRQ, SINR, and any other relevant data. The mobility management prediction circuit, which in some examples utilizes AI / ML techniques to predict possible handovers for each UE, continuously monitors the RAN data collector for any updates or changes in the UE's data record. The mobility management prediction circuit 173 (e.g., a HO prediction circuit) uses the latent space-based representation of the latent space-based RAN data in order to generate additional data that is used to further improve the accuracy of the handover prediction. In some examples, this may be accomplished by RAN data generation circuit 172 leveraging the latent space representation of the latent space-based RAN data in order to synthesize additional RAN data points that are similar to the existing data, thereby increasing the sample size and diversity of the data set used for handover prediction. In this manner in one example use case, historical data and current data are used in combination in order to predict better handover decisions, which is not possible in currently known systems. Using this approach, the HO predictor may be able to make more accurate and efficient predictions about possible handovers for each UE, thereby enabling the source NG-RAN 101 to reserve resources and establish a smooth and seamless handover to the target NG-RAN 505 in FIG. 5. Once the HO predictor identifies a potential handover for a UE, the source NG-RAN 101 may inform the target NG-RAN 505 of the handover and thereafter exchanges UE context information, for example including security and ciphering parameters, in order to allocate and reserve resources at the target NG-RAN 505 in advance. Thus, by leveraging latent space-based data representation and AI / ML techniques, the proposed system offers an innovative and effective solution for mobility management in mobile networks. In some examples, the use of latent space-based data representation and synthesis may improve the accuracy and efficiency of handover prediction, thereby enabling more seamless and uninterrupted service for mobile users. Referring now to FIG. 5, an example of a simplified message sequence chart 500 for a procedure for information exchange of HO use case is illustrated, in accordance with some example embodiments. The simplified message sequence chart 500 includes communications between source NG-RAN 101, a RDANF 170, a target NG-RAN 505 and mobility management prediction circuit 173 (such as a HO predictor). The message sequence chart 500 starts at 515 with the mobility management prediction circuit 173, for example residing in a network function or set of functions and / or a network entity or set of entities, fetching the identities IDs of a UE or group of UEs connected to the source NG-RAN 101. At 520, the mobility management prediction circuit 173 fetches data specific to the obtained UE(s) ID(s) from the RDANF 170. If the data has not been pre-generated the RDANF 170 generates new data traces for the received UE(s) ID(s) at 530. At 540, the RDANF 170 may then share the data traces with the mobility management prediction circuit 173. Based on the provided data traces, the mobility management prediction circuit 173 may perform inference at 550 about a possible location in the near future of these UEs. At 560, the mobility management prediction circuit 173 informs the source NG-RAN 101 about the UE’s IDs that are expected to be handed over and provides the NG-RAN IDs of the expected target NG-RANs 505. At 570 the source NG-RAN 101 shares that information with the target NG-RAN 505, thereby exchanging key and UE context. If forecasting is correct, the handover occurs and is confirmed by the target NG-RAN 505 at 580. It is noted that the simplified message sequence chart 500 only shows examples of possible messages and / or steps, in order to describe a possible example of exchange between the source NG-RAN 101, the target NG-RAN 505, the RDANF 170 and / or RDC. However, it is envisaged that other messages and / or steps may be added to the message sequence chart 200. Moreover, the steps maybe performed independently, combined, modified, and / or in any order. Handover Execution Time: Accurate and reliable handover prediction is crucial for network operators to plan their network resources and minimize service interruptions for UEs. Therefore, predicting future cell IDs of UEs helps network operators allocate resources to the target network entity in advance. This approach may reduce overhead and reduce service interruption time for UEs. A typical handover procedure in 3 GPP™ involves the UE measuring the received signal strength (RSS) of the serving and neighbouring cells, followed by the serving cell determining the target network entity to which the UE should be associated. The serving cell then establishes a connection with the target cell, which checks and reserves resources for the new UE. Next, the serving network entity sends all the UE-specific data, such as security and ciphering, to the target network entity for connection establishment. Finally, the UE detaches from the serving network entity and associates with the target network entity, and the data plane switches. Leveraging the HO prediction circuit 173 that is available as a separate entity in the RAN, coupled to the RDANF 170 in accordance with the examples described herein, and assuming an accurate handover model, most of the handover procedure can now advantageously be performed in advance. In this manner, the predicted target network entity may be instructed to reserve resources for the UE in advance, and the serving network entity may also start exchanging parameters with the predicted target network entity in advance of any handover decision. When the UE meets the criteria for HO, it sends measurement reports to the serving network entity. If the predicted target network entity matches the one reported by the UE, a fast and smooth HO operation is performed. Otherwise, the standard handover procedure defined in the 3 GPP is executed. In case the predicted target network entity does not match the one reported by the UE, additional signalling may be needed in order to cancel the resources pre-reserved in a wrongly predicted target network entity. Thus, examples herein described provide a mobility management prediction circuit / model with enough training data and recent data valid for prediction, i.e., using latent-space representation data the system is able to generate as many samples as needed / wanted, including the created synthetic data. Taking the above example above, it is possible to sample a Gaussian distribution as many times as needed / wanted in order to obtain samples from it. In this manner, a smoother handover and more precise prediction can be achieved. Unlike known HO prediction techniques, which only rely on the RSRP data gathered for the period a UE is served from a particular network entity, the proposed method described herein shares RAN metrics across network entities. This approach provides more reliable ML models and higher accuracy in HO prediction. Additionally, examples may solve a problem of acquiring enough data during the time that a UE is attached to a small cell. In scenarios with Pico cells and Femto cells, where the coverage range is short, collecting enough data during a high-speed mobility pattern becomes difficult. The approach described herein provides each network entity with enough data to train the model from the very beginning that a UE joins, it is possible to leverage the existing latent-space data of that UE for that cell to generate data for inference purposes and also provide enough data for the training phase, which leads to high-performing HO prediction models. In summary, the examples described herein may help network operators improve their handover prediction accuracy and reduce service interruption time for UEs. By sharing RAN metrics across network entities, it is possible to provide enough data for the training phase, leading to higher accuracy in HO prediction. RSRP Data Collection for Handover Prediction: In the current approach for RSRP Data Collection for Handover, each NG-RAN only has access to the data available locally, i.e., there is currently no transfer of RAN mobility data between RANs, thereby resulting in suboptimal performance, especially for high-mobility UEs or network configurations, e.g., a lot of pico / femto cells. In contrast, according to some examples herein described, the inventors have recognised and appreciated that such data may be useful, particularly if each RAN employs an entity with an AI / ML processor 699. Referring now to FIG. 6, an example of a neural network 600 that may be employed as a learning processor, such as an artificial intelligence (Al)-based learning processor such as learning processor 699, is described to improve handover optimization, according to some example embodiments according to some examples. It is envisaged that any entity in the RAN or CN may be configured to access stored RAN data, as described previously, for use and access by an AI-based learning processor, e.g., for improved handover optimization. In some examples, the example neural network 600 may comprise a convolutional neural network 600 that is arranged to apply a series of node mappings 680 to an input 610, which ultimately resolves into an output 630 consisting of one or more values, from which at least one of the values is used by the neural network 600. The example (convolutional) neural network 600 comprises a consecutive sequence of network layers (e.g., layers 640), each of which consists of a series of channels 650. The channels are further divided into input elements 660. In this example, each input element 660 may store a single value. Some (or all) input elements 660 in an earlier layer are connected to the elements in a later layer by node mappings 680, each with an associated weight. The collection of weights in the node mappings 680, together, form the neural network model parameters 647. For each node mapping 680, the elements in the earlier layer are referred to as input elements 660 and the elements in the output layer are referred to as the output elements 670. An element may be an input element to more than one node mapping, but an element is only ever the output of one node mapping 680. In order to calculate the output 630 of the (convolutional) neural network 600, the system first considers the input layer as the earlier layer. The layer(s) to which the earlier layer is connected by a node mapping 680 is / are considered, in turn, as the later layer. The value for each element in later layers is calculated using the node mapping 680 in equation [1], where the values in the input elements 660 are multiplied by their associated weight in the node mapping 680 and summed together. Node mapping 680: d = A(wad X a + wbd X b + wcd X c) [1] The result of the summing operation is transformed by an activation function, ‘A’ and stored in the output element 670. The (convolutional) neural network 600 now treats the previously considered later layer(s) as the earlier layer, and the layers to which they are connected as the later layers. In this manner, the (convolutional) neural network 600 proceeds from the input layer 640 until the value(s) in the output 630 have been computed. In some examples, the (convolutional) neural network 600 may be trained. In some examples, the training of the convolutional neural network 600 may entail repeatedly presenting data as the input 610 of the (convolutional) neural network 600, in order to improve handover optimization. In some examples, an optimization algorithm may be used to reduce a loss function, for example by measuring how much each node mapping 680 weight contributed to the loss, and using this to modify the node mapping 680 in such a way as to reduce the loss. Each such modification is referred to as an iteration. After a sufficient number of iterations, the convolutional neural network 600 can be used to analyze the input data to assist a handover optimization. In some examples, the large number of model parameters 647 used in the (convolutional) neural network 600 may require the device to include a memory 690. The memory 690 may be used to store the training data 615, the model parameters 647, and any intermediate results 693 of the node mappings. Thus, in the learning processor 699, input data (e.g., a training dataset, clinical dataset, model parameters or intermediate results) is fed to the learning processor 699 neural network in a format that fits the input matrix. Nodes are mapped in a specific way that is adapted to the purpose of the device (forming e.g., a convolutional neuronal network). The information is gradually reduced through a series of interconnected input / output elements to generate the final output. In this manner, personalized mobility management solutions based on historical mobility patterns may be enabled because the historical data may be used to train an AI / ML processor or may be used for inference in case there is need for a batch of samples (avoiding the cold start problem of some ML solutions. Thus, in some examples, the generated additional RAN data stored in a database may be accessed by a RAN device in performance of at least one of: training a machine learning processor 699 with RAN data; inference of RAN data; a comparison with monitored RAN data, a Life-Cycle-Management, LCM, model purposes, such as activation, deactivation, fallback, switching, selection of model, etc. Examples herein described provide a novel method and apparatus for enhancing AI / ML-assisted mobility management in mobile networks through latent space-based RAN data collection, storage, and transmission. In summary, the proposed method provides a way to generate sufficient data for the machine learning model, which is important for creating accurate and reliable handover predictions and helping mitigate a cold start problem by collecting RAN metrics across multiple network entities / base stations / gNBs. Examples herein described provide a system, apparatus, new interfaces, new signalling and methods for re-generating of data, storage, and utilization of RAN data, for example to assist mobility management in a wireless network. Examples herein described provide a range of optional, potential benefits, including: enabling efficient collection and storage of RAN data for a longer duration of time that can be used for mobility management; reducing a transmission overhead associated with exchanging large amounts of RAN data between neighbouring network entities using a known compression approach, complementing RAN-related mobility data with data available in the core to improve mobility management; increasing the accuracy of predicting UE (User Equipment) mobility and reducing handover-related overhead and interruption time (as more data can be used for training, so higher accuracy can be obtained), and enabling a provision of personalized services for each UE based on their historical mobility patterns. The system uses a novel method of RAN data collection, storage, and transmission based on a latent space representation of the RAN. ML algorithms are employed to assist in mobility management operations, and UE historical data is utilized to train ML models at the RAN, which can be used to predict UE mobility and handover events. The system uses a distributed architecture to make RAN data available across the network whilst minimizing the transmission overhead. The invention provides an Al-based system and method for predicting handovers in a RAN. It employs a novel approach to data representation and augmentation, using RAN latent-space representation data and synthetic data generation. Following we provide an example of how to implement this type of solutions: Synthetic Data Generation: Synthetic data based on the latent space representations is generated at the RDNAF. This synthetic data augmentation enhances the diversity of training examples, thereby improving model robustness and generalizability. Data Acquisition: Data is collected from the RDNAF. This data encompasses features necessary for handover prediction, such as user mobility patterns, RSRP measurement, RSRQ measurements, and other contextual information. Preprocessing: The acquired data undergoes a preprocessing step, which involves data cleaning (handling missing values, removing outliers), data normalization (scaling data to a similar range), and data transformation (converting categorical variables into numerical ones). Model Selection: A suitable AI model for handover prediction is chosen. The selection may include traditional machine learning models (e.g., decision trees, random forests, SVMs) or deep learning models (e.g., CNNs, RNNs, LSTMs, Transformers). Model Training: The selected model is trained on the preprocessed and augmented data. Optimization algorithms and loss functions suitable for the task are used. Techniques like cross-validation or early stopping may be employed to enhance model performance. Model Testing &Evaluation: Post-training, the model is tested on a separate dataset. Performance metrics such as accuracy, precision, recall, Fl-score, and AUC-ROC may be used for evaluation. In case of unsatisfactory performance, adjustments may be made to the model, features, or hyperparameters. Deployment &Monitoring: Once satisfactory performance is achieved, the model is deployed in the live RAN environment for handover predictions. Continuous monitoring and updating are performed to ensure model accuracy and reliability over time. Personalised mobility management solutions are provided for each UE based on their mobility patterns. In accordance with some of the examples described herein, it is noted that sharing of RAN mobility data with the CN may be performed in general, and only in some instances use compressed, low-dimensional latent space-based representation of the RAN mobility data 175. In this context of a generic sharing of RAN mobility data with the CN, e.g., from a database of RAN data and without using latent space representation techniques, may be beneficial for one or more of the following scenarios. A first example scenario for generally sharing RAN mobility data with the CN is in a context of network optimization. Here, for example, RAN data may contain information about resource allocation, user equipment behaviour, and network performance. Hence, by analyzing this data, the CN may be able to identify potential communication bottlenecks, congestion, or inefficiencies in the RAN and thereafter optimize resource allocation, load balancing, and any other network parameters accordingly. A second example scenario for generally sharing RAN mobility data with the CN is in a context of monitoring and fault detection. Here, for example, storing RAN data in the CN may enable real-time monitoring of network performance, as well as early identification of potential issues or failures. With this information, network operators may be able to quickly react to problems, minimize downtime, and ensure a seamless user experience. A third example scenario for generally sharing RAN mobility data with the CN is in a context of traffic forecasting and capacity planning. Here, for example, historical RAN data may be used to predict future traffic patterns and demands, thereby allowing network operators to make informed decisions about capacity expansion, infrastructure investments, and other strategic planning activities. A fourth example scenario for generally sharing RAN mobility data with the CN is in a context of anomaly detection and security. Here, for example, by analyzing RAN data, the CN may be able to detect anomalous behaviour, such as unauthorized access attempts or unusual traffic patterns, which might indicate security breaches or network vulnerabilities. This allows network operators to proactively address potential threats and maintain the overall security and integrity of the system. A fifth example scenario for generally sharing RAN mobility data with the CN is in a context of Quality of Service (QoS) management. Here, for example, RAN data may be used to help the CN monitor the quality of service provided to users, thereby ensuring that different types of traffic (e.g., voice, data, and video) receive the appropriate level of priority and resources. It is envisaged that this is particularly important in scenarios with limited resources or during periods of high network demand. A sixth example scenario for generally sharing RAN mobility data with the CN is in a context of support for machine learning and analytics. Here, for example, the availability of RAN data at the CN may enable the use of machine learning algorithms and other advanced analytics techniques for various purposes, such as network optimization, demand forecasting, and anomaly detection. These insights can help improve network performance, user experience, and overall efficiency. In particular, it is envisaged that the aforementioned inventive concept can be applied by a semiconductor manufacturer to any integrated circuit comprising a signal processor configured to perform any of the aforementioned operations. Furthermore, the inventive concept can be applied to any circuit that is able to configure, process, encode and / or decode signals for wireless distribution. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a digital signal processor, or application-specific integrated circuit (ASIC) and / or any other sub-system element. It will be appreciated that, for clarity purposes, the above description has described example embodiments with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units or processors, for example with respect to the signal processor may be used without detracting from the concepts described herein. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization. Aspects may be implemented in any suitable form including hardware, software, firmware or any combination of these. Example embodiments may optionally be implemented, at least partly, as computer software running on one or more data processors and / or digital signal processors or configurable circuit components such as FPGA devices. Thus, the elements and components of an embodiment may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. Although the concepts have been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in other examples. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps. Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and / or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate. In accordance with examples herein described, a number of approaches are provided to enable better access to RAN data, wherein the aforementioned disadvantages with prior art arrangements have been substantially alleviated. References: [1] M. S. e. a. Mollel, “A survey of machine learning applications to handover management in 5G and beyond,” IEEE Access, pp. 45770-45802, 2021. [2] E. e. a. Gures, “A comprehensive survey on mobility management in 5G heterogeneous networks: Architectures, challenges and solutions,” IEEE Access, vol. 8, pp. 195883-195913, 2020. [3] 3GPP TS 37.320, “Radio measurement collection for Minimization of Drive Tests (MDT); Overall description;”, VI7.2.0, Dec. 2022. Abbreviations / Definitions In the present disclosure, the following acronyms / definitions are used. 3 GPP 3rd Generation Partnership Project 5G 5th Generation 5GC 5G Core 5QI 5G QoS Identifier 5GS 5G System 5GSM 5G System Session Management 5GMM 5G System Mobility Management AF Application Function AI Artificial Intelligence AM Acknowledged Mode AMF Access and Mobility Management Function AS Application Server ASP Application Service Provider AUSF Authentication Server Function CDN Content Delivery Network CN Core Network DCAF Data Collection Application Function DNAI Data Network Access Identifier DNN DNS Data Network Name Domain Name Server DRB Data Radio Bearer gNB Evolved Node B 5 EPC Evolved Packet Core FEC Forward Error Correction FQDN Fully Qualified Domain Name GBR Guaranteed Bit Rate gNB Next generation Node B 10 GPSI Generic Public Subscription Identifier HSS Home Subscriber Service IAB Integrated Access and Backhaul ID Identity / Identifier IIoT Industrial Internet of Things 15 I ME I International Mobile Equipment Identities IP Internet Protocol I-SMF Intermediate SMF LADN Local Area Data Network LLSSM Lower Layer SSM 20 MBMS Multimedia Broadcast / Multicast Service MBS Multicast / Broadcast Service MBSF Multicast / Broadcast Service Function MBSTF Multicast / Broadcast Service Transport Function MB-SMF Multicast / Broadcast Session Management Function 25 MB-UPF Multicast / Broadcast User Plane Function ML Machine Learning MME Mobility Management Entity MN Master Node MNF Monitoring Network Function 30 MNO Mobile Network Operator MT Mobile Termination NAS Non-Access Stratum NEF Network Exposure Function NRF Network Repository Function 35 NG-RAN Next Generation Radio Access Network NG-gNB Next Generation gNB NSA Non-Standalone NSSF Network Slice Selection Function NTN Non-Terrestrial Networks 40 NW Network NWDAF Network Data Analytics Function OS Operating System OSAPP OS Application PCF Policy Control Function 45 PCO Protocol Configuration Options PDR Packet Detection Rule PDU Protocol Data Unit PTM Point To Multipoint PTP Point to Point QFI QoS Flow Identifier (ID) 5 QoS Quality of Service RACH Random Access Channel RAN Radio Access Network RRC Radio Resource Control RSD Route Selection Descriptor 10 RSRP Reference Signal Received Power RSRQ Reference Signal Received Quality RSS Reference Signal Strength RSSI Received Signal Strength Indicator. SA Standalone 15 SDAP Service Data Adaptation Protocol SDU Service Data Unit SGW Serving Gateway SIM Subscriber Identity Module SLA Service Level Agreement 20 SM Session Management SMF Session Management Function SN Secondary Node S-NSSAI Single Network Slice Selection Assistance Information SSB Synchronization Signal Block 25 SSM Source Specific IP Multicast address ssc Session and Service Continuity SRB Signaling Radio Bearer SUPI Subscription Permanent Identifier TA Tracking Area 30 TAI Tracking Area Identity TE Terminal Equipment TM Transparent Mode TMGI Temporary Mobile Group Identity TS Technical Specification 35 UDM Unified Data Manager UDR Unified Data Repository UE User Equipment UL Uplink UM Unacknowledged Mode 40 UP User Plane UPF User Plane Function URLLC Ultra-Reliable and Low-Latency Communication URSP UE Route Selection Policy

Claims

18 07 251. A wireless communication system (100) comprises:a first network entity (101) comprising a transceiver operably coupled to a signal processor and configured to support wireless communication for a plurality of wireless communication units; anda radio access network, RAN, device (151) operably coupled to the first network entity (101) that is configured to collect RAN mobility data of the plurality of wireless communication units and provide the RAN mobility data to the RAN device (151); wherein the RAN device (151) comprises or is operably coupled to a latent space representation circuit (159) configured to generate and transmit compressed, low-dimensional latent space-based representation of the RAN mobility data (175);a RAN data analytics device (170) operably coupled to the RAN device (151) and comprising a database (171) that is configured to receive and store a received compressed, lowdimensional latent space-based representation of the RAN mobility data (175),wherein the RAN data analytics device (170) comprises or is operably coupled to a RAN data generation circuit (172) that is configured to generate additional RAN data samples using the stored compressed, low-dimensional latent space-based representation of the RAN mobility data (175) obtained from the database (171).

2. The wireless communication system (100) of Claim 1, wherein the RAN device (151) is a radio access network, RAN, data collector, RDC, device (151).

3. The wireless communication system (100) of Claim 1 or Claim 2, wherein the RAN data analytics device (170) is a RAN data analytics network function, RDANF, (170).

4. The wireless communication system (100) of any preceding Claim, wherein the network entity (242) and the RAN data analytics device (170) is located in one of: the RAN, a core network, CN, in the wireless communication system (100).18 07 255. The wireless communication system (100) of Claim 1, wherein, the RAN data generation circuit (172) is configured to generate additional RAN data samples for a specific user equipment, UE, or group of UEs, based on a set of features or conditions of the generated additional RAN data samples.

6. The wireless communication system (100) of Claim 5, wherein the set of features or conditions of the generated additional RAN data samples comprises at least one of:a desired Reference Signal Received Power, RSRP,a desired radio signal strength, RSS, a desired radio signal strength indicator, RSSI,a desired Reference Signals Received Quality, RSRQ,global positioning system, GPS, coordinates for a specific UE;and wherein the RAN data generation circuit (172) is configured to generate data samples that match the additional RAN data samples.

7. The wireless communication system (100) of Claim 5 or Claim 6, wherein the generated additional RAN data stored in the database (171) is accessed by a RAN device in performance of at least one of: training a machine learning processor (699) with RAN data; inference of RAN data; a comparison with monitored RAN data, a Life-Cycle-Management, LCM, model.

8. The wireless communication system (100) of any preceding Claim, wherein the RAN data generation circuit (172) is configured to generate additional RAN data samples in advance of a potential handover of an user equipment, UE.

9. The wireless communication system (100) of any preceding Claim, wherein the database (171) is configured to be accessible to at least one of: a plurality of RAN entities, at least one CN entity.18 07 2510. The wireless communication system (100) of any preceding Claim, wherein the RAN data analytics device (170) comprises or is operably coupled to a mobility management prediction circuit (173) operably coupled to the database (171) and configured to train the mobility management prediction circuit (173) using the additional RAN data samples.

11. The wireless communication system (100) of any preceding Claim, wherein, the first network entity (101) is configured to initiate a subscription procedure with the RAN device (151) that is responsible to generate the compressed, low-dimensional latent space-based representation of the RAN mobility data (175) prior to obtaining RAN mobility data for a user equipment, UE, (210) or group of UEs.

12. The wireless communication system (100) of any preceding Claim, wherein the RAN mobility data comprises at least one of the following information elements:a specific set of user equipment, UE, (210) unique identifiers, IDs;a priority level of requested data; a RAN mobility data collection session ID;an unique identifier of the first network entity (101);at least one data field;a TimeStamp for requested RAN mobility data;authentication and authorization information;network topology information;a Quality of Service, QoS, requirement;at least one RAN mobility data privacy and security policy;a RAN mobility data collection purpose;a RAN mobility data validity indication;an indication of a granularity of the RAN mobility data; and an expected data size.

13. A radio access network, RAN, data analytics device (170) located in a Core Network, CN, comprises:18 07 25a receiver operably coupled to the database (171) and configured to receive, from a RAN device (151), compressed, low-dimensional latent space-based representation of RAN mobility data (175) generated from collected RAN mobility data of a plurality of wireless communication units;a database (171) operably coupled to the receiver and configured to store the received compressed, low-dimensional latent space-based representation of the RAN mobility data (175) and configured to be accessible by at least one of: a plurality of RAN entities, at least one other CN entity;wherein the RAN data analytics device (170) comprises a RAN data generation circuit (172) that is configured to generate additional RAN data samples using the stored compressed, low-dimensional latent space-based representation of the RAN mobility data (175) obtained from the database (171).

14. A method for a radio access network, RAN, data analytics device, (170) located in a Core Network, CN, comprises:receiving, from a RAN device (151), compressed, low-dimensional latent space-based representation of RAN mobility data (175) generated from collected RAN mobility data of a plurality of wireless communication units;storing the received compressed, low-dimensional latent space-based representation of the RAN mobility data (175) in a database (171);allowing access to the compressed, low-dimensional latent space-based representation of the RAN mobility data (175) in the database (171) by at least one of: a plurality of RAN entities, at least one other CN entity; andgenerating, by a RAN data generation circuit (172), additional RAN data samples using the stored compressed, low-dimensional latent space-based representation of the RAN mobility data (175) obtained from the database (171).

Images