Feedback regarding predicted user device trajectories

Abstract

The present disclosure relates to a method performed by a first network node, the method comprising: obtaining (1101) a user equipment, UE, trajectory prediction, transmitting (1102) the UE trajectory prediction to a second network node and an indication requesting feedback on the UE trajectory prediction, and receiving (1103) feedback on the UE trajectory prediction from a third network node; the present disclosure relates to a first network node, and to a method performed by a second network node, the method comprising receiving (1201) a UE trajectory prediction and an indication requesting feedback on the UE trajectory prediction, and transmitting (1202) the feedback on the UE trajectory prediction to the first network node.

Description

Technical Field

[0001] Embodiments of the present disclosure are directed to wireless communications, and more particularly, to feedback regarding predicted user equipment (UE) trajectories. Background Art

[0002] Generally, unless different meanings and / or different meanings are implied by the context in which it is used, otherwise they will be interpreted according to the ordinary meaning of all terms used in this article in the relevant technical field. Unless otherwise clearly stated, all references to one / an / described element, equipment, parts, devices, steps, etc. will be openly interpreted as referring to at least one instance of described element, equipment, parts, devices, steps, etc. Unless a step is clearly described as being followed by another step or before another step and / or it is implied that a step must be followed by another step or before another step, it is not necessary to perform the steps of any method disclosed herein in the precise order disclosed. Where appropriate, any feature of any embodiment in the embodiments disclosed herein may be applicable to any other embodiment. Similarly, any advantage of any embodiment in the embodiment may be applicable to any other embodiment, and vice versa. By the following description, other purposes, features and advantages of the attached embodiments will be apparent.

[0003] The Next Generation Radio Access Network (NG-RAN) consists of a collection of gNBs connected to the Fifth Generation Core (5GC) through NG interfaces. Figure 1 An example is shown in .

[0004] Figure 1 This is a block diagram illustrating the NG-RAN architecture as described in Technical Specification (TS) 38.401 (e.g., v17.2.0). As specified in TS 38.300 (e.g., v17.2.0), the NG-RAN may also consist of a group of ng-eNBs. The ng-eNB may consist of an ng-eNB central unit (CU) and one or more ng-eNB distributed units (DUs). The ng-eNB-CU and ng-eNB-DU are connected via the W1 interface. Unless explicitly stated otherwise, the general principles described herein also apply to the ng-eNB and the W1 interface.

[0005] A gNB can support frequency division duplex (FDD) mode, time division duplex (TDD) mode, or dual-mode operation. gNBs can be interconnected via the Xn interface. A gNB may consist of a gNB-CU and one or more gNB-DUs. The gNB-CU and gNB-DUs are connected via the F1 interface. A gNB-DU is connected to only one gNB-CU.

[0006] For network sharing with multiple cell identity broadcast, each cell identity associated with a subset of the Public Land Mobile Network (PLMN) corresponds to a gNB-DU and its connected gNB-CU, i.e., the corresponding gNB-DUs share the same physical layer cell resources.

[0007] For resiliency, one gNB-DU can be connected to multiple gNB-Cu with proper implementation.

[0008] NG, Xn and F1 are logical interfaces.

[0009] For NG-RAN, the NG and Xn-C interfaces of a gNB, consisting of a gNB-CU and gNB-DU, are terminated at the gNB-CU. For EN-DC, the S1-U and X2-C interfaces of a gNB, consisting of a gNB-CU and gNB-DU, are terminated at the gNB-CU. The gNB-CU and the connected gNB-DU are visible only to other gNBs and the 5GC acting as the gNB.

[0010] The node hosting the user plane portion of the New Radio (NR) Packet Data Convergence Protocol (PDCP) (e.g., gNB-CU, gNB-CU-UP, and, for EN-DC, the MeNB or SgNB depending on bearer splitting) shall perform user inactivity monitoring and further notify nodes with C-plane connectivity towards the core network (e.g., via E1, X2) of their inactivity or (re)activation. The node hosting the NR Radio Link Control (RLC) (e.g., gNB-DU) may perform user inactivity monitoring and further notify the node hosting the control plane (e.g., gNB-CU or gNB-CU-CP) of their inactivity or (re)activation.

[0011] The uplink (UL) PDCP configuration (i.e., how the UE uses the UL at the secondary node) is indicated via X2-C (for EN-DC), Xn-C (for NG-RAN), and F1-C. Radio link interruption / recovery for the downlink (DL) and / or UL is indicated via X2-U (for EN-DC), Xn-U (for NG-RAN), and F1-U.

[0012] NG-RAN is layered into the Radio Network Layer (RNL) and the Transport Network Layer (TNL). The NG-RAN architecture (i.e., the NG-RAN logical nodes and the interfaces between them) is defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the relevant TNL protocols and functionality are specified. The TNL provides services for user plane transport and signaling transport.

[0013] In an NG-Flex configuration, each NG-RAN node is connected to all access and mobility management functions (AMFs) of an AMF set within an AMF area that supports at least one slice also supported by the NG-RAN node. AMF sets and AMF areas are defined in 3GPP TS 23.501 (e.g., v17.6.0).

[0014] If security protection of control plane and user plane data on the TNL of the NG-RAN interface must be supported, Network Domain Security (NDS) / Internet Protocol (IP) 3GPP TS 33.501 (e.g. v17.7.0) shall be applied.

[0015] The architecture for the separation of gNB-CU-CP and gNB-CU-UP is Figure 2 and specified in TS 37.483 (e.g. v17.2.0).

[0016] Figure 2 This is a block diagram illustrating the architecture for the separation of the gNB-CU-CP and gNB-CU-UP. A gNB may consist of a gNB-CU-CP, multiple gNB-CU-UPs, and multiple gNB-DUs.

[0017] The gNB-CU-CP connects to the gNB-DU via the F1-C interface. The gNB-CU-UP connects to the gNB-DU via the F1-U interface. The gNB-CU-UP connects to the gNB-CU-CP via the E1 interface. One gNB-DU connects to only one gNB-CU-CP. One gNB-CU-UP connects to only one gNB-CU-CP.

[0018] For resiliency, a gNB-DU and / or gNB-CU-UP can be connected to multiple gNB-CU-CPs through appropriate implementation. A gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP. A gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP.

[0019] Connectivity between the gNB-CU-UP and the gNB-DU is established by the gNB-CU-CP using bearer context management functionality. The gNB-CU-CP selects the appropriate gNB-CU-UP(s) for the service requested by the UE. For multiple CU-UPs, they belong to the same security domain as defined in TS 33.210 (e.g., v17.1.0). During intra-gNB-CU-CP handover within a gNB, data forwarding between gNB-CU-UPs can be supported by Xn-U.

[0020] 3rd Generation Partnership Project (3GPP) Release 16 includes UE history information. Network nodes collect information about cells visited by UEs in active mode and store it as UE history information. The information is stored as a chronological list related to each cell, with the most recent information at the top of the list. In the 3GPP standard, this list is capped at 16 entries (16 cells) because the stated goal of the UE history information is to prevent ping-pong. Ping-pong handovers are an undesirable phenomenon in mobile networks where a UE performs frequent handovers back and forth between the same pair of cells within a short period of time.

[0021] During handover on Xn, the UE history information collected at the node is transferred to the target node. Similarly, it is sent to the CN via the NG during context release.

[0022] The data stored depends on the type of cell connected as seen in the procedure text. For NR cells, the network node collects the global cell ID, cell type, time the UE stayed in the cell and handover reason and stores them for each UE at cell change / handover.

[0023] The information element (IE) UE History Information from the UE corresponds to the Mobility History Information (MHI), defined in 3GPP TS 38.413 v17.1.0, and contains information about the UE's mobility history report. The mobility history contains a list of (one or more) cells to which the UE is connected or camped on. It is generated by the UE in RRC_Connected, RRC_INACTIVE, and IDLE. The content of the IE is shown below:

[0024] The referenced VisitedCellInfoList information element (IE) is defined in 3GPP TS 38.331 v17.1.0 as follows:

[0025] Another mobility history is generated by the network and is called UE History Information (UHI). It contains a list of cells to which the UE is connected. It is generated by the network in RRC_Connected. It is defined in TS 38.413. This IE contains information about the cells that the UE has been served by before the target cell in the active state. The last visited cell information IE may contain cell specific information.

[0026] The Last Visited NG-RAN Cell Information IE contains information about the cell. For NR cells, the IE contains information about the set of NR cells with the same NR Absolute Radio Frequency Channel Number (ARFCN) for reference point A, and the Global Cell ID IE identifies one of the NR cells in the set. This information is to be used for Radio Resource Management (RRM) purposes.

[0027] Starting with release 17, the UHI and MHI may also contain historical information about the PSCell.

[0028] Release 17 work on UE history information has progressed to incorporate PSCell history information. The responsibility for collecting UE history information is split between the Master Node (MN) and the Secondary Node (SN). The MN is responsible for collecting PCell-related information, and the SN is responsible for collecting PSCell-related information. The MN obtains the information collected by the SN through subscription, query, and / or SN release procedures. Finally, the MN correlates the PSCell information from the SN with the collected PCell information. This correlated UE history information is then sent to the target MN during handover.

[0029] The information present in the MHI and UHI includes the following: Previous PCell List: The UHI contains a list of previously visited PCells, with a maximum limit of 16. Previous PSCell List: UHI contains the list of PSCells that each PCell accesses. The upper limit of this for UHI is 8 per PCell. Duration of stay in each cell: UHI contains the duration that the UE stays in each PCell and PSCell. This duration can have a maximum value of 4095 seconds (about 68 minutes). There are additional IEs with higher granularity. Handover Cause: UHI contains the handover cause (inter-MN). However, this does not exist in the PSCell-related UHI. Cell type: The UHI finally contains information about the cell type, which is enumerated as (very small, small, medium, large, ...).

[0030] WO2021028893A1 (Enhancement of Mobility History Information) describes a method for operating a UE, comprising: receiving a request for UE mobility history information from a network node; generating a UE mobility history report; and transmitting the UE mobility history report to the network node, wherein the UE mobility history report includes beam-related information, sensor information, location information and / or dual connectivity information of the UE.

[0031] Beam-related information includes: (a) beam identifiers of beams monitored by the UE; (b) beam identifiers of all beams monitored by a single network transceiver node; (c) beam identifiers of the strongest beam monitored by a single network transceiver node; (d) timing information; and / or (e) measurement time and / or discontinuous reception (DRX) related information.

[0032] The 3GPP RAN3 study item (SI), "Study on Enhancements to Data Collection for NR and EN-DC," examines general high-level principles, an artificial intelligence (AI) / machine learning (ML) functional framework, potential use cases, and potential solutions identified for these use cases. The results of the study on AI-enabled RAN are documented in 3GPP TR 37.817 v17.0.0. Standardization work based on the conclusions of the Rel-17 SI is currently underway in 3GPP Rel-18. Related work items (WIs) are described in RP-213602.

[0033] The functional framework of AI / ML in RAN obtained in 3GPP TR 37.817v17.0.0 is Figure 3 The functional framework states that the model training function is a function that performs AI / ML model training, validation, and testing and can generate model performance metrics as part of the model testing process, while the model inference function is a function that provides AI / ML model inference output (e.g., prediction or decision).

[0034] 3GPP TR 37.817v17.0.0 Section 5.3.2.5 describes that AI / ML-based mobility optimization can generate UE trajectory predictions (latitude, longitude, altitude, cell ID of the UE in the future time period) as output and other information, with the following note: Whether the UE trajectory prediction is an external output to the node hosting the model inference function should be discussed during the standardization work phase.

[0035] Various participants in the standardization workstream discussed the need to transmit predicted UE trajectories over the Xn interface. Some participants suggested that this predicted trajectory information, along with other information, could help the NG-RAN node select a more appropriate target cell for handovers. UE trajectory predictions are an important output for mobility optimization use cases and can help the target NG-RAN node make further predictions about UE trajectories and UE handover decisions. Because the predicted UE trajectory can include the location or cell of residence and the corresponding time interval, it can later be compared with the actual UE trajectory for performance evaluation purposes of an AI / ML model.

[0036] Participants also discussed the feasibility of transmitting UE trajectory predictions, which depends on how the information is encoded. If the information is encoded as a prediction of the cells the UE will pass through, transmission might be reasonable. However, if the information should provide the predicted geographic location of the UE in real time, this becomes complex, sensitive, and requires the radio access network (RAN) to be able to geolocate the UE.

[0037] Participants also discussed that delivering predicted trajectories during handovers could be useful. For example, beam-level predictions could be used to configure the target beam. The predicted UE trajectory could be transmitted via the Xn interface to benefit the target NG-RAN node in performing subsequent network optimization. The definition of the predicted UE trajectory could include the UE serving cell where it will camp, or the predicted UE geographic location.

[0038] Cell-based, beam-based (e.g., for FR2), and UE geolocation can all be considered, as the usefulness and feasibility of information at different granularities depends on the use cases, frequency layers, and time scales involved, so there is a tradeoff between options in terms of accuracy and simplicity.

[0039] The cell-based UE trajectory prediction has the same structure as the UE History Information IE. The cell-based UE trajectory prediction is provided as a list of future cells, each of which is indicated along with the expected time to stay in the cell. The cell-based UE trajectory prediction is transmitted via existing handover (HO) signaling messages.

[0040] Certain challenges currently exist. For example, UE trajectory prediction information is sent from the source node of a mobility event (e.g., the source RAN node of a handover, or a PSCell change) to the target node of a mobility event. For example, when an Xn-based handover is completed, the UE connects to the target gNB, and the target gNB sends an XnAP UE Context Release message to the source gNB to indicate to the source gNB that it is permitted to release resources associated with the UE (including the UE context of the UE that was just handed over). After releasing the UE context of such a UE, the UE for which the UE trajectory prediction information was transmitted is no longer known at the source gNB. Therefore, if the source gNB (i.e., the old serving gNB before the handover) wants to receive feedback from the target gNB (i.e., the new serving gNB after the handover) related to the UE trajectory prediction information previously sent to the target gNB, the source gNB will no longer be able to associate the feedback with the UE, and therefore with the trajectory prediction performed for the UE. In other words, the source node cannot verify whether the information included in the UE trajectory prediction information is accurate and to what extent.

[0041] Similar limitations exist for the mobility of a UE in the RRC_INACTIVE state. When the UE attempts to resume to a new target network node that does not host the UE context for the UE, the target network node attempts to retrieve the UE context from the old anchor node (or source network node) that stored the UE context (e.g., via the XnAP Retrieve UE Context procedure). The anchor network node sends the UE context to the target node, and along with (or as part of) the UE context, it may also send the UE trajectory prediction information for the UE. Once the UE context is relocated to the target network node, the source (anchor) node releases the UE context. Therefore, the same limitations indicated above exist, where the old anchor node will not be able to verify whether and to what extent the predictions included in the UE trajectory prediction information are accurate.

[0042] Another problem with the existing technology is that the UE trajectory prediction can include a list of several future cells to which the UE will connect, and the source gNB should receive feedback not only from the immediately next cell, but also from several future cells. For example, suppose a UE is handing over from gNB1 to gNB2, and gNB1 signals UE trajectory predictions for three future cells: cell 1, cell 2, and cell 3, where cell 1 comes from gNB2 and the others come from gNB3. However, after connecting to cell 1, the UE moves not in the direction of cell 2, but towards cell 4 from gNB4. During the handover from gNB2 to gNB4, gNB2 sends a new UE trajectory prediction to gNB4. Because the original UE trajectory prediction from gNB1 is no longer available to gNB4, gNB4 is unaware that it needs to signal the true UE trajectory to gNB1. Without feedback from gNB4, gNB1 cannot improve its prediction of the UE trajectory more than one step ahead in time.

[0043] Another problem is that a UE trajectory prediction may include assuming that the UE will move through several future cells, which are served by many different RAN nodes. While the prediction can be passed from the serving node to the target node during mobility, it may not be possible to identify the RAN node that originated the prediction. That is, if a RAN node generates feedback consisting of measured UE trajectories (in terms of visited cells), the RAN node cannot identify the RAN node to which such feedback should be signaled. Therefore, it is impossible for the node that originated the prediction to use the feedback to check how accurate the prediction is, or to determine whether the model / algorithm used to derive the prediction should, for example, be updated, retrained, discarded (and not used), or replaced. Summary of the Invention

[0044] As described above, there are currently certain challenges with respect to feedback on predicted user equipment (UE) trajectories. Certain aspects of the present disclosure and embodiments thereof may provide solutions to these or other challenges. For example, in certain embodiments, a source node of a mobility event (e.g., a source node of a handover or PSCell add / PSCell change, or an anchor node in the event of an attempt to recover from RRC_INACTIVE) is enabled to receive feedback related to UE trajectory prediction information and use it to verify whether and to what extent the predictions included in the UE trajectory prediction information are accurate, and such feedback may be used to train (or retrain) (one or more) AI / ML models and (one or more) algorithms, or generally improve any type of algorithm used to generate UE trajectory prediction information. In some cases, the source node may instruct the recipient of the UE trajectory information to provide feedback information to a third node.

[0045] In general, certain embodiments include feedback assistance information sent by the node performing UE trajectory prediction. The assistance information is sent along with the UE trajectory prediction. Some embodiments include feedback requests made by the node performing UE trajectory prediction. Some embodiments include receiving the feedback itself and how it is sent to the node requesting it or another node.

[0046] According to some embodiments, a method performed by a first network node includes obtaining a user equipment (UE) trajectory prediction, and transmitting the UE trajectory prediction and an indication requesting feedback regarding the UE trajectory prediction to a second network node. The indication requesting feedback includes assistance information for associating an identifier with the requested feedback. The method also includes receiving feedback regarding the UE trajectory prediction from a third network node based on the transmitted assistance information.

[0047] In certain embodiments, the second network node and the third network node are the same network node (eg, a RAN node).In certain embodiments, the second network node may be a RAN node, and the third network node may be, for example, an OAM node.

[0048] In certain embodiments, the assistance information included in the indication transmitted to the second network node requesting feedback regarding the UE trajectory prediction includes an identifier for associating the requested feedback with the UE trajectory prediction. For example, the identifier may include a feedback identifier and / or an identifier of the UE.

[0049] In certain embodiments, the received feedback includes an identifier for associating the requested feedback with the UE trajectory prediction.

[0050] In a particular embodiment, the assistance information included in the indication transmitted to the second network node requesting feedback regarding the UE trajectory prediction includes an identifier of the network node for receiving the feedback.

[0051] In certain embodiments, receiving feedback includes receiving artificial intelligence / machine learning assisted data update messages.

[0052] In a particular embodiment, the assistance information included in the indication requesting feedback regarding the UE trajectory prediction transmitted to the second network node includes an indication requesting feedback after a threshold number of handovers.

[0053] In certain embodiments, the received feedback includes a UE trajectory cell list and / or a dwell time for each cell in the UE trajectory cell list.

[0054] In certain embodiments, the method further includes training an artificial intelligence or machine learning model with the received feedback.

[0055] According to some embodiments, a method performed by a second network node includes receiving a UE trajectory prediction and an indication requesting feedback regarding the UE trajectory prediction. The indication requesting feedback includes assistance information for associating an identifier with the requested feedback. The method also includes transmitting feedback regarding the UE trajectory prediction to a first network node based on the assistance information.

[0056] In particular embodiments, the first network node comprises a Radio Access Network (RAN) node or an Operation and Management (OAM) node.

[0057] In a particular embodiment, the assistance information included in the indication received from the first network node requesting feedback regarding the UE trajectory prediction includes an identifier for associating the requested feedback with the UE trajectory prediction. The identifier may include an identifier of the UE.

[0058] In certain embodiments, the transmitted feedback includes an identifier for associating the requested feedback with the UE trajectory prediction.

[0059] In a particular embodiment, the assistance information included in the indication received from the first network node requesting feedback regarding the UE trajectory prediction includes an identifier of the network node for transmitting the feedback.

[0060] In certain embodiments, transmitting feedback includes transmitting artificial intelligence / machine learning assisted data update messages.

[0061] In a particular embodiment, the assistance information included in the indication received from the first network node requesting feedback regarding the UE trajectory prediction includes an indication requesting feedback after a threshold number of handovers.

[0062] In certain embodiments, the transmitted feedback includes the UE trajectory cell list and / or the dwell time of each cell in the UE trajectory cell list.

[0063] According to some embodiments, a network node comprises processing circuitry operable to perform any of the methods of the network node described above.

[0064] Also disclosed is a computer program product comprising a non-transitory computer readable medium storing computer readable program code, which when executed by a processing circuit is operable to perform any of the methods performed by the network node described above.

[0065] Certain embodiments may provide one or more of the following technical advantages. For example, certain embodiments enable a network node performing UE trajectory prediction to request feedback information from other network nodes involved in the UE trajectory (e.g., the network node to which the UE is handed over). Some embodiments enable a network node sending feedback information to identify the network node performing UE trajectory prediction to send feedback directly to it or via other network nodes. The auxiliary information included in the feedback information enables the network node performing UE trajectory prediction to link it to the UE trajectory prediction without having to store the UE context for too long.

[0066] Some embodiments verify whether and how accurate the predictions included in the UE trajectory prediction information are, and may use such feedback to train (or retrain) AI / ML model(s) and algorithm(s), or generally improve any type of algorithm used to generate the UE trajectory prediction information. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which: Figure 1 is a block diagram illustrating the NG-RAN architecture; Figure 2 is a block diagram illustrating an architecture for separation of gNB-CU-CP and gNB-CU-UP; Figure 3 is a block diagram illustrating the functional framework of AI / ML in RAN obtained in 3GPP TR 37.817 v17.0.0; Figure 4 is a block diagram illustrating an example wireless network; Figure 5 shows an example user device according to certain embodiments; Figure 6 shows an example virtualized environment according to certain embodiments; Figure 7 illustrates an example telecommunications network connected to a host computer via an intermediary network in accordance with certain embodiments; Figure 8 shows an example host computer communicating with a user device over a partially wireless connection via a base station in accordance with certain embodiments; Figure 9 is a flow chart illustrating a method implemented according to certain embodiments; Figure 10 is a flow chart illustrating a method implemented in a communication system according to certain embodiments; Figure 11 is a flow chart illustrating a method implemented in a communication system according to certain embodiments; Figure 12 is a flow chart illustrating a method implemented in a communication system according to certain embodiments; Figure 13A is a flow chart illustrating a method performed by a wireless device according to certain embodiments; Figure 13B is a flow chart illustrating a method performed by a first network node according to certain embodiments; Figure 13C is a flow chart illustrating a method performed by a second network node according to certain embodiments; Figure 14 is a flow chart illustrating another method performed by a first network node according to certain embodiments; and Figure 15 is a flow chart illustrating another method performed by a second network node according to certain embodiments. DETAILED DESCRIPTION

[0068] Certain embodiments are described with respect to a network node. The network node may be a radio access network (RAN) node, an operations and management (OAM) node, a core network (CN) node, a service management and coordination (SMO) node, a network management system (NMS), a non-real-time RAN intelligent controller (non-RT RIC), a real-time RAN intelligent controller (RT-RIC), a gNB, an eNB, an en-gNB, an ng-eNB, a gNB-CU, a gNB-CU-CP, a gNB-CU-UP, a gNB-DU, an eNB-CU, an eNB-CU-CP, an eNB-CU-UP, an eNB-DU, an integrated access and backhaul (IAB) node, an IAB-donor DU, an IAB-donor CU, an IAB-DU, an IAB-MT, an O-CU, an O-CU-CP, an O-CU-UP, an O-DU, an O-RU, an O-eNB, a cloud-based network function, and / or a cloud-based centralized training node.

[0069] In a specific embodiment, a first network node (source network node) determines user equipment (UE) trajectory prediction information including a cell list and / or a reference signal beam list (such as a synchronization signal block (SSB) reference signal), for example, as one of the outputs of an artificial intelligence (AI) / machine learning (ML) model, and sends the UE trajectory prediction information to one or more other network nodes (target network nodes). Associated with the cell list and / or reference signal list, the UE trajectory prediction information may also include an indication of the network node identity to which the cell or reference signal belongs.

[0070] According to certain embodiments, as part of or together with the UE trajectory prediction information, the source network node sends assistance information (described below) for providing feedback on the predicted UE trajectory to one or more target network nodes. Upon receiving feedback regarding the UE trajectory information from (one or more) other target network nodes, the source network node may improve future determinations of the UE trajectory prediction information (e.g., for other UEs having the same or similar radio measurements / services as the UE for which the UE trajectory prediction information was determined and for which feedback was received).

[0071] Optionally, depending on the type of mobility event, the source network node may send UE trajectory prediction information to only one target network node or to multiple target network nodes. In one example, the predicted UE trajectory may involve cells and / or reference signal coverage areas (such as SSB coverage areas) of different neighboring network nodes. Therefore, in this example, the source node may transmit UE trajectory prediction information to all nodes involved in the predicted UE trajectory. The same principle applies to conditional handover, where the source network node sends UE trajectory prediction to one or more target network node candidates.

[0072] The source network node may send UE trajectory prediction information to a target network node for any of the following situations: a handover that is not a conditional handover (i.e., in the case of a "normal" handover, or in the case of a Dual Active Protocol Stack (DAPS) handover), ·PSCell addition that is not conditional PSCell addition, A PSCell change that is not a conditional PSCell change, and / or · Response to UE context retrieval request.

[0073] In one example, the source network node may transmit the UE trajectory prediction information by adding a cause value for transmitting such information. The cause value may indicate the reason for transmitting the UE trajectory prediction information, such as predicted or planned handover, PSCell addition, PSCell change, etc.

[0074] The source network node may send UE trajectory prediction information to more than one (candidate) target network node for any of the following situations: As a conditional switch, or · added as a conditional PSCell, or PSCell changes as conditional PSCell changes

[0075] The source network node may send different UE trajectory prediction information to different (candidate) target network nodes, or the source network node may send different UE trajectory prediction information to the same target network node.

[0076] For example, for a T-junction in which a moving UE is in cell A, if the UE turns right, the UE will go to cell B, and if the UE turns left, the UE will go to cell C. In that case, the source network node may know that the UE will later go to cell D (if it went to cell B) or to cell E (if it went to cell C), so there are two possible UE trajectory predictions: 1) "cell A, (then) cell B, (then) cell D" (trajectory 1); 2) "cell A, (then) cell C, (then) cell E" (trajectory 2).

[0077] The source network node can send UE trajectory prediction information with a weighting factor, which indicates the probability that the UE will be in one or more cells or reference signal coverage areas in the cells indicated by the UE trajectory information. Especially in the case of conditional handover (which depends on the cell that will be the next hop), this means which candidate cell will be the actual target cell and the corresponding next hop, resulting in different cell sequences. In one example, the source node in conditional handover sends one UE trajectory prediction information to each target node, but with the weights of the candidate target cells. In another example, the source node sends different UE trajectory prediction information with different cell sequences to each candidate target cell. In that case, the source node can assign different priorities to different sequences, which indicate the probability of each sequence occurring.

[0078] In some embodiments, the source network node is a RAN node and sends UE trajectory prediction information to one or more other target network nodes that are also RAN nodes. The target network node(s) may send feedback regarding the UE trajectory prediction information to a third network node that is not a RAN node, such as an OAM node / function or a CN node / function. In this option, the training process for the AI / ML model used to infer the UE trajectory prediction information may be deployed at the OAM.

[0079] In one example, the source node may request feedback information related to the provided predicted UE trajectory information from the target node as part of the signaling of the predicted UE trajectory information, and may optionally indicate whether the requested feedback information should be provided to the source node or to a third network node (e.g., an OAM node or a CN node / function). In order to implement the functionality that feedback on the predicted UE trajectory can be provided to one or more nodes indicated by the source network node, the source node provides auxiliary information for feedback on the predicted UE trajectory. Such information may include any one or more of the following: - An identifier of the prediction, such as a prediction ID or an AI / ML model ID, associated with a process (e.g., an AI / ML model or prediction process) used to generate at least part of the information included in the UE trajectory prediction information. - An identifier of the requested feedback, such as a feedback ID, to identify feedback associated with UE trajectory prediction information, or to identify feedback associated with a piece of information (e.g., the output of an AI / ML model) including UE trajectory prediction information, the source network node requests / expects the target network node to return the UE trajectory prediction information in a message to the source network node, wherein such a message carries the same identifier (or a new identifier derived from the feedback ID) and feedback on the UE trajectory prediction information. - The request for feedback information may contain the number of network nodes that the UE needs to hand over to before sending feedback information (eg, feedback information may be sent after the first hop, the third hop, the last hop, or any combination of these). - an identifier of a pattern, such as a pattern ID identifying or associated with at least a portion of the UE trajectory prediction information, such as any combination of the following options: All cells in the cell list included in the UE trajectory prediction information All the reference signal beam lists included in the UE trajectory prediction information Reference signal beam o A non-repeated combination of at least part of the cells in the cell list included in the UE trajectory prediction information o A non-repeated combination of at least part of the reference signal beams in the reference signal beam list included in the UE trajectory prediction information o A non-repeating combination of at least part of the cells and / or reference signal beams in the list(s) of cells and / or reference signal beams included in the UE trajectory prediction information o A value generated by a one-way or two-way hash function that uses any of the above specified values as input o The predicted residence time in one or more cells in the cell list included in the UE trajectory prediction information. o The predicted dwell time in one or more reference signal beams in the reference signal beam list included in the UE trajectory prediction information. - An identifier of the UE or an identifier of a group of UEs, such as a RAN UE ID, identifying the UE in a semi-permanent manner across multiple network nodes, including the first network node and one or more target network nodes. -The number of cells and / or reference signal beams included in the UE trajectory prediction information. - an identifier associated with the cell and / or reference signal beam included in the UE trajectory prediction information. - an indication or identifier of the network node to which the cell or reference signal beam indicated in the UE trajectory prediction is associated. - An indication that all or part of the assistance information used for feedback on the predicted UE trajectory should be forwarded in subsequent mobility events. o An optional indication of how long the information should be forwarded may also be included. For example, the indication may be related to the number of hops (e.g., the number of cells and / or reference signal beams and / or network nodes to which the UE is connected) or the amount of time (e.g., as the sum of the total dwell time in the cells and / or reference signal beams and / or network nodes, a time interval, or a future expiration timestamp). Upon receiving this indication, the RAN node decides whether it will send feedback to the previous node and / or the source node. - an identifier indicating where the feedback should be sent, eg back to the first network node or to another network node (eg another RAN node or an OAM node / function or a CN node / function). -For each cell entry in the UE trajectory prediction, an identifier that uniquely identifies the network node that performs the UE trajectory prediction for that entry An indication of the nodes that need to be signaled as feedback for the embedded indication in the list of cells that make up the predicted UE trajectory. That is, if the predicted UE trajectory consists of cell 1, cell 2, cell 3, cell 4, the additional assistance information can associate an indication (e.g., a feedback reception flag) with one of these cells, which will let the future target node know that the predicted UE trajectory will have to be sent to the node serving such a cell. As an example, the enhanced predicted UE trajectory may consist of: cell 1, cell 2 + feedback reception flag, cell 3, cell 4. - An indication of the node from which the UE trajectory feedback will be sent. Similar to the above embodiment, such an indication can be provided explicitly as a node or cell identifier indicating the node from which the trajectory feedback should be sent, or as an indication associated with one of the cells in the trajectory prediction. Such an indication can be referred to as a feedback signaling flag.

[0080] The auxiliary information used for feedback on the predicted UE trajectory can be related to the complete predicted UE trajectory (i.e., all entries / cells), or can be related to only one entry / cell (i.e., attached to one cell / entry). In the latter case, only some (or all) of the entries can have attached auxiliary information for feedback.

[0081] The source network node may request to receive one or more of the auxiliary identifiers described above from the target network node(s) as feedback regarding the predicted UE trajectory.

[0082] In some embodiments, sending one or more of the aforementioned identifiers corresponds to an implicit request by the source network node to the target network node to provide such identifier(s) in a return message toward the source network node. The return message may be implemented as a message included in the same process that includes the UE trajectory prediction information and / or the aforementioned identifier(s), or as a message not included in the same process that includes the UE trajectory prediction information and / or the aforementioned identifier(s).

[0083] In one embodiment, after making a prediction, the UE trajectory prediction can be updated by the target node serving the UE. As an example, network node 1 can predict a trajectory consisting of cells 1, 2, 3, and 4. However, when the UE moves to network node 2 serving cell 2, network node 2 can modify the predictions for cells 1, 2, 5, and 6. In this case, network node 2 will add a message containing the new UE trajectory prediction information, indicating that the UE trajectory feedback also needs to be signaled back to network node 2.

[0084] In one embodiment, such information added by the network node 2 may be in the form of adding a feedback reception flag to any of the predicted cells whose hosting node should receive the predicted feedback.

[0085] As a non-limiting example, the assistance information is included in a (previous) XnAP Handover Request message, and the return message is a response message (e.g., an XnAP UE Context Release message for closing the handover process). As another example, the return message may be a notification message, such as an XnAP Access and Mobility Indication message, an XnAP Handover Success message, or an XnAP Handover Report message. In another example, the return message may be an AI / ML Assistance Data Update message.

[0086] In some embodiments, an explicit request for feedback is sent along with the auxiliary information. The explicit request for feedback can be any of the following: - An indication of the need to receive feedback from a neighbor network node or from a neighbor network node's neighbors (second level or second layer neighbors) or up to nth level neighbors. - An indication of the need to receive feedback for the cell of the neighbor network node and / or for the cells of the neighbors of the neighbor network node (second level or second layer neighbors) or up to the nth level neighbors. - An indication of the need to receive feedback for the reference signal beam of a neighbor network node and / or for the reference signal beams of the neighbor network node's neighbors (second level or second layer neighbors) or up to nth level neighbors. - An indication that feedback is required after the nth handover. - An indication that feedback is required if the UE trajectory prediction is different from the actual UE trajectory (e.g. recorded in the UHI or MHI).

[0087] The source network node may implicitly or explicitly request the target network node(s) to provide feedback on the predicted UE trajectory in the same message (to one or more target network nodes) that carries the UE trajectory prediction information, or using a different message. Such a request may be sent in conjunction with or in lieu of a request to obtain one or more of the identifiers listed above.

[0088] The requested feedback may be to obtain a list of UE trajectory cells, i.e., to obtain a list indicating which cells in the cell list included in the UE trajectory prediction information have been visited by the UE in its trajectory, and optionally other characteristics or performance associated with those cells (e.g., the dwell time of each cell, the time the UE spends in a certain radio resource control (RRC) state and camped on the cell or served by the cell, the performance of the handed-over UE in the target cell). The list may be sorted using a time criterion, for example, the first entry in the list corresponds to the cell most recently visited by the UE, the second entry in the list corresponds to the cell second most recently visited by the UE, and so on.

[0089] In some embodiments, the UE trajectory cell list can be represented as a list of values, where the position in the list represents the cell of the UE trajectory prediction information that the UE actually visited. In some embodiments, the UE trajectory cell list can be represented as a list of values, where the position in the list represents the cell of the UE trajectory prediction information, and the value in that position indicates the UE's residence time in that cell. A zero residence time indicates that the cell indicated by the corresponding position in the list was not visited by the UE.

[0090] In some embodiments, the UE trajectory cell list can be represented as a bitmap, where the positions in the bitmap represent cells in the UE trajectory prediction information, and a bit set to 1 in a certain position indicates that the UE has visited the cell corresponding to the position, and a value of 0 indicates that the UE has not yet visited the corresponding cell.

[0091] In some embodiments, the UE trajectory cell list can be represented as a sequence list, where the position in the list represents the cell in the UE trajectory prediction information, and the sequence in the position is the reference signal beam list of the cell visited by the UE.

[0092] In some embodiments, the UE trajectory cell list can be represented as a sequence list, where the position in the list represents the cell in the UE trajectory prediction information, and the sequence in the position is a list of performance indicators of the UE in the cell. Performance can refer to throughput, delay, jitter, packet loss, etc.

[0093] In some embodiments, the list of cells visited by the UE is represented by the UE History Information (UHI) or Mobility History Information (MHI) of the UE, as received by the network node sending the feedback. The UHI and / or MHI is supplemented with auxiliary information for the feedback.

[0094] The requested feedback may be to obtain a list of UE trajectory reference signal beams, i.e., to obtain a list indicating which reference signal beams in the list of reference signal beams included in the UE trajectory prediction information have been visited by the UE in its trajectory, and optionally other characteristics or performance associated with those reference signal beams (e.g., the dwell time of each reference signal beam, the time spent in a certain RRC state when dwelling on a reference signal beam or being served by a reference signal beam).

[0095] The feedback requested may be a set of suggested changes to the model weights / parameters already used to make the prediction. In this case, the candidate target node(s) (in conjunction with a third node, such as an OAM system, or independently) may provide feedback on the suggested changes to the model parameters on the source node, rather than the results of the actual UE trajectory. Such feedback may be provided at the reference signal level and / or at the cell-level trajectory level.

[0096] In one option, when UE trajectory prediction information is sent to multiple candidate target network nodes, feedback on the predicted UE trajectory is sent to the source network node only by the candidate target network nodes involved in the actual execution of the mobility event.

[0097] In another option, when UE trajectory prediction information is sent to multiple candidate target network nodes, feedback about the predicted UE trajectory is sent to the source network node by multiple candidate target network nodes, i.e., not just by the candidate target network node involved in the actual execution of the mobility event. In this case, the feedback information may consist of another identifier that can be used to distinguish whether feedback has been received from a candidate target node involved in the mobility event.

[0098] In another option, when UE trajectory prediction information is sent to multiple candidate target network nodes, the candidate node that the UE will actually visit can send feedback. In one alternative, each candidate node visited by the UE can send feedback directly to the source node. In another alternative, each candidate node sends feedback to the previous hop node, and the feedback can then be collected and cascaded to the source node.

[0099] Upon receiving assistance information for feedback regarding a predicted vUE trajectory and / or a request (implicit or explicit) to send feedback regarding a predicted UE trajectory from a source network node, the target network node involved in the execution of the mobility event may send such feedback to the source network node using one or more messages.

[0100] The source network node receives feedback about the predicted UE trajectory and compares it with the predicted information (or forwards the feedback about the predicted UE trajectory to a third network node that performs the above comparison, such as a network node that implements the training function of the AI / ML model). For example, the comparison can be used to determine the accuracy of a certain pattern (e.g., a list of consecutive cells that the UE is expected to visit) and improve the UE trajectory prediction information for future mobility events. For example, the source network node may have sent several instances of UE trajectory prediction information containing a cell list "A, B, C" to the target network node, and received as return feedback multiple instances of the UE trajectory cell list indicating that the visited cell is "A, B, C", where the dwell time of cell "B" is very short. The source network node can then suggest to the target network node that the mobility trigger point be adjusted from B to C to delay the handover from B to C.

[0101] In another embodiment, upon receiving feedback suggesting changes to model parameters, the source network node may directly update the model with the suggestion, or derive new model parameter updates using feedback information or other input data received from other nodes during a certain time span.

[0102] In one embodiment, the RAN node requesting to receive UE trace feedback may not have a direct signaling connection with the target RAN node. In this case, the request for UE trace feedback can be signaled through the RAN to CN interface, and it can be forwarded by the CN to the appropriate target RAN node.

[0103] In one embodiment, the RAN node that signals the UE trace feedback to the source node may not have a direct signaling connection with the source RAN node. In this case, the UE trace feedback can be signaled via the RAN to CN interface and it can be forwarded by the CN to the appropriate source RAN node.

[0104] In this case, the assistance information included with the UE trajectory prediction indicating the receiving UE trajectory feedback may include a tracking area indication of the node to which the UE trajectory feedback should be signaled. With this information, the RAN node that should signal back the UE trajectory feedback can provide the CN with the information required to route the UE trajectory feedback to the appropriate source RAN node.

[0105] In one example of the embodiment described above, the UE trajectory prediction may be encoded as follows and signaled to the next serving RAN node via a message such as an Xn Handover Request message or an Xn Retrieve UE Context message.

[0106] The Cell Trajectory Prediction IE contains a list of predicted NR cells that the UE will move to after handover from the source NG-RAN node.

[0107] The predicted trajectory cell information includes the cell ID of the predicted cell used for trajectory prediction.

[0108] As can be seen from the examples above, one or more cells in the UE trajectory prediction may be marked with a flag indicating one or more of these options: -Nodes serving marked cells should send UE trajectory feedback - The node serving the marked cell is the node that should receive UE trajectory feedback

[0109] The cell global identifier includes the RAN node global identifier, so the RAN node receiving the trajectory prediction cell information can infer the RAN node to which the trajectory feedback needs to be sent.

[0110] In one example of the above embodiment, the UE trajectory feedback may be represented by UE history information, as defined for XnAP.

[0111] Figure 4An example wireless network according to certain embodiments is shown. The wireless network can include any type of communication, telecommunication, data, cellular and / or radio network or other similar type of system and / or can be connected to any type of communication, telecommunication, data, cellular and / or radio network or other similar type of system by an interface. In some embodiments, the wireless network can be configured to operate according to a specific standard or other type of predefined rules or procedures. Thus, specific embodiments of the wireless network can implement communication standards such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G or 5G standards; Wireless Local Area Network (WLAN) standards such as IEEE 802.2 standards; and / or any other suitable wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and / or ZigBee standards.

[0112] The network 106 may include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks that enable communication between devices.

[0113] The network node 160 and the WD 110 include various components described in more detail below. These components work together to provide network node and / or wireless device functionality, such as providing wireless connectivity in a wireless network. In various embodiments, a wireless network may include any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that may facilitate or participate in the transfer of data and / or signals, whether via a wired connection or via a wireless connection.

[0114] As used herein, a network node refers to a device capable of, configured to, arranged to, and / or operable to communicate, directly or indirectly, with a wireless device and / or with other network nodes or devices in a wireless network to enable and / or provide wireless access to the wireless device and / or to perform other functions (e.g., management) in the wireless network.

[0115] Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs). Base stations may be categorized based on the amount of coverage they provide (or, in other words, their transmit power level) and may also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations.

[0116] The base station may be a relay node or a relay donor node that controls the relay. The network node may also include one or more (or all) parts of a distributed radio base station such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio device. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Still other examples of network nodes include multi-standard radio (MSR) equipment such as an MSR BS, a network controller such as a radio network controller (RNC) or a base station controller (BSC), a base transceiver station (BTS), a transmission point, a transmission node, a multi-cell / multicast coordination entity (MCE), a core network node (e.g., MSC, MME), an O&M node, an OSS node, a SON node, a positioning node (e.g., E-SMLC), and / or an MDT.

[0117] As another example, a network node may be a virtual network node as described in more detail below. However, more generally, a network node may represent any suitable device (or group of devices) that is capable of, configured to, arranged to, and / or operable to enable and / or provide wireless devices with access to a wireless network or to provide some services to wireless devices that have accessed a wireless network.

[0118] exist Figure 4 In FIG, the network node 160 includes a processing circuit 170, a device readable medium 180, an interface 190, an auxiliary device 184, a power supply 186, a power circuit 187, and an antenna 162. Figure 4 The network node 160 shown in the example wireless network of FIG. 1 may represent an apparatus including the shown combination of hardware components, but other embodiments may include network nodes having different combinations of components.

[0119] It is understood that the network node includes any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. In addition, although the components of the network node 160 are depicted as a single box within a larger box or nested within multiple boxes, in reality, the network node may include multiple different physical components that make up the single illustrated component (e.g., the device readable medium 180 may include multiple separate hard drives and multiple RAM modules).

[0120] Similarly, network node 160 may be composed of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own corresponding components. In certain scenarios where network node 160 includes multiple separate components (e.g., a BTS component and a BSC component), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may, in some instances, be considered a single independent network node.

[0121] In some embodiments, the network node 160 can be configured to support multiple radio access technologies (RATs). In such embodiments, some components can be replicated (e.g., separate device-readable media 180 for different RATs) and some components can be reused (e.g., the same antenna 162 can be shared by the RATs). The network node 160 can also include multiple sets of various illustrated components for different wireless technologies integrated into the network node 160, such as, for example, GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies. These wireless technologies can be integrated into the same or different chips or chipsets and other components within the network node 160.

[0122] The processing circuitry 170 is configured to perform any determinations, calculations, or similar operations described herein as being provided by the network node (e.g., certain obtaining operations). These operations performed by the processing circuitry 170 may include processing information obtained by the processing circuitry 170 by, for example, converting the obtained information into other information, comparing the obtained information or the converted information with information stored in the network node, and / or performing one or more operations based on the obtained information or the converted information, and making a determination as a result of the processing.

[0123] The processing circuitry 170 may include one or more of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or encoded logic operable to provide network node 160 functionality, either alone or in combination with other network node 160 components, such as device-readable medium 180.

[0124] For example, processing circuit 170 may execute instructions stored in device-readable medium 180 or stored in memory within processing circuit 170. Such functionality may include providing any of the various wireless features, functions, or benefits discussed herein. In some embodiments, processing circuit 170 may include a system on a chip (SOC).

[0125] In some embodiments, processing circuitry 170 may include one or more of radio frequency (RF) transceiver circuitry 172 and baseband processing circuitry 174. In some embodiments, radio frequency (RF) transceiver circuitry 172 and baseband processing circuitry 174 may be on separate chips (or chipsets), boards, or units such as a radio unit and a digital unit. In alternative embodiments, some or all of RF transceiver circuitry 172 and baseband processing circuitry 174 may be on the same chip or chipset, board, or unit.

[0126] In certain embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB, or other such network device may be performed by processing circuitry 170 executing instructions stored on a device-readable medium 180 or memory within processing circuitry 170. In alternative embodiments, some or all of the functionality may be provided by processing circuitry 170 without executing instructions stored on a separate or discrete device-readable medium, such as in a hardwired manner. In any of those embodiments, processing circuitry 170 may be configured to perform the described functionality regardless of whether instructions stored on a device-readable storage medium are executed. The benefits provided by such functionality are not limited to processing circuitry 170 alone or to other components of network node 160, but are generally enjoyed by network node 160 as a whole and / or by end users and the wireless network.

[0127] Device-readable medium 180 may include any form of volatile or non-volatile computer-readable memory, including, without limitation, permanent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., a hard disk), removable storage media (e.g., a flash drive, a compact disk (CD), or a digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuit 170. Device-readable medium 180 may store any suitable instructions, data, or information, including applications, software, computer programs, and / or other instructions that include one or more of logic, rules, code, tables, and / or the like that can be executed by processing circuit 170 and utilized by network node 160. Device-readable medium 180 may be used to store any computations performed by processing circuit 170 and / or any data received via interface 190. In some embodiments, processing circuit 170 and device-readable medium 180 may be considered integrated.

[0128] Interface 190 is used in the wired or wireless transfer of signaling and / or data between network node 160, network 106, and / or WD 110. As shown, interface 190 includes port(s) / terminal(s) 194 used to send data to network 106, for example, via a wired connection, and to receive data from network 106. Interface 190 also includes radio front-end circuitry 192 that may be coupled to antenna 162 or, in some embodiments, may be part of antenna 162.

[0129] The radio front-end circuit 192 includes a filter 198 and an amplifier 196. The radio front-end circuit 192 can be connected to the antenna 162 and the processing circuit 170. The radio front-end circuit 192 can be configured to condition the signals transmitted between the antenna 162 and the processing circuit 170. The radio front-end circuit 192 can receive digital data to be transmitted to other network nodes or WDs via a wireless connection. The radio front-end circuit 192 can use a combination of the filter 198 and / or the amplifier 196 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal can then be transmitted via the antenna 162. Similarly, when data is received, the antenna 162 can collect the radio signal, which is then converted into digital data by the radio front-end circuit 192. The digital data can then be transmitted to the processing circuit 170. In other embodiments, the interface may include different components and / or different combinations of components.

[0130] In certain alternative embodiments, the network node 160 may not include a separate radio front end circuitry 192; instead, the processing circuitry 170 may include the radio front end circuitry and may be connected to the antenna 162 without the separate radio front end circuitry 192. Similarly, in some embodiments, all or some of the RF transceiver circuitry 172 may be considered part of the interface 190. In still other embodiments, the interface 190 may include one or more ports or terminals 194, the radio front end circuitry 192, and the RF transceiver circuitry 172 as part of a radio unit (not shown), and the interface 190 may communicate with the baseband processing circuitry 174, which is part of a digital unit (not shown).

[0131] Antenna 162 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals. Antenna 162 may be coupled to radio front-end circuitry 192 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 162 may include one or more omnidirectional, sectored, or flat panel antennas operable to transmit / receive radio signals between, for example, 2 GHz and 66 GHz. Omnidirectional antennas may be used to transmit / receive radio signals in any direction, sectored antennas may be used to transmit / receive radio signals from devices within a specific area, and flat panel antennas may be line of sight antennas for transmitting / receiving radio signals on a relatively straight line. In some instances, the use of more than one antenna may be referred to as MIMO. In certain embodiments, antenna 162 may be separate from network node 160 and may be connectable to network node 160 via an interface or port.

[0132] Antenna 162, interface 190 and / or processing circuit 170 can be configured to perform any receiving operation and / or certain obtaining operations described herein as being performed by a network node. Any information, data and / or signal can be received from a wireless device, another network node and / or any other network equipment. Similarly, antenna 162, interface 190 and / or processing circuit 170 can be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data and / or signal can be transmitted to a wireless device, another network node and / or any other network equipment.

[0133] Power circuit 187 may include or be coupled to power management circuitry and is configured to provide power to the components of network node 160 for performing the functionality described herein. Power circuit 187 may receive power from power source 186. Power source 186 and / or power circuit 187 may be configured to provide power to the various components of network node 160 in a form suitable for the respective components (e.g., at the voltage and current levels required by each respective component). Power source 186 may be either included in power circuit 187 and / or network node 160 or external to power circuit 187 and / or network node 160.

[0134] For example, network node 160 may be connectable to an external power source (e.g., an electrical outlet) via an input circuit or interface such as a cable, whereby the external power source supplies power to power circuit 187. As another example, power source 186 may include a power source in the form of a battery or battery pack that is connected to or integrated into power circuit 187. If the external power source fails, the battery can provide backup power. Other types of power sources, such as photovoltaic devices, may also be used.

[0135] Alternative embodiments of network node 160 may include Figure 4 , which may be responsible for providing certain aspects of the functionality of the network node, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 160 may include a user interface device to allow information to be entered into the network node 160 and to allow information to be output from the network node 160. This may allow a user to perform diagnostics, maintenance, repair, and other management functions on the network node 160.

[0136] As used herein, a wireless device (WD) refers to a device capable of, configured to, arranged to, and / or operable to wirelessly communicate with a network node and / or other wireless devices. Unless otherwise specified, the term WD may be used interchangeably herein with user equipment (UE). Wireless communication may involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information through the air.

[0137] In some embodiments, a WD may be configured to transmit and / or receive information without direct human interaction. For example, a WD may be designed to transmit information to a network on a predetermined schedule when triggered by an internal or external event or in response to a request from the network.

[0138] Examples of WDs include, but are not limited to, smartphones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded equipment (LEEs), laptop mounted equipment (LMEs), smart devices, wireless customer premises equipment (CPEs), vehicle-mounted wireless terminal devices, etc. WDs may support device-to-device (D2D) communication, for example, by implementing 3GPP standards for direct link communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X), and in this case may be referred to as D2D communication devices.

[0139] As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another WD and / or a network node. In this case, the WD may be a machine-to-machine (M2M) device, which may be referred to as an MTC device in the 3GPP context. As a specific example, the WD may be a UE that implements the 3GPP Narrowband Internet of Things (NB-IoT) standard. Examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or household or personal appliances (e.g., refrigerators, televisions, etc.), personal wearable devices (e.g., watches, fitness trackers, etc.).

[0140] In other scenarios, a WD may represent a vehicle or other device capable of monitoring and / or reporting its operating status or other functions associated with its operation. As described above, a WD may represent an endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, as described above, a WD may be mobile, in which case it may also be referred to as a mobile device or mobile terminal.

[0141] As shown, wireless device 110 includes antenna 111, interface 114, processing circuit 120, device-readable medium 130, user interface device 132, auxiliary device 134, power supply 136, and power circuit 137. WD 110 may include multiple sets of one or more of the components shown for different wireless technologies supported by WD 110, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, to name a few. These wireless technologies may be integrated into the same or different chips or chipsets as other components within WD 110.

[0142] Antenna 111 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals and is connected to interface 114. In certain alternative embodiments, antenna 111 may be separated from WD 110 and may be connected to WD 110 via an interface or port. Antenna 111, interface 114 and / or processing circuit 120 may be configured to perform any receiving or transmitting operation described herein as being performed by a WD. Any information, data and / or signal may be received from a network node and / or another WD. In some embodiments, the radio front-end circuit and / or antenna 111 may be considered an interface.

[0143] As shown, interface 114 includes radio front-end circuitry 112 and antenna 111. Radio front-end circuitry 112 includes one or more filters 118 and amplifier 116. Radio front-end circuitry 112 is connected to antenna 111 and processing circuitry 120 and is configured to condition signals passed between antenna 111 and processing circuitry 120. Radio front-end circuitry 112 may be coupled to antenna 111 or may be part of antenna 111. In some embodiments, WD 110 may not include a separate radio front-end circuitry 112; instead, processing circuitry 120 may include the radio front-end circuitry and may be connected to antenna 111. Similarly, in some embodiments, some or all of RF transceiver circuitry 122 may be considered part of interface 114.

[0144] The radio front-end circuit 112 can receive digital data to be transmitted to other network nodes or WDs via a wireless connection. The radio front-end circuit 112 can use a combination of filters 118 and / or amplifiers 116 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal can then be transmitted via the antenna 111. Similarly, when data is received, the antenna 111 can collect the radio signal, which is then converted into digital data by the radio front-end circuit 112. The digital data can be passed to the processing circuit 120. In other embodiments, the interface may include different components and / or different combinations of components.

[0145] The processing circuitry 120 may include one or more of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or encoded logic operable to provide WD 110 functionality, either alone or in combination with other WD 110 components such as the device-readable medium 130. Such functionality may include providing any of the various wireless features or benefits discussed herein. For example, the processing circuitry 120 may execute instructions stored in the device-readable medium 130 or in memory within the processing circuitry 120 to provide the functionality disclosed herein.

[0146] As shown, processing circuitry 120 includes one or more of RF transceiver circuitry 122, baseband processing circuitry 124, and application processing circuitry 126. In other embodiments, the processing circuitry may include different components and / or different combinations of components. In some embodiments, processing circuitry 120 of WD 110 may include an SOC. In some embodiments, RF transceiver circuitry 122, baseband processing circuitry 124, and application processing circuitry 126 may be on separate chips or chipsets.

[0147] In an alternative embodiment, part or all of the baseband processing circuitry 124 and the application processing circuitry 126 may be combined into one chip or chipset, and the RF transceiver circuitry 122 may be on a separate chip or chipset. In still other alternative embodiments, part or all of the RF transceiver circuitry 122 and the baseband processing circuitry 124 may be on the same chip or chipset, and the application processing circuitry 126 may be on a separate chip or chipset. In still other alternative embodiments, part or all of the RF transceiver circuitry 122, the baseband processing circuitry 124, and the application processing circuitry 126 may be combined into the same chip or chipset. In some embodiments, the RF transceiver circuitry 122 may be part of the interface 114. The RF transceiver circuitry 122 may condition RF signals for use with the processing circuitry 120.

[0148] In some embodiments, some or all of the functionality described herein as being performed by the WD may be provided by processing circuitry 120 executing instructions stored on device-readable medium 130, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by processing circuitry 120 without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner.

[0149] In any of those embodiments, processing circuitry 120 may be configured to perform the described functionality, whether or not executing instructions stored on a device-readable storage medium. The benefits provided by such functionality are not limited to just processing circuitry 120 or to other components of WD 110, but are generally enjoyed by WD 110 and / or by end users and wireless networks.

[0150] Processing circuitry 120 may be configured to perform any determinations, calculations, or similar operations described herein as being performed by the WD (e.g., certain acquisition operations). Such operations, as performed by processing circuitry 120, may include processing information obtained by processing circuitry 120 by, for example, converting the obtained information into other information, comparing the obtained information or the converted information with information stored by WD 110, and / or performing one or more operations based on the obtained information or the converted information, and making determinations as a result of the processing.

[0151] Device-readable medium 130 may be operable to store applications, software, computer programs, including one or more of logic, rules, code, tables, and / or other instructions that can be executed by processing circuitry 120. Device-readable medium 130 may include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., a compact disk (CD) or a digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuitry 120. In some embodiments, processing circuitry 120 and device-readable medium 130 may be integrated.

[0152] The user interface device 132 may provide a component that allows for a human user to interact with the WD 110. Such interaction may be in a variety of forms, such as visual, auditory, tactile, and the like. The user interface device 132 may be operable to generate output to the user and allow the user to provide input to the WD 110. The type of interaction may vary depending on the type of user interface device 132 installed in the WD 110. For example, if the WD 110 is a smartphone, the interaction may be via a touch screen; if the WD 110 is a smart meter, the interaction may be through a screen that provides usage information (e.g., gallons used) or a speaker that provides an audible alarm (e.g., if smoke is detected).

[0153] The user interface device 132 may include an input interface, a device and a circuit and an output interface, a device and a circuit. The user interface device 132 is configured to allow information to be input into the WD 110 and is connected to the processing circuit 120 to allow the processing circuit 120 to process the input information. The user interface device 132 may include, for example, a microphone, proximity or other sensors, keys / buttons, a touch display, one or more cameras, a USB port or other input circuits. The user interface device 132 is also configured to allow information to be output from the WD 110 and allow the processing circuit 120 to output information from the WD 110. The user interface device 132 may include, for example, a speaker, a display, a vibration circuit, a USB port, a headphone jack or other output circuits. Using one or more input and output interfaces, devices and circuits of the user interface device 132, the WD 110 can communicate with the end user and / or wireless network and allow them to benefit from the functionality described herein.

[0154] Auxiliary devices 134 are operable to provide more specialized functionality that may not typically be performed by a WD. This may include specialized sensors for taking measurements for various purposes, interfaces for additional types of communication such as wired communication, etc. The type and content of components of auxiliary devices 134 may vary depending on the embodiment and / or scenario.

[0155] The power source 136 may be in the form of a battery or battery pack in some embodiments. Other types of power sources such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a power cell may also be used. The WD 110 may further include a power circuit 137 for delivering power from the power source 136 to various parts of the WD 110 that require power from the power source 136 to perform any functionality described or indicated herein. The power circuit 137 may include power management circuitry in some embodiments.

[0156] The power circuit 137 may additionally or alternatively be operable to receive power from an external power source; in this case, the WD 110 may be connectable to the external power source (such as an electrical outlet) via an input circuit or interface such as a power cable. The power circuit 137 may also be operable in certain embodiments to deliver power from the external power source to the power supply 136. This may be used, for example, to charge the power supply 136. The power circuit 137 may perform any formatting, conversion, or other modification of the power from the power supply 136 to make the power suitable for the corresponding components of the WD 110 being powered.

[0157] Although the subject matter described herein may be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein are described with respect to wireless networks, such as Figure 4For simplicity, the example wireless network shown in Figure 4 The wireless network shown in FIG. 1 depicts only network 106, network nodes 160 and 160b, and WDs 110, 110b, and 110c. In practice, a wireless network may also include any additional components suitable for supporting communication between wireless devices or between a wireless device and another communication device, such as a wired telephone, a service provider, or any other network node or terminal device. Of the components shown, network node 160 and wireless device (WD) 110 are depicted with additional detail. A wireless network may provide communication and other types of services to one or more wireless devices, facilitating the wireless devices to access and / or use services provided by or via the wireless network.

[0158] Figure 5 An example user equipment according to certain embodiments is shown. As used herein, a user equipment or UE may not necessarily have a user in the sense of a human user owning and / or operating the associated device. Rather, a UE may represent a device that is intended to be sold to or operated by a human user but may not, or may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended to be sold to or operated by an end user but may be associated with a user or operated for the benefit of a user (e.g., a smart meter). UE 200 may be any UE identified by the Third Generation Partnership Project (3GPP), including an NB-IoT UE, a Machine Type Communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. As Figure 5 As shown in FIG, UE 200 is an example of a WD configured to communicate according to one or more communication standards promulgated by the Third Generation Partnership Project (3GPP), such as 3GPP's GSM, UMTS, LTE, and / or 5G standards. As previously mentioned, the terms WD and UE may be used interchangeably. Accordingly, although Figure 5 It is a UE, but the components discussed in this article are also applicable to WD, and vice versa.

[0159] exist Figure 5 In the embodiment, UE 200 includes processing circuit 201, which is operatively coupled to input / output interface 205; radio frequency (RF) interface 209; network connection interface 211; memory 215 including random access memory (RAM) 217, read-only memory (ROM) 219 and storage medium 221; communication subsystem 231; power supply 213; and / or any other components; or any combination thereof. Storage medium 221 includes operating system 223, application 225 and data 227. In other embodiments, storage medium 221 may include other similar types of information. Some UEs may use Figure 5 All of the components shown in the figure may be used, or only a subset of the components may be used. The level of integration between components may vary from one UE to another. In addition, some UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0160] exist Figure 5 , processing circuitry 201 may be configured to process computer instructions and data. Processing circuitry 201 may be configured to implement any sequential state machine that operates to execute machine instructions stored in memory as a machine-readable computer program, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGAs, ASICs, etc.); programmable logic together with appropriate firmware; one or more stored programs, general-purpose processors such as microprocessors or digital signal processors (DSPs), together with appropriate software; or any combination thereof. For example, processing circuitry 201 may include two central processing units (CPUs). Data may be information in a form suitable for use by a computer.

[0161] In the depicted embodiment, the input / output interface 205 may be configured to provide a communication interface to an input device, an output device, or both. The UE 200 may be configured to use an output device via the input / output interface 205 .

[0162] The output device may use the same type of interface port as the input device. For example, a USB port may be used to provide input to and output from the UE 200. The output device may be a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, a transmitter, a smart card, another output device, or any combination thereof.

[0163] The UE 200 can be configured to use input devices via the input / output interface 205 to allow the user to capture information into the UE 200. The input devices can include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. The presence-sensitive display can include a capacitive or resistive touch sensor to sense input from the user. The sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, a light sensor, a proximity sensor, another similar sensor, or any combination thereof. For example, the input device can be an accelerometer, a magnetometer, a digital camera, a microphone, and a light sensor.

[0164] exist Figure 5In the embodiment of the present invention, the RF interface 209 can be configured to provide a communication interface to RF components such as transmitters, receivers, and antennas. The network connection interface 211 can be configured to provide a communication interface to the network 243a. The network 243a can include a wired and / or wireless network such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 243a can include a Wi-Fi network. The network connection interface 211 can be configured to include a receiver and transmitter interface for communicating with one or more other devices through a communication network according to one or more communication protocols such as Ethernet, TCP / IP, SONET, ATM, etc. The network connection interface 211 can implement receiver and transmitter functionality suitable for a communication network link (e.g., optical, electrical, etc.). The transmitter and receiver functions can share circuit components, software, or firmware, or alternatively, the transmitter and receiver functions can be implemented separately.

[0165] RAM 217 may be configured to interface to processing circuitry 201 via bus 202 to provide storage or caching of data or computer instructions during execution of software programs, such as an operating system, application programs, and device drivers. ROM 219 may be configured to provide computer instructions or data to processing circuitry 201. For example, ROM 219 may be configured to store unchanging low-level system code or data for basic system functions, such as basic input and output (I / O), booting, or receiving keystrokes from a keyboard, that are stored in non-volatile memory.

[0166] The storage medium 221 may be configured to include a memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), a magnetic disk, an optical disk, a floppy disk, a hard disk, a removable cassette, or a flash drive. In one example, the storage medium 221 may be configured to include an operating system 223; an application 225 such as a web browser application, a widget or gadget engine, or another application; and data files 227. The storage medium 221 may store any of a variety of different operating systems or a combination of operating systems for use by the UE 200.

[0167] The storage medium 221 can be configured to include multiple physical drive units such as a redundant array of independent disks (RAID), a floppy disk drive, flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD) optical drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) optical drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, smart card memory such as a subscriber identity module or a removable user identity (SIM / RUIM) module, other memory, or any combination thereof. The storage medium 221 can allow the UE 200 to access computer-executable instructions, applications, etc. stored on a temporary or non-transitory storage medium to download or upload data. An article of manufacture, such as an article of manufacture utilizing a communication system, can be tangibly embodied in the storage medium 221, which can include device-readable media.

[0168] exist Figure 5 In the embodiment, the processing circuit 201 can be configured to communicate with the network 243b using the communication subsystem 231. The network 243a and the network 243b can be the same one or more networks or different one or more networks. The communication subsystem 231 can be configured to include one or more transceivers for communicating with the network 243b. For example, the communication subsystem 231 can be configured to include one or more transceivers for communicating with one or more remote transceivers of another device capable of wireless communication, such as another WD, UE, or a base station of a radio access network (RAN), according to one or more communication protocols such as IEEE 802.11, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, etc. Each transceiver can include a transmitter 233 and / or a receiver 235 for respectively implementing transmitter or receiver functionality (e.g., frequency allocation, etc.) suitable for a RAN link. In addition, the transmitter 233 and receiver 235 of each transceiver can share circuit components, software, or firmware, or alternatively, the transmitter 233 and receiver 235 of each transceiver can be implemented separately.

[0169] In the illustrated embodiment, the communication functions of the communication subsystem 231 may include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as using a global positioning system (GPS) to determine location, another similar communication function, or any combination thereof. For example, the communication subsystem 231 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 243b may include a wired and / or wireless network such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 243b may be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 213 may be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE 200.

[0170] The features, benefits, and / or functions described herein may be implemented in one of the components of the UE 200 or divided across multiple components of the UE 200. Furthermore, the features, benefits, and / or functions described herein may be implemented using any combination of hardware, software, or firmware. In one example, the communication subsystem 231 may be configured to include any of the components described herein. Furthermore, the processing circuit 201 may be configured to communicate with any of these components via the bus 202. In another example, any of these components may be represented by program instructions stored in a memory that, when executed by the processing circuit 201, perform the corresponding functions described herein. In another example, the functionality of any of these components may be divided between the processing circuit 201 and the communication subsystem 231. In another example, non-computationally intensive functions of any of these components may be implemented using software or firmware, while computationally intensive functions may be implemented using hardware.

[0171] Figure 6 is a schematic block diagram illustrating a virtualization environment 300 in which functionality implemented by some embodiments may be virtualized. In this context, virtualization means creating a virtual version of an appliance or device that may include virtualized hardware platforms, storage devices, and networking resources. As used herein, virtualization may be applied to a node (e.g., a virtualized base station or a virtualized radio access node) or to a device (e.g., a UE, a wireless device, or any other type of communication device) or component thereof and relates to an implementation in which at least a portion of functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, or containers executed on one or more physical processing nodes in one or more networks).

[0172] In some embodiments, some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 300 hosted by one or more of the hardware nodes 330. Furthermore, in embodiments where the virtual nodes are not radio access nodes or do not require radio connectivity (e.g., core network nodes), the network nodes may be fully virtualized.

[0173] The functionality may be implemented by one or more applications 320 (which may alternatively be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) that operate to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. The applications 320 are executed in a virtualized environment 300 that provides hardware 330 including processing circuitry 360 and memory 390. The memory 390 contains instructions 395 executable by the processing circuitry 360, whereby the applications 320 operate to provide one or more of the features, benefits, and / or functions disclosed herein.

[0174] The virtualized environment 300 includes general-purpose or specialized network hardware devices 330, which include a collection of one or more processors or processing circuits 360, which may be commercial off-the-shelf (COTS) processors, specialized application-specific integrated circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or specialized processors. Each hardware device may include memory 390-1, which may be non-persistent memory for temporarily storing software or instructions 395 executed by the processing circuits 360. Each hardware device may include one or more network interface controllers (NICs) 370, also known as network interface cards, which include a physical network interface 380. Each hardware device may also include a non-transitory, permanent, machine-readable storage medium 390-2 having stored therein instructions and / or software 395 executable by the processing circuits 360. The software 395 may include any type of software, including software for instantiating one or more virtualization layers 350 (also referred to as a hypervisor), software for executing a virtual machine 340, and software that enables it to perform the functions, features and / or benefits described in connection with some of the embodiments described herein.

[0175] The virtual machines 340 include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage devices, and can be run by corresponding virtualization layers 350 or hypervisors. Different embodiments of instances of the virtual device 320 can be implemented on one or more of the virtual machines 340 and can be implemented in different ways.

[0176] During operation, processing circuitry 360 executes software 395 to instantiate a hypervisor, which may sometimes be referred to as a virtual machine monitor (VMM), or virtualization layer 350. Virtualization layer 350 may present to virtual machines 340 a virtual operating platform that appears to be networked hardware.

[0177] like Figure 6 As shown in FIG, hardware 330 can be a standalone network node with general or specialized components. Hardware 330 can include antenna 3225 and can implement some functions with the help of virtualization. Alternatively, hardware 330 can be part of a larger hardware cluster (e.g., such as in a data center or customer premises equipment (CPE)), where many hardware nodes work together and are managed via management and orchestration (MANO) 3100, which also oversees the lifecycle management of application 320, among other things.

[0178] Virtualization of hardware is referred to in some contexts as network function virtualization (NFV). NFV can be used to consolidate many network device types onto industry-standard high-volume server hardware, physical switches, and physical storage devices that can be located in data centers and customer premises equipment.

[0179] In the context of NFV, virtual machines 340 can be software implementations of physical machines that run programs as if they were executing on a physical, non-virtualized machine. Each of virtual machines 340 and the portion of hardware 330 on which that virtual machine executes, whether it is hardware dedicated to that virtual machine and / or hardware shared by that virtual machine and other virtual machines in virtual machines 340, form an independent virtual network element (VNE).

[0180] Still in the context of NFV, a virtual network function (VNF) is responsible for handling specific network functions running in one or more virtual machines 340 on top of the hardware networking infrastructure 330 and corresponds to the application 320 in Figure 18.

[0181] In some embodiments, one or more radio units 3200, each including one or more transmitters 3220 and one or more receivers 3210, may be coupled to one or more antennas 3225. The radio units 3200 may communicate directly with the hardware nodes 330 via one or more appropriate network interfaces, and may be used in combination with virtual components to provide radio capabilities to a virtual node, such as a radio access node or base station.

[0182] In some embodiments, some signaling may be achieved with the aid of a control system 3230 , which may alternatively be used for communication between the hardware node 330 and the radio unit 3200 .

[0183] refer to Figure 7 According to an embodiment, a communications system includes a telecommunications network 410, such as a 3GPP-type cellular network, including an access network 411, such as a radio access network, and a core network 414. Access network 411 includes multiple base stations 412a, 412b, and 412c, such as NBs, eNBs, gNBs, or other types of wireless access points, each defining a corresponding coverage area 413a, 413b, and 413c. Each base station 412a, 412b, and 412c is connectable to core network 414 via a wired or wireless connection 415. A first UE 491 located in coverage area 413c is configured to wirelessly connect to or be paged by the corresponding base station 412c. A second UE 492 in coverage area 413a is configured to wirelessly connect to the corresponding base station 412a. Although multiple UEs 491 and 492 are shown in this example, the disclosed embodiments are equally applicable to scenarios where a single UE is within the coverage area or where a single UE is connecting to the corresponding base station 412.

[0184] Telecommunications network 410 itself is connected to a host computer 430, which may be embodied in the hardware and / or software of a standalone server, a cloud-enabled server, a distributed server, or as processing resources in a server farm. Host computer 430 may be under the ownership or control of a service provider, or may be operated by or on behalf of a service provider. Connections 421 and 422 between telecommunications network 410 and host computer 430 may extend directly from core network 414 to host computer 430, or may be via an optional intermediary network 420. Intermediary network 420 may be one of a public, private, or managed network, or a combination of more than one of these networks; intermediary network 420, if present, may be a backbone network or the Internet; in particular, intermediary network 420 may include two or more subnetworks (not shown).

[0185] Figure 7 The communication system as a whole enables connectivity between connected UEs 491, 492 and host computer 430. This connectivity can be described as an over-the-top (OTT) connection 450. Host computer 430 and connected UEs 491, 492 are configured to communicate data and / or signaling via OTT connection 450 using access network 411, core network 414, any intermediate networks 420, and possible additional infrastructure (not shown) as intermediaries. OTT connection 450 can be transparent in the sense that the participating communication devices through which OTT connection 450 passes are unaware of the routing of uplink and downlink communications. For example, base station 412 may not be informed or need not be informed of the past routing of incoming downlink communications, where data originating from host computer 430 is to be forwarded (e.g., handed over) to connected UE 491. Similarly, base station 412 does not need to be aware of the future routing of outgoing uplink communications originating from UE 491 toward host computer 430.

[0186] Figure 8 An example host computer is shown communicating with a user device via a base station over a partially wireless connection according to some embodiments. Figure 8 5. The example implementation of the UE, base station, and host computer discussed in the previous paragraphs according to the embodiments is described. In the communication system 500, the host computer 510 includes hardware 515, which includes a communication interface 516 configured to establish and maintain a wired or wireless connection with the different communication devices of the communication system 500. The host computer 510 further includes processing circuitry 518, which may have storage and / or processing capabilities. In particular, the processing circuitry 518 may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or a combination thereof (not shown) adapted to execute instructions. The host computer 510 further includes software 511, which is stored in the host computer 510 or accessible by the host computer 510 and executable by the processing circuitry 518. The software 511 includes a host application 512. The host application 512 may be operable to provide services to a remote user, such as a UE 530, connected via an OTT connection 550 terminated at the UE 530 and the host computer 510. When providing services to remote users, the host application 512 may provide user data transmitted using the OTT connection 550 .

[0187] The communication system 500 further includes a base station 520 provided in the telecommunication system and including hardware 525 enabling it to communicate with the host computer 510 and with the UE 530. The hardware 525 may include a communication interface 526 for establishing and maintaining wired or wireless connections with different communication devices of the communication system 500 and hardware 526 for establishing and maintaining connections with at least those located in the coverage area served by the base station 520 (not in the coverage area). Figure 8 The communication interface 526 may be configured to facilitate a connection 560 to the host computer 510. The connection 560 may be direct or it may be through a core network of the telecommunications system (not shown). Figure 8 ) and / or through one or more intermediate networks external to the telecommunications system. In the illustrated embodiment, the hardware 525 of the base station 520 further includes processing circuitry 528, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination thereof (not shown) adapted to execute instructions. The base station 520 further has software 521 stored internally or accessible via an external connection.

[0188] Communication system 500 further includes the aforementioned UE 530. Its hardware 535 may include a radio interface 537 configured to establish and maintain a wireless connection 570 with a base station serving the coverage area in which UE 530 is currently located. UE 530's hardware 535 further includes processing circuitry 538, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or a combination thereof (not shown) adapted to execute instructions. UE 530 further includes software 531 stored in UE 530 or accessible to UE 530 and executable by processing circuitry 538. Software 531 includes a client application 532. Client application 532 may be operable to provide services to human or non-human users via UE 530 with the support of host computer 510. Within host computer 510, executing host application 512 may communicate with executing client application 532 via an OTT connection 550 terminated at UE 530 and host computer 510. When providing services to users, client application 532 can receive request data from host application 512 and provide user data in response to the request data. OTT connection 550 can transmit both the request data and the user data. Client application 532 can interact with the user to generate the user data it provides.

[0189] Notice that Figure 8 The host computer 510, base station 520 and UE 530 shown in FIG can be respectively Figure 4The host computer 430, one of the base stations 412a, 412b, 412c, and one of the UEs 491, 492 may be similar or identical. That is, the internal workings of these entities may be similar to Figure 8 As shown in , and independently, the surrounding network topology can be Figure 4 network topology.

[0190] exist Figure 8 In FIG, OTT connection 550 has been abstractly drawn to illustrate communication between host computer 510 and UE 530 via base station 520, without explicitly mentioning any intermediate devices and the precise routing of messages via these devices. The network infrastructure can determine the routing, which can be configured to be hidden from UE 530 or from the service provider operating host computer 510, or both. While OTT connection 550 is active, the network infrastructure can further make decisions by which it dynamically changes the routing (e.g., based on network reconfiguration or load balancing considerations).

[0191] Wireless connection 570 between UE 530 and base station 520 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments may improve the performance of an OTT service provided to UE 530 using OTT connection 550, where wireless connection 570 forms the final leg. More specifically, the teachings of these embodiments may improve signaling overhead and reduce latency, which may provide users with faster Internet access.

[0192] Measurement processes may be provided for monitoring data rate, latency, and other factors improved by one or more embodiments. Optional network functionality may further be provided for reconfiguring the OTT connection 550 between the host computer 510 and the UE 530 in response to changes in measurement results. The measurement process and / or network functionality for reconfiguring the OTT connection 550 may be implemented using software 511 and hardware 515 of the host computer 510, software 531 and hardware 535 of the UE 530, or both. In an embodiment, sensors (not shown) may be deployed in or associated with the communication device through which the OTT connection 550 passes. The sensors may participate in the measurement process by providing values of the monitored quantities exemplified above or other physical quantities from which the software 511 or 531 can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 550 may include message formats, retransmission settings, preferred routing, and the like. The reconfiguration need not affect the base station 520 and may be unknown or imperceptible to the base station 520. Such processes and functionality may be known and implemented in the art. In certain embodiments, the measurements may involve proprietary UE signaling that facilitates measurements by the host computer 510 of throughput, propagation time, latency, etc. The measurements may be achieved because the software 511 and 531 uses the OTT connection 550 to cause messages to be transmitted, particularly empty or "dummy" messages, while the software 511 and 531 monitors propagation time, errors, etc.

[0193] Figure 9 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a Figure 7 and Figure 8 For the sake of simplicity of this disclosure, only the host computers, base stations and UEs described in this section will be included. Figure 9 See attached drawings for reference.

[0194] In step 610, the host computer provides user data. In sub-step 611 of step 610 (which may be optional), the host computer provides the user data by executing a host application. In step 620, the host computer initiates a transmission to the UE carrying the user data. In step 630 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station transmits the user data carried in the transmission initiated by the host computer to the UE. In step 640 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0195] Figure 10 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a Figure 7 and Figure 8 For the sake of simplicity of this disclosure, only the host computers, base stations and UEs described in this section will be included. Figure 10 See attached drawings for reference.

[0196] In step 710 of the method, a host computer provides user data. In an optional sub-step (not shown), the host computer provides the user data by executing a host application. In step 720, the host computer initiates a transmission to the UE carrying the user data. According to the teachings of the embodiments described throughout this disclosure, the transmission may pass through a base station. In step 730 (which may be optional), the UE receives the user data carried in the transmission.

[0197] Figure 11 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a Figure 7 and Figure 8 For the sake of simplicity of this disclosure, only the host computers, base stations and UEs described in this section will be included. Figure 11 See attached drawings for reference.

[0198] In step 810 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 820, the UE provides user data. In sub-step 821 (which may be optional) of step 820, the UE provides the user data by executing a client application. In sub-step 811 (which may be optional) of step 810, the UE executes the client application, which provides the user data as a reaction to the received input data provided by the host computer. When providing the user data, the executed client application may further consider the user input received from the user. Regardless of the specific manner in which the user data is provided, the UE initiates the transmission of the user data to the host computer in sub-step 830 (which may be optional). In step 840 of the method, the host computer receives the user data transmitted from the UE in accordance with the teachings of the embodiments described throughout this disclosure.

[0199] Figure 12 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a Figure 7 and Figure 8 For the sake of simplicity of this disclosure, only the host computers, base stations and UEs described in this section will be included. Figure 12 See attached drawings for reference.

[0200] In step 910 (which may be optional), the base station receives user data from the UE in accordance with the teachings of the embodiments described throughout this disclosure. In step 920 (which may be optional), the base station initiates a transmission of the received user data to the host computer. In step 930 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0201] In the examples and embodiments described herein, when a message is transmitted to a wireless device or to a network node, the message may be transmitted directly or indirectly via one or more intermediate network nodes or wireless devices. Similarly, when a message is received from a wireless device or network node, the message may be received directly or indirectly via one or more intermediate network nodes or wireless devices.

[0202] Figure 13A is a flow chart illustrating a method 1000 performed by a wireless device according to certain embodiments. In certain embodiments, Figure 13A One or more steps may be performed by Figure 4 The wireless device 110 described above is implemented.

[0203] The method begins at step 1001, where a wireless device tracks historical information of the wireless device.

[0204] At step 1002, the wireless device generates a mobility report based on historical information.

[0205] At step 1003, the wireless device transmits a mobility report to the network node. The network node may use the mobility report to train or retrain an artificial intelligence / machine learning model for predicting the mobility path of the wireless device.

[0206] Can Figure 13A Method 1000 may be modified, added, or omitted. Figure 13A One or more steps in the method may be performed in parallel or in any suitable order.

[0207] Figure 13B is a flow chart illustrating a method 1100 performed by a first network node according to certain embodiments. In certain embodiments, Figure 13B One or more steps may be performed by Figure 4 The network node 162 described above is executed.

[0208] The method begins at step 1101, where a first network node obtains a UE trajectory prediction. The UE trajectory prediction may include the output of an artificial intelligence / machine learning model. The first network node may perform training of the AI / ML model, or the first network node may obtain the UE trajectory prediction from another network node (such as an OAM node).

[0209] At step 1102, the first network node transmits a UE trajectory prediction and an indication requesting feedback on the UE trajectory prediction to the second network node. The indication requesting feedback includes assistance information for associating an identifier with the requested feedback.

[0210] The first network node may transmit the UE trajectory prediction in the same message as the indication requesting feedback on the UE trajectory prediction or in a separate message.

[0211] In certain embodiments, the assistance information includes an identifier for associating the requested feedback with the UE trajectory prediction. For example, the identifier may include a feedback identifier and / or an identifier of the UE.

[0212] In some embodiments, the indication requesting feedback may include one or more messages. For example, a first message may include a portion of a feedback identifier associated with the UE trajectory prediction, and another message may include a second portion of the feedback identifier associated with the UE trajectory prediction (e.g., a UE identifier).

[0213] In a particular embodiment, the assistance information includes an identifier of a network node for receiving the feedback.

[0214] In certain embodiments, receiving feedback includes receiving artificial intelligence / machine learning assisted data update messages.

[0215] In certain embodiments, the assistance information includes an indication to request feedback after a threshold number of handovers.

[0216] In certain embodiments, the received feedback includes a UE trajectory cell list and / or a dwell time for each cell in the UE trajectory cell list.

[0217] Other and additional examples of assistance information and received feedback are described with respect to the embodiments and examples described herein.

[0218] At step 1103, the first network node receives feedback regarding the UE trajectory prediction from the third network node. In certain embodiments, the second network node and the third network node are the same network node (e.g., a RAN node). In certain embodiments, the second network node may be a RAN node, and the third network node may be, for example, an OAM node.

[0219] Can Figure 13B Method 1100 may be modified, added, or omitted. Figure 13B One or more steps in the method may be performed in parallel or in any suitable order.

[0220] Figure 13Cis a flow chart illustrating a method 1200 performed by a second network node according to certain embodiments. In certain embodiments, Figure 13C One or more steps may be performed by Figure 4 The network node 162 described above is executed.

[0221] The method starts at step 1201, where a second network node receives a UE trajectory prediction and an indication requesting feedback on the UE trajectory prediction. The indication requesting feedback includes auxiliary information for associating an identifier with the requested feedback. Figure 13B and the embodiments and examples described herein, describe the instructions and auxiliary information in more detail.

[0222] At step 1202, the second network node transmits feedback regarding the UE trajectory prediction to the first network node. Figure 13B and the embodiments and examples described herein describe feedback in more detail.

[0223] Can Figure 13C Method 1200 may be modified, added, or omitted. Figure 13C One or more steps in the method may be performed in parallel or in any suitable order.

[0224] Figure 14 is a flow chart illustrating a method 1400 performed by a first network node according to certain embodiments. In certain embodiments, Figure 14 One or more steps may be performed by Figure 4 The network node 162 described above is executed.

[0225] The method begins at step 1412, where a first network node obtains a UE trajectory prediction. The UE trajectory prediction may include the output of an artificial intelligence / machine learning model. The first network node may perform training of the AI / ML model, or the first network node may obtain the UE trajectory prediction from another network node, such as an OAM node.

[0226] At step 1414, the first network node transmits the UE trajectory prediction and an indication requesting feedback on the UE trajectory prediction to the second network node. The indication requesting feedback includes assistance information for associating an identifier with the requested feedback.

[0227] The first network node may transmit the UE trajectory prediction in the same message as the indication requesting feedback on the UE trajectory prediction or in a separate message.

[0228] In certain embodiments, the assistance information includes an identifier for associating the requested feedback with the UE trajectory prediction. For example, the identifier may include a feedback identifier and / or an identifier of the UE.

[0229] In some embodiments, the indication requesting feedback may include one or more messages. For example, a first message may include a portion of a feedback identifier associated with the UE trajectory prediction, and another message may include a second portion of the feedback identifier associated with the UE trajectory prediction (e.g., a UE identifier).

[0230] In a particular embodiment, the assistance information includes an identifier of a network node for receiving the feedback.

[0231] In certain embodiments, receiving feedback includes receiving artificial intelligence / machine learning assisted data update messages.

[0232] In certain embodiments, the assistance information includes an indication to request feedback after a threshold number of handovers.

[0233] In certain embodiments, the received feedback includes a UE trajectory cell list and / or a dwell time for each cell in the UE trajectory cell list.

[0234] Other and additional examples of assistance information and received feedback are described with respect to the embodiments and examples described herein.

[0235] At step 1416, the first network node receives feedback regarding the UE trajectory prediction from the third network node. In certain embodiments, the second network node and the third network node are the same network node (e.g., a RAN node). In certain embodiments, the second network node may be a RAN node, and the third network node may be, for example, an OAM node.

[0236] Can Figure 14 Method 1400 may be modified, added, or omitted. Figure 14 One or more steps in the method may be performed in parallel or in any suitable order.

[0237] Figure 15 is a flow chart illustrating a method 1500 performed by a second network node according to certain embodiments. In certain embodiments, Figure 15 One or more steps may be performed by Figure 4 The network node 162 described above is executed.

[0238] The method begins at step 1512, where the second network node receives a UE trajectory prediction and an indication requesting feedback on the UE trajectory prediction. The indication requesting feedback includes auxiliary information for associating an identifier with the requested feedback. Figure 14 and the embodiments and examples described herein describe the instructions and auxiliary information in more detail.

[0239] At step 1514, the second network node transmits feedback regarding the UE trajectory prediction to the first network node. Figure 14 and the embodiments and examples described herein describe feedback in more detail.

[0240] Can Figure 15 Method 1500 may be modified, added, or omitted. Figure 15 One or more steps in the method may be performed in parallel or in any suitable order.

[0241] The term unit may have the conventional meaning in the field of electronic devices, electrical apparatus and / or electronic devices and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logical solid-state and / or discrete devices, computer programs or instructions for performing corresponding tasks, processes, calculations, output and / or display functions, etc., such as those described in this document.

[0242] Without departing from the scope of the present invention, the systems and devices disclosed herein may be modified, added to, or omitted. The components of the systems and devices may be integrated or separated. In addition, the operations of the systems and devices may be performed by more, fewer, or other components. In addition, the operations of the systems and devices may be performed using any suitable logic including software, hardware, and / or other logic. As used in this document, "each" refers to each member of a set or each member of a subset of a set.

[0243] Without departing from the scope of the present invention, the methods disclosed herein may be modified, added to, or omitted. The methods may include more, fewer, or other steps. Furthermore, the steps may be performed in any suitable order.

[0244] The foregoing description sets forth numerous specific details. However, it is understood that embodiments can be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of this description. Using the included descriptions, one of ordinary skill in the art will be able to implement appropriate functionality without undue experimentation.

[0245] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. In addition, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0246] Although the present disclosure has been described in terms of certain embodiments, variations and substitutions of the embodiments will be apparent to those skilled in the art. Therefore, the above description of the embodiments does not limit the present disclosure. Other variations, substitutions, and modifications are possible without departing from the scope of the present disclosure as defined by the appended claims.

[0247] Example Embodiments Group A Examples 1. A method performed by a wireless device, the method comprising: - Track historical information of wireless devices; -Generate mobility reports based on historical information; and -Transmitting mobility reports to network nodes. 2. A method performed by a wireless device, the method comprising: - Any of the wireless device steps, features or functions described above, alone or in combination with other steps, features or functions described above. 3. The method as described in the preceding embodiment further includes one or more additional wireless device steps, features or functions described above. 4. The method according to any of the preceding embodiments, further comprising: - provide user data; and - Forwarding user data to a host computer via transmission to a base station. Group B Examples 5. A method performed by a first base station, the method comprising: - Obtaining user equipment (UE) trajectory projection; - transmitting an indication of the UE trajectory projection to the second base station and requesting feedback on the accuracy of the UE trajectory projection; and - receiving feedback from a third base station regarding the accuracy of the UE trajectory projection. 6. A method performed by a second base station, the method comprising: - receiving an indication of a user equipment (UE) trajectory projection and requesting feedback on the accuracy of the UE trajectory projection; and - transmitting feedback to the first base station regarding the accuracy of the UE trajectory projection. 7. The method according to embodiment 5, wherein the second base station and the third base station are the same base station. 8. The method as in any one of embodiments 5-7, wherein the indication requesting feedback on the accuracy of the UE trajectory projection includes an identifier for associating the feedback with the UE trajectory projection. 9. The method as in any one of embodiments 5-8, wherein the indication requesting feedback on the accuracy of the UE trajectory prediction includes an identifier of a network node for receiving the feedback. 10. The method as described in Example 5 also includes using the received feedback to train an artificial intelligence or machine learning model. 11. A method performed by a base station, the method comprising: - receiving a mobility prediction report from another network node; and -Perform network optimization based on mobility prediction reports. 12. A method performed by a base station, the method comprising: a. Any of the base station steps, features, or functions described above, alone or in combination with other steps, features, or functions described above. 13. The method as described in the above embodiment further includes one or more additional base station steps, features or functions described above. 14. The method according to any of the preceding embodiments, further comprising: - access user data; and -Forward user data to a host computer or wireless device. Group C Examples 15. A wireless device, comprising: - processing circuitry configured to perform any of the steps of any of the embodiments of Group A; and - A power supply circuit configured to supply power to the wireless device. 16. A base station, comprising: - a processing circuit configured to perform any of the steps of any of the embodiments in Group B; - A power supply circuit configured to supply power to the base station. 17. A user equipment (UE), the UE comprising: - an antenna configured to transmit and receive wireless signals; a radio front-end circuit connected to the antenna and to the processing circuit and configured to condition signals passed between the antenna and the processing circuit; - the processing circuit is configured to perform any of the steps of any of the embodiments of Group A; an input interface connected to the processing circuitry and configured to allow information to be input into the UE for processing by the processing circuitry; - an output interface connected to the processing circuit and configured to output information from the UE that has been processed by the processing circuit; and - a battery connected to the processing circuit and configured to supply power to the UE. 18. A computer program comprising instructions which, when executed on a computer, perform any of the steps of any of Group A embodiments. 19. A computer program product comprising a computer program comprising instructions which, when executed on a computer, perform any of the steps of any of Group A embodiments. 20. A non-transitory computer readable storage medium or carrier comprising a computer program comprising instructions that, when executed on a computer, perform any of the steps of any of Group A embodiments. 21. A computer program comprising instructions which, when executed on a computer, perform any of the steps of any of Group B embodiments. 22. A computer program product comprising a computer program comprising instructions which, when executed on a computer, perform any of the steps of any of Group B embodiments. 23. A non-transitory computer readable storage medium or carrier comprising a computer program comprising instructions that, when executed on a computer, perform any of the steps of any of Group B embodiments. 24. A communication system comprising a host computer, comprising: - processing circuitry configured to provide user data; and - a communication interface configured to forward said user data to a cellular network for transmission to a user equipment (UE), - wherein the cellular network comprises a base station having a radio interface and a processing circuit, the processing circuit of the base station being configured to perform any of the steps of any of the embodiments of Group B. 25. The communication system as described in the above embodiment also includes the base station. 26. The communication system as described in the above two embodiments further includes the UE, wherein the UE is configured to communicate with the base station. 27. The communication system according to any of the preceding three embodiments, wherein: - the processing circuitry of the host computer is configured to execute a host application to provide said user data; and - The UE comprises a processing circuit configured to execute a client application associated with a host application. 28. A method implemented in a communication system comprising a host computer, a base station, and a user equipment (UE), the method comprising: - at the host computer, providing user data; and - Initiating, at a host computer, a transmission carrying said user data to the UE via a cellular network comprising a base station, wherein the base station performs any of the steps of any of the embodiments of Group B. 29. The method according to the preceding embodiment further comprises transmitting the user data at the base station. 30. The method of any preceding embodiment, wherein the user data is provided at a host computer by executing a host application, the method further comprising executing a client application associated with the host application at the UE. 31. A user equipment (UE) configured to communicate with a base station, the UE comprising a radio interface and a processing circuit configured to perform the above three embodiments. 32. A communication system comprising a host computer, comprising: - processing circuitry configured to provide user data; and - a communication interface configured to forward user data to a cellular network for transmission to a user equipment (UE), - wherein the UE comprises a radio interface and a processing circuit, the components of the UE being configured to perform any of the steps of any of the embodiments of Group A. 33. The communication system as described in the preceding embodiment, wherein the cellular network further comprises a base station configured to communicate with the UE. 34. The communication system according to the two preceding embodiments, wherein: - the processing circuitry of the host computer is configured to execute a host application to provide said user data; and - The processing circuitry of the UE is configured to execute a client application associated with a host application. 35. A method implemented in a communication system comprising a host computer, a base station, and a user equipment (UE), the method comprising: - at the host computer, providing user data; and - initiating, at a host computer, a transmission carrying the user data to the UE via a cellular network including the base station, wherein the UE performs any of the steps of any of the embodiments of Group A. 36. The method according to the preceding embodiment further includes receiving the user data from the base station at the UE. 37. A communication system comprising a host computer, comprising: - a communication interface configured to receive user data originating from a transmission from a user equipment (UE) to a base station, - wherein the UE comprises a radio interface and a processing circuit, the processing circuit of the UE being configured to perform any of the steps of any of the embodiments of Group A. 38. The communication system as described in the above embodiment also includes the UE. 39. The communication system as described in the above two embodiments further includes the base station, wherein the base station includes a radio interface configured to communicate with the UE and a communication interface configured to forward the user data carried by the transmission from the UE to the base station to a host computer. 40. The communication system according to any of the preceding three embodiments, wherein: - the processing circuitry of the host computer is configured to execute the host application; and - The processing circuitry of the UE is configured to execute a client application associated with a host application, thereby providing the user data. 41. The communication system according to any of the preceding four embodiments, wherein: - the processing circuitry of the host computer is configured to execute the host application, thereby providing the requested data; and - The processing circuitry of the UE is configured to execute a client application associated with a host application, thereby providing the user data in response to the request data. 42. A method implemented in a communication system comprising a host computer, a base station, and a user equipment (UE), the method comprising: - receiving, at a host computer, user data transmitted from the UE to the base station, wherein the UE performs any of the steps of any of the embodiments in Group A. 43. The method as described in the above embodiment also includes providing the user data to the base station at the UE. 44. The method according to the two preceding embodiments, further comprising: - at the UE, executing a client application, thereby providing user data to be transmitted; and - At the host computer, executing a host application associated with the client application. 45. The method according to the above three embodiments, further comprising: - executing a client application at the UE; and - receiving, at the UE, input data for a client application, the input data being provided at a host computer by executing a host application associated with the client application, - wherein user data to be transmitted is provided by the client application in response to said input data. 46. A communication system comprising a host computer, the host computer comprising a communication interface, the communication interface being configured to receive user data originating from a transmission from a user equipment (UE) to a base station, wherein the base station comprises a radio interface and a processing circuit, the processing circuit of the base station being configured to perform any of the steps of any of the embodiments in Group B. 47. The communication system as described in the above embodiment also includes the base station. 48. The communication system as described in the above two embodiments further includes the UE, wherein the UE is configured to communicate with the base station. 49. The communication system according to any of the preceding three embodiments, wherein: - the processing circuitry of the host computer is configured to execute a host application; - the UE being configured to execute a client application associated with the host application, thereby providing the user data to be received by a host computer. 50. A method implemented in a communication system comprising a host computer, a base station, and a user equipment (UE), the method comprising: - receiving, at a host computer, from the base station user data originating from a transmission that the base station has received from the UE, wherein the UE performs any of the steps of any of Group A embodiments. 51. The method according to the preceding embodiment further includes receiving, at the base station, the user data from the UE. 52. The method of the two preceding embodiments further comprising initiating, at the base station, transmission of the received user data to a host computer. Some additional example embodiments include the following: 1. A method performed by a first network node, the method comprising: Obtaining (1412) a user equipment UE trajectory prediction; transmitting (1414) the UE trajectory prediction and an indication requesting feedback regarding the UE trajectory prediction to a second network node, wherein the indication requesting feedback includes assistance information for associating an identifier with the requested feedback; and Feedback regarding the UE trajectory prediction is received (1416) from a third network node based on the transmitted assistance information. The method of claim 1 , wherein the second network node and the third network node are the same network node. 3. The method according to any one of claims 1-2, wherein the assistance information includes an identifier for associating the requested feedback with the UE trajectory prediction. The method of claim 3 , wherein the identifier comprises an identifier of a UE. 5. The method according to any one of claims 3-4, wherein the received feedback includes the identifier for associating the requested feedback with the UE trajectory prediction. 6. The method according to any one of claims 1 to 5, wherein the assistance information comprises an identifier of a network node for receiving the feedback. 7. The method of any one of claims 1-6, wherein receiving the feedback comprises receiving an artificial intelligence / machine learning assisted data update message. 8. The method of any one of claims 1-7, wherein the assistance information comprises an indication requesting feedback after a threshold number of handovers. 9. The method according to any one of claims 1 to 8, wherein the received feedback comprises a UE trajectory cell list. 10. The method according to any one of claims 1 to 9, wherein the received feedback includes a dwell time of each cell in the UE trajectory cell list. 11. The method of any one of claims 1-10, further comprising using the received feedback to train an artificial intelligence or machine learning model. 12. A first network node (160), comprising a processing circuit (170), the processing circuit (170) being operable to: Obtaining a user equipment UE trajectory prediction; transmitting the UE trajectory prediction and an indication requesting feedback regarding the UE trajectory prediction to a second network node, wherein the indication requesting feedback includes assistance information for associating an identifier with the requested feedback; and Feedback regarding the UE trajectory prediction is received from a third network node based on the transmitted assistance information. 13. The network node of claim 12, the processing circuit being further operable to perform the steps of any one of claims 2-11. 14. A method performed by a second network node, the method comprising: receiving (1512) a user equipment (UE) trajectory prediction and an indication requesting feedback regarding the UE trajectory prediction, wherein the indication requesting feedback includes assistance information for associating an identifier with the requested feedback; and Feedback regarding the UE trajectory prediction is transmitted (1514) to a first network node based on the assistance information. 15. The method of claim 14, wherein the first network node comprises a Radio Access Network (RAN) node or an Operation and Management (OAM) node. 16. The method according to any one of claims 14-15, wherein the assistance information comprises an identifier for associating the requested feedback with the UE trajectory prediction. The method of claim 16 , wherein the identifier comprises an identifier of a UE. 18. The method of any of claims 16-17, wherein the transmitted feedback includes the identifier for associating the requested feedback with the UE trajectory prediction. 19. The method according to any one of claims 14 to 18, wherein the assistance information comprises an identifier of a network node used to transmit the feedback. 20. The method of any one of claims 14-19, wherein transmitting the feedback comprises transmitting an artificial intelligence / machine learning assisted data update message. 21. The method of any of claims 14-20, wherein the assistance information comprises an indication requesting feedback after a threshold number of handovers. 22. The method of any one of claims 14-21, wherein the transmitted feedback comprises a UE trajectory cell list. 23. The method of any one of claims 14-22, wherein the transmitted feedback includes a dwell time for each cell in the UE trajectory cell list. 24. A second network node (160), the second network node (160) comprising a processing circuit (170), the processing circuit (170) being operable to: receiving an indication of a user equipment (UE) trajectory prediction and requesting feedback on the UE trajectory prediction; and Feedback regarding the UE trajectory prediction is transmitted to the first network node. 25. The network node of claim 24, the processing circuit being further operable to perform the steps of any one of claims 15-23. Appendix A Title: Cell Trajectory Prediction Exchange 1 Introduction The usage and semantics of UE trajectory prediction for AI / ML were discussed during RAN3#117-e and the following agreement was reached. The predicted cell-granular UE trajectories can be exchanged over Xn for AI / ML-based mobility optimization. This was discussed further during RAN3#117bis-e and the following was agreed upon: The cell-based UE trajectory prediction has the same structure as the UE history information IE. The cell-based UE trajectory prediction is provided as a list of future cells, each of which is indicated together with the expected time to stay in the cell. This appendix aims to discuss next steps related to the standards implications of the above protocol and to further discuss the open issues listed above. 2 Discussions 2.1 Cell-based UE trajectory prediction information Now that cell-based UE trajectory prediction has been agreed upon, RAN3 needs to define the information it contains. The following has been agreed upon: The cell-based UE trajectory prediction has the same structure as the UE history information IE. The cell-based UE trajectory prediction is provided as a list of future cells, each of which is indicated together with the expected time to stay in the cell. Regarding the UHI IE (Last Visited NG-RAN Cell Information IE from TS 38.413), for each cell or set of cells, it contains the following information: 1.Cell ID (mandatory) 2.Cell type (mandatory) 3. The time the UE stays in the cell (mandatory) 4. Enhanced granularity of the time the UE stays in the cell (optional) 5.HO reason value (optional) For cell-based UE trajectory prediction, (1) and (3) have been agreed upon during the previous meeting. Observation 1: There is agreement on the cell ID and expected dwell time being included as part of the cell-based UE trajectory prediction. (2) It is not always known at the node performing the prediction, since the prediction may include cells that are not adjacent to the node calculating the prediction. Configuring this information for all cells (including cells that are not adjacent cells) would be a burden for the operator. Therefore, and even though this information may be interesting for the prediction itself, it is recommended not to add it to the cell-based UE trajectory prediction information. Observation 2: Configuring cell types for non-adjacent cells will be a burden for operators For trajectory prediction, as suggested in (4), a granularity of 100ms is too detailed to produce accurate predictions. It will also not be very useful to the nodes receiving the predictions. If predictions are used to help predict mobility, relying on the exact time of the prediction to trigger HO or configure measurements may lead to an increase in HOF or RLF. The final HO decision should always be made based on the actual radio conditions. If the prediction is used for ES scenarios, a granularity of one second is sufficient. Therefore, it is recommended not to add the enhanced granularity IE to the cell-based UE trajectory prediction information. Observation 3: 100ms granularity is too complex for accurate trajectory prediction and is not useful to the nodes receiving the prediction. Finally, (5) is not trajectory-related information and cannot be accurately predicted because the decision to handover the UE (and therefore the HO cause) will be made by a different node than the one performing the prediction. Therefore, it is recommended not to add the HO cause to the cell-based UE trajectory prediction information. Observation 4: HO causes are not related to trajectory In summary, it is recommended to agree that the cell trajectory prediction IE contains a chronologically ordered list of predicted cells, including the following information: -Global cell ID -Estimated time the UE stays in the cell Proposal 1: Cell trajectory prediction is signaled as a chronological list of predicted cell IDs that the UE will connect to, together with the time the UE is expected to stay in this cell Recommendation 2: No need for cell type, expected dwell time enhancement granularity, and HO reason as cell-based UE trajectory prediction information The remaining question is how to signal this information to the nodes that require trajectory prediction. Handover decisions are made on a UE-by-UE basis, primarily for coverage reasons and based on UE measurements and capabilities. These parameters are different for different UEs, and it logically follows that cell-based UE trajectory prediction is associated with a given UE, such as for UHI. Therefore, it is recommended to use UE-associated signaling to signal cell trajectory prediction. Recommendation 3: Cell trajectory prediction is signaled via UE-associated signaling If the goal of cell-based UE trajectory prediction is to give more information to the source and target nodes to optimize mobility, and if UE-associated signaling is used, the next logical conclusion would be to reuse the handover request message, similar to UHI signaling. The cell-based UE trajectory prediction is transmitted via the existing HO signaling message. Recommendation 4: Signaling cell trajectory prediction in the handover request message 2.2 Feedback on Cell-Based UE Trajectory Prediction Discussions on UE trajectory prediction feedback were initiated at RAN3#117bis-e. Some companies suggested signaling the actual measurements of trajectory prediction to the source RAN node to be used as feedback information to improve future predictions. To determine whether this approach is feasible, it is important to emphasize that the NG-RAN node generates trajectory predictions on a per-UE basis. That is, the model inference function will take as input the UE's past mobility, UE location, UE radio measurements (e.g., the direction of movement), etc., and it will derive a trajectory prediction for a specific UE. With this in mind, when analyzing the option of receiving a measurement trajectory as feedback, the following questions can be immediately identified: -After UE mobility, the source NG-RAN removes the UE context. Therefore, even if the NG-RAN Even if a node receives a measured UE trace, it will not be able to determine to what UE context the feedback corresponds. This makes the feedback rather useless, as it is impossible to correlate the feedback with its corresponding prediction. If the trajectory prediction covers n future cell hops, the NG-RAN node serving the nth cell will most likely not be Xn connected to the source node that generated the prediction. Therefore, even if the source node keeps the UE context stored, it is unlikely that the nth NG-RAN node can signal the trajectory feedback back. - When the measured prediction is made available to the source node, the layout of cells in the neighborhood may have changed. As an example, some active cells may become deactivated when the prediction is generated. In order for the source node to correctly understand the trajectory feedback, the source node will need to maintain a complete history of how the cell deployment has changed over time, which increases complexity because it requires maintaining the full context of the cell deployment state at the NG-RAN node. In view of the above problems, it can be concluded that signaling of trajectory feedback is not feasible. Alternatively, the source NG-RAN node can use UE history information to check the accuracy of its trajectory prediction. In reality, UE trajectories often repeat themselves, meaning that a UE may frequently traverse the same route. By examining UE history information, the NG-RAN node can see the mobility history of UEs previously served by the NG-RAN node and returning to that node. This history can be used as feedback for future predictions. The following table explains this concept. UE trajectory prediction when UE x is in cell 1 Measured UHI of UEy connected to cell 1 t0–CGI 1 <![CDATA[t0–CGI1]]> t1–CGI 2 <![CDATA[t -1 –CGI4]]> t2–CGI 1 <h2 style=";text-align:left;direction:ltr"><![CDATA[t <h2 style=";text-align:left;direction:ltr"> -2 <h2 style=";text-align:left;direction:ltr"> –CGI3]]><h2 style=";text-align:left;direction:ltr"> T3–CGI 3 <![CDATA[t -3 –CGI1]]> T4–CGI 4 <![CDATA[t -4 –CGI2]]> In the table above, NG-RAN node 1 predicts the UE trajectory of UE x connected to cell 1. At the same time, UE y is connected to cell 1, and NG-RAN node 1 receives the UE history information in the right column. It is possible that the historical sequence of cells that the NG-RAN node 1 sees a newly connected UE traverses matches well with the trajectory prediction that the NG-RAN node 1 derived for the UE under similar conditions. Assuming that an NG-RAN node receives thousands of UHIs per day, it is reasonable to assume that the UHIs can have a statistical correlation with time and thus be used as trajectory feedback. Conclusion: It is not feasible to explicitly signal the measured UE trajectory to the source NG-RAN. The NG-RAN node can use the UE historical information to derive feedback for the UE trajectory prediction. Appendix B Examples of update specifications based on the embodiments and examples described herein may include the following. <<<<<<<<<<<<<<<<<<<<<First Change>>>>>>>>>>>>>>> 8.2.1 Switchover Preparation 8.2.1.1 Overview This procedure is used to establish the necessary resources in the NG-RAN node for an incoming handover. If the procedure involves a conditional handover, parallel transactions are allowed. When the source UE AP ID is the same, possible parallel requests are identified by the target cell ID. This process uses UE-associated signaling. 8.2.1.2 Successful Operation <Image omitted> Figure 8 .2.1.2-1: Switch preparation, successful operation The source NG-RAN node initiates the procedure by sending a Handover Request message to the target NG-RAN node. When the source NG-RAN node sends the Handover Request message, it shall start the timer TXn RELOCprep . If the Handover Request message contains a Conditional Handover Information Request IE, the target NG-RAN node shall consider that the request involves a conditional handover and shall include the Conditional Handover Information Confirm IE in the Handover Request Confirm message. If the Target NG-RAN Node UEXnAP ID IE is included in the Conditional Handover Information Request IE included in the Handover Request message, the target NG-RAN node shall remove the existing prepared conditional HO identified by the Target NG-RAN Node UEXnAP ID IE and the Target Cell Global ID IE. When to remove the HO information depends on the implementation of the target NG-RAN node. Upon receipt of the Handover Request Confirm message, the source NG-RAN node shall stop the timer TXn RELOCprep , and terminate the handover preparation procedure. If the procedure is initiated for immediate handover, the source NG-RAN node shall start timer TXn RELOCoverall The source NG-RAN node is then defined as having handover prepared signalling associated with this Xn UE. For each E-RAB ID IE included in the QoS Flow List to be Set IE in the Handover Request message, the target NG-RAN node shall store the content of the IE in the UE context, if supported, and use it for subsequent inter-system handovers. If the Suppressed IMEISV IE is included in the Handover Request message, the target NG-RAN node shall use it to determine the characteristics of the UE for subsequent handling, if supported. Upon receiving the Handover Request message, the target NG-RAN node shall prepare the configuration of the AS security relationship between the UE and the target NG-RAN node by using the information in the AS Security Information IE and the UE Security Capabilities IE in the UE Context Information IE, as specified in TS 33.501. Upon receiving the PDU Session Resources Setup List IE included in the Handover Request message, the target NG-RAN node shall behave as specified in TS 38.413 for the PDU Session Resources Setup procedure. The target NG-RAN node shall report the resulting successful establishment of all requested PDU Session resources in the Handover Request Confirm message. When the target NG-RAN node reports unsuccessful establishment of PDU Session resources, the cause value shall be precise enough to enable the source NG-RAN node to understand the reason for the unsuccessful establishment. For each PDU Session, if the PDU Session Aggregate Maximum Bit Rate IE is included in the PDU Session Resource List to Set Up IE contained in the Handover Request message, the target NG-RAN node shall store the received PDU Session Aggregate Maximum Bit Rate in the UE context and use it when enforcing flow policing for the Non-GBR QoS flows of the involved UEs as specified in TS 23.501. For each QoS flow for which the source NG-RAN node proposes to perform downlink data forwarding, the source NG-RAN node shall include the DL Forwarding IE set to "Proposed DL Forwarding" within the Data Forwarding and Offload Information from Source NG-RAN Node IE in the PDU Session Resource List to be Set IE in the Handover Request message. If the source NG-RAN node requests DAPS handover for this DRB, the source NG-RAN node shall include the DL Forwarding IE set to "Proposed DL Forwarding" for all QoS flows mapped to the DRB. For each PDU session for which the target NG-RAN node decides to admit data forwarding for at least one QoS flow, the target NG-RAN node shall include the PDU Session Level DL Data Forwarding GTP-U Tunnel Endpoint IE within the Data Forwarding Information from Target NG-RAN Node IE in the PDU Session Resource Admission List IE included in the Handover Request Confirm message. For each QoS flow for which the source NG-RAN node has not received an SDAP end marker packet, if QoS flow remapping occurs before handover, the source NG-RAN node should include the UL Forwarding Proposal IE in the Data Forwarding and Offload Information IE from the source NG-RAN node in the Handover Request message, and if the target NG-RAN node decides to admit uplink data forwarding of at least one QoS flow, the target NG-RAN node may include the PDU Session Level UL Data Forwarding UP TNL Information IE in the Data Forwarding Information IE from the target NG-RAN node in the PDU Session Resource Admission Item IE included in the PDU Session Resource Admission List IE in the Handover Request Confirm message to indicate that it accepts uplink data forwarding. For each PDU Session Resource successfully set up at the target NG-RAN, the target NG-RAN node may allocate resources for an additional Xn-U PDU Session Resource GTP-U tunnel indicated in the Assistance Data Forwarding Information IE from the target NG-RAN node list. For each PDU Session in the Handover Request message, if the Alternative QoS Parameter Set List IE is included in the GBR QoS Flow Information IE in the PDU Session Resource List to Set IE, then if at least one of the requested QoS parameter set or the alternative QoS parameter set can be satisfied at the time of handover as specified in TS 23.501, then the target NG-RAN node may accept the setup of the QoS flow involved when notification control has been enabled. In the event that the target NG-RAN node accepts handover that satisfies one of the alternative QoS parameters, it shall indicate the alternative QoS parameter set that it can currently satisfy in the Current QoS Parameter Set Index IE in the PDU Session Resource Admission List IE of the Handover Request Confirm message, while setting the QoS parameters for the UE according to the requested QoS parameter set as specified in TS 23.501. For each DRB for which the source NG-RAN node proposes to perform downlink data forwarding, the source NG-RAN node shall include the DRB ID IE and the mapped QoS Flow List IE in the Source DRB to QoS Flow Mapping List IE included in the PDU Session Resource List to be Set Up IE in the Handover Request message. The source NG-RAN node may include a QoS Flow Mapping Indication IE in the Source DRB to QoS Flow Mapping List IE to indicate that only uplink or downlink QoS flows are mapped to the DRB. If the target NG-RAN node decides to use the same DRB configuration and map the same QoS flows as the source NG-RAN node, the target NG-RAN node includes a DL Forwarding GTP Tunnel Endpoint IE in the Data Forwarding Response DRB List IE in the Handover Request Confirm message to indicate that it accepts the proposed forwarding of downlink data for this DRB. If at least one of the QoS flows mapped to the DRB complies with the redundant transmission characteristics, as indicated in the Redundant QoS Flow Indicator IE within the PDU Session Resource List to Set Up IE received in the Handover Request message for the QoS flow, the target NG-RAN node may additionally include a Redundant DL Forwarding UP TNL Information IE. If the Handover Request Confirm message contains the UL Forwarding GTP Tunnel Endpoint IE for a given DRB in the Data Forwarding Response DRB List IE within the Data Forwarding Information IE from the target NG-RAN node in the PDU Session Resource Admission List IE and the source NG-RAN node accepts the data forwarding proposed by the target NG-RAN node, the source NG-RAN node shall perform the forwarding of the uplink data for the DRB. If the Handover Request includes PDU session resources for PDU sessions associated with S-NSSAI not supported by the target NG-RAN, the target NG-RAN node shall reject such PDU session resources. In this case, and if at least one PDU session resource item to be set IE is accepted, the target NG-RAN node shall send a Handover Request Confirm message including a PDU Session Resource Not Accepted List IE listing the corresponding PDU sessions rejected at the target NG-RAN. If the mobility restriction list IE - is included in the Handover Request message, the target NG-RAN node should - Storing the information received in the Mobility Restriction List IE in the UE context; - Use this information to determine the target of the UE during subsequent mobility actions for which the NG-RAN node provides the UE with information about the target of the mobility action, except when one of the PDU sessions has a specific ARP value (TS 23.501) (in In this case this information should not apply); - During dual connectivity operations, this information is used to select the appropriate SCG. - When moving the UE to RRC_INACTIVE, use this information to select the appropriate RNA(s) for the UE. - is not included in the Handover Request message, the target NG-RAN node SHOULD - Consider that no roaming and no access restrictions apply to the UE. If the Trace Activation IE is included in the Handover Request message, the target NG-RAN node shall initiate the requested trace functionality as specified in TS 32.422 (e.g. v17.8.0), if supported. If the Index of RAT / Frequency Selection Priority IE is included in the Handover Request message, the target NG-RAN node shall store this information and use it as defined in TS 23.501. If the UE Context Reference at S-NG-RAN IE is included in the Handover Request message, the target NG-RAN node may use it as specified in TS 37.340 (e.g. v17.2.0). In this case, the source NG-RAN node may expect the target NG-RAN node to include the UE Context Retention Indicator IE set to "True" in the Handover Request Confirm message, which it shall use as specified in TS 37.340. For each PDU Session, if the Network Instance IE is included in the PDU Session Resource List to Set IE and the Common Network Instance IE is not present, the target NG-RAN node shall use it when selecting transport network resources as specified in TS 23.501, if supported. Redundant transmission: - For each PDU Session, if the redundant UL NG-U UP TNL information IE at the UPF If a VLAN tag is included in the PDU Session Resource List to Set IE, the target NG-RAN node shall use it as the uplink termination point for redundantly delivered user plane data for the PDU sessions involved, if supported. - For each PDU Session, if the Additional Redundant UL NG-U UP TNL Information List IE at the UPF is included in the PDU Session Resource List IE to be set, the target NG-RAN node shall use them as uplink termination points for redundantly transmitted user plane data for the involved PDU Sessions, if supported. - For each PDU Session, if the Redundant Common Network Instance IE is included in the PDU Session Resource List to Set IE, the target NG-RAN node shall use it when selecting transport network resources for redundant delivery as specified in TS 23.501, if supported. - For each PDU Session, if the Redundant PDU Session Information IE is included in the PDU Session Resource List to be Set Up IE contained in the Handover Request message, the target NG-RAN node shall, if supported, store the received information in the UE context and establish a redundant user plane for the PDU Sessions involved as specified in TS 23.501. If the Session Pair ID IE is included in the Redundant PDU Session Information IE, the target NG-RAN node can store and use it to identify the paired PDU Session. If the TSC Traffic Characteristics IE is included in the QoS Flows to be Set Up List in the PDU Session Resources to be Set Up List IE, the target NG-RAN node shall use it as specified in TS 23.501, if supported. For each PDU session, if the Common Network Instance IE is included in the PDU Session Resource List IE to be set up, or is included in the Additional UL NG-U UP TNL Information List IE at the UPF, or is included in the Additional Redundant UL NG-U UP TNL Information List IE at the UPF, the target NG-RAN node shall use it when selecting transport network resources for the involved NG-U transport bearers as specified in TS 23.501, if supported. For each PDU Session for which the Security Indication IE is included in the PDU Session Resources List to be Set Up IE and either the Integrity Protection Indication IE or the Confidentiality Protection Indication IE is set to "Required", the target NG-RAN node shall perform user plane integrity protection or ciphering, respectively. If the NG-RAN node is not capable of performing user plane integrity protection or ciphering, it shall reject the setup of the PDU Session resources with an appropriate cause value. If the NG-RAN node is an ng-eNB, it shall reject all PDU sessions for which the Integrity Protection Indication IE is set to "Required". For each PDU Session for which the Security Indication IE is included in the PDU Session Resource List to be Set IE and either the Integrity Protection Indication IE or the Confidentiality Protection Indication IE is set to "Preferred", the target NG-RAN node shall perform user plane integrity protection or ciphering, respectively, if supported, and shall inform the SMF whether it succeeded with user plane integrity protection or ciphering for the security policy involved. For each PDU session for which the Maximum Integrity Protected Data Rate IE is included in the Security Indication IE in the PDU Session Resource List to be Set IE, the NG-RAN node shall store the corresponding information and, if integrity protection is to be performed for the PDU session, it shall implement the service corresponding to the received Maximum Integrity Protected Data Rate IE for the PDU session involved and the UE involved, as specified in TS 23.501. For each PDU Session for which the Security Indication IE is included in the PDU Session Resource List to be Set IE and either the Integrity Protection Indication IE or the Confidentiality Protection Indication IE is set to “Not Required”, the target NG-RAN node shall not perform user plane integrity protection or ciphering, respectively, for the PDU Session in question. For each PDU session, if an additional UL NG-U UP TNL Information List IE is included in the PDU Session Resource List IE to be set up contained in the Handover Request message, the target NG-RAN node may forward the UP transport layer information to the target S-NG-RAN node as the uplink termination point for the user plane data of this PDU session split in different tunnels. If the Location Reporting Information IE is included in the Handover Request message, the target NG-RAN node shall initiate the requested location reporting functionality as defined in TS 38.413. Upon receiving the UE History Information IE in the Handover Request message, the target NG-RAN node shall collect the information defined as mandatory in the UE History Information IE and, if supported, shall collect the information defined as optional in the UE History Information IE as long as the UE stays in one of its cells and store the collected information for future handover preparation. If the Trace Activation IE is included in the Handover Request message, the Handover Request message includes - MDT Activation IE set to "Immediate MDT and Trace", then the target NG-RAN node shall initiate the requested trace session and MDT session, if supported, as described in TS 32.422. - MDT Activation IE set to "Immediate MDT Only" or "Logged MDT Only", if supported, the target NG-RAN node shall initiate the requested MDT session as described in TS 32.422 and the target NG-RAN node shall ignore the Interface to Trace IE and Trace Depth IE. - MDT Location Information IE, within the MDT Configuration IE, the target NG-RAN node shall store this information, if supported, and take it into account in the requested MDT session. - MDT Activation IE set to "Immediate MDT Only" or "Logged MDT Only", and if the Signaling-based MDTPLMN List IE is included in the MDT Configuration IE, the target NG-RAN node can use it to propagate the MDT configuration as described in TS 37.320 (e.g. v17.1.0). - Bluetooth Measurement Configuration IE, within the MDT Configuration IE, if supported, the target NG-RAN node shall consider it for MDT configuration as described in TS 37.320. - WLAN Measurement Configuration IE, within the MDT Configuration IE, the target NG-RAN node shall consider it for MDT configuration, if supported, as described in TS 37.320. - Sensor Measurement Configuration IE, within the MDT Configuration IE, the target NG-RAN node shall consider it for MDT configuration as described in TS 37.320. -MDT Configuration IE, and if the target NG-RAN node is receiving the MDT configuration -EUTRA IE, or the target NG-RAN node is an ng-eNB that receives the MDT Configuration-NR IE, the target NG-RAN node shall store it as part of the UE context, And use it as described in TS 37.320. If the Management-based MDT PLMN List IE is included in the Handover Request message, the target NG-RAN node shall store the received information in the UE context, if supported, and use this information to allow subsequent selection of the UE for Management-based MDT as defined in TS 32.422. If the Handover Request message includes the Management-based MDTPLMN List IE, the target NG-RAN node shall store it in the UE context, if supported, and take it into account if it includes information about the PLMN serving the UE in the target NG-RAN node. If the Mobility Information IE is provided in the Handover Request message, the target NG-RAN node shall store this information, if supported. If supported, the target NG-RAN shall store the C-RNTI allocated at the source cell as received in the Handover Request message. Upon receiving the UE History Information IE from the UE in the Handover Request message, the target NG-RAN node shall store the collected information and use it for future handover preparations, if supported. For each QoS flow that has been successfully established in the target NG-RAN node, if the QoS Monitoring Request IE is included in the QoS Flow Level QoS Parameters IE contained in the Handover Request message, the target NG-RAN node shall store this information and, if supported, shall perform delay measurement and QoS monitoring as specified in TS 23.501. If the QoS Monitoring Report Frequency IE is included in the QoS Flow Level QoS Parameters IE contained in the Handover Request message, the target NG-RAN node shall store this information and, if supported, shall use this information for RAN part delay reporting. If the 5GC Mobility Restriction List Container IE is included in the Handover Request message, the target NG-RAN node shall store this information in the UE context, if supported, and use this information as specified in TS 38.300 (e.g. v17.2.0). V2X: - If the NR V2X Service Authorization IE is included in the Handover Request message and it contains one or more IEs set to "Authorized", the target NG-RAN node shall consider the UE to be authorized for the relevant service(s), if supported. - If the LTE V2X Service Authorization IE is included in the Handover Request message and it contains one or more IEs set to “Authorization”, the target NG-RAN, if supported The node shall consider the UE to be authorized for the relevant service(s). - If the NR UE Side Link Aggregation Maximum Bit Rate IE is included in the Handover Request message, the target NG-RAN node shall use the received value for sidelink communications of the involved UEs in the Network Scheduling Mode for NR V2X services, if supported. - If the LTE UE Side Link Aggregation Maximum Bit Rate IE is included in the Handover Request message, the target NG-RAN node shall use the received value for sidelink communications of the involved UEs in the Network Scheduling Mode for LTE V2X services, if supported. 5G ProSe: - If the 5G ProSe Authorization IE is included in the Handover Request message and it contains one or more IEs set to "Authorized", the target NG-RAN node shall consider the UE to be authorized for the related service(s), if supported. - If the 5G ProSe UEPC5 Aggregate Maximum Bit Rate IE is included in the Handover Request message, the target NG-RAN node shall use the received value for sidelink communications of the involved UEs in the network scheduling mode for 5G ProSe services, if supported. - If the 5G ProSe PC5 QoS Parameters IE is included in the Handover Request message, the target NG-RAN node shall use it as defined in TS 23.304 (e.g. v17.4.0), if supported. If the PC5 QoS Parameters IE is included in the Handover Request message, the target NG-RAN node shall use it as defined in TS 23.287 (e.g. v17.4.0), if supported. If, for a given DRB, the DAPS Request Information IE is included in the Handover Request message, the target NG-RAN node shall consider that the request involves a DAPS handover for that DRB, as described in TS 38.300. Therefore, the target NG-RAN node shall include the DAPS Response Information IE in the Handover Request Confirm message. If the Maximum Number of CHO Preparation IE is included in the Conditional Handover Information Confirm IE contained in the Handover Request Confirm message, the source NG-RAN node SHOULD NOT prepare more candidate target cells for CHO of the same UE towards the target NG-RAN node than the number indicated in the IE. If the Estimated Probability of Arrival IE is included in the Conditional Handover Information Request IE included in the Handover Request message, the target NG-RAN node can use this information to allocate the necessary resources for the incoming CHO. If the IAB Node Indication IE is included in the Handover Request message, the target NG-RAN node shall consider the handover to be directed to the IAB node, if supported. Additionally: - If the No PDU Session Indication IE is included in the Handover Request message, the target NG-RAN node shall, if supported, treat the UE as an IAB node without any PDU Session activated and ignore the PDU Session Resource List to Set IE and shall not take any action regarding the PDU Session Indication IE. Subsequently, the source NG-RAN node shall ignore the Admit Added PDU Session Resource List IE in the Handover Request Confirm message, if supported. If the UE Radio Capability ID IE is included in the Handover Request message, the target NG-RAN node shall store this information in the UE context, if supported, and use this information as defined in TS 23.501 and TS 23.502 (e.g. v17.6.0). If, for a given QoS flow, the Source DL Forwarding IP Address IE is included in the Data Forwarding and Offload Information IE from the source NG-RAN node in the PDU Session Resources List to Set Up IE contained in the Handover Request message, the target NG-RAN node shall store this information, if supported, and use it as part of its ACL functionality configuration actions if such ACL functionality is deployed. If the MBS Session Information List IE is included in the Handover Request message, the target NG-RAN node shall establish MBS session resources as specified in TS 23.247 (e.g. v17.4.0) and TS 38.300, if supported, if applicable. If the Handover Request message includes the MBS Area Session ID IE, the target NG-RAN, if supported, shall use this information as an indication of the MBS Area Session ID from which the UE is to be handed over. For each MBS session for which the Active MBS Session Information IE is included in the MBS Session Information Item List IE, the target NG-RAN, if supported, shall use this information to configure the corresponding MBS session resources. If supported, the target NG-RAN node shall consider MBS sessions that do not include the Active MBS Session Information IE to be inactive. If the Handover Request Confirm message contains the MBS Data Forwarding Response Information IE in the MBS Session Information Response List IE, the source NG-RAN node shall use this information to forward the MBS service to the target NG-RAN node. If the MBS Session Associated Information List IE is included in the PDU Session Resources List IE to be set up in the Handover Request message, the target NG-RAN node shall use the information contained in the Associated QoS Flow Information List IE as specified in TS 23.247, if supported. For each MRB indicated in the MBS Mapping and Data Forwarding Request Information IE from the source NG-RAN node, the target NG-RAN node shall use the MRBID IE and, if included, the MRB Progress Information IE including the highest PDCP SN of packets for the MRB that have been delivered to the UE to decide whether to apply data forwarding for that MRB and to set up the corresponding resources. For each MRB in the MBS Data Forwarding Response Information IE from the target NG-RAN node in the Handover Request Confirm message, the source NG-RAN node shall start forwarding data towards the indicated DL Forwarding UP TNL information. If the MRB Progress Information IE is included, the source NG-RAN node may use this information to determine when to stop data forwarding. If the Time Synchronization Assistance Information IE is included in the Handover Request message, the target NG-RAN node shall store this information in the UE context, if supported, and use it as defined in TS 23.501. If the QMC Configuration Information IE is included in the Handover Request message, the target NG-RAN node shall take it into account for QoE measurement handling, if supported, as described in TS 38.300. If the UE Slice Maximum Bit Rate List IE is included in the Handover Request message, the target NG-RAN node shall store the received UE Slice Maximum Bit Rate List in the UE context, if supported, and use the received UE Slice Maximum Bit Rate value for each S-NSSAI of the involved UEs as specified in TS 23.501. If the Cell Trajectory Prediction IE is included in the Handover Request message, the target NG-RAN node considers the contents of this list as the cell trajectories predicted by the source NG-RAN node and may use it for e.g. mobility decisions. Interaction with SN status transmission process: If the UE Context Retention Indicator IE set to TRUE and the DRB IE transferred to the MN are included in the Handover Request Confirm message, the source NG-RAN node shall include the uplink / downlink PDCP SN and HFN status received from the S-NG-RAN node in the SN status transfer procedure towards the target NG-RAN node, if supported, as specified in TS 37.340. 8.2.1.3 Unsuccessful Operation <Image omitted> Figure 8 .2.1.3-1: Switch preparation, unsuccessful operation If the target NG-RAN node does not admit at least one PDU Session resource, or a failure occurs during handover preparation, the target NG-RAN node shall send a Handover Preparation Failure message to the source NG-RAN node. This message shall include the Cause IE with an appropriate value. If the Conditional Handover Information Request IE is included in the Handover Request message and the target NG-RAN node rejects the handover or a failure occurs during handover preparation, the target NG-RAN node shall include the Requested Target Cell ID IE in the Handover Preparation Failure message. Interaction with the switch cancellation process: If the timer TXn in the source NG-RAN node RELOCprep If there is no response to the Handover Request message from the target NG-RAN node before the expiration date, the source NG-RAN node shall cancel the Handover Prepare procedure towards the target NG-RAN node by initiating a Handover Cancel procedure with an appropriate value for the Cause IE. The source NG-RAN node shall ignore any Handover Request Confirm or Handover Prepare Failure messages received after initiation of the Handover Cancel procedure and remove any references and release any resources related to the signalling associated with the involved Xn UE. 8.2.1.4 Abnormal conditions If the supported cipher algorithms defined in the UE Security Capability IE in the UE Context Information IE, plus the mandatory support of EEA0 and NEA0 algorithms in all UEs (TS 33.501), do not match any of the allowed algorithms defined in the configured list of allowed cipher algorithms in the NG-RAN node (TS 33.501), the NG-RAN node shall reject the procedure with a Handover Preparation Failure message. If the supported integrity algorithms defined in the UE Security Capability IE in the UE Context Information IE, plus the mandatory support of EIA0 and NIA0 algorithms in all UEs (TS 33.501), do not match any of the allowed algorithms defined in the configured list of allowed integrity protection algorithms in the NG-RAN node (TS 33.501), the NG-RAN node shall reject the procedure with a HANDOVER PREPARE FAILURE message. If the CHO Trigger IE is set to "CHO-Replace" in the Handover Request message, but CHO is not prepared for the included target NG-RAN node UE XnAP ID, or the candidate cell in the Target Cell ID IE is not prepared using the same UE-associated signalling connection, the NG-RAN node shall reject the procedure with a Handover Preparation Failure message. If the Handover Request message includes information of a PLMN that does not serve the UE in the target NG-RAN node in the Management-based MDT PLMN List IE, the target NG-RAN node shall ignore the information of this PLMN in the Management-based MDT PLMN List. <<<<<<<<<<<<<<<<<<<<<<End of First Change>>>>>>>>>>>>>>>> -Text omitted- <<<<<<<<<<<<<<<<<<<<<<Second Change>>>>>>>>>>>>>>> 9.1.1.1 Switch Request This message is sent by the source NG-RAN node to the target NG-RAN node to request that resources be prepared for handover. Direction: Source NG-RAN node Target → NG-RAN node. <<<<<<<<<<<<<<<<<<<<<<End of Second Change>>>>>>>>>>>>>>> -Text omitted- <<<<<<<<<<<<<<<<<<<<<<Third Change>>>>>>>>>>>>>>>>>> 9.2.3.x Cell Trajectory Prediction The Cell Trajectory Prediction IE contains a list of predicted NR cells that the UE will move to after handover from the source NG-RAN node. 9.2.3.y Predicted trajectory cell information The predicted trajectory cell information includes the cell ID of the predicted cell used for trajectory prediction. <<<<<<<<<<<<<<<<<<<<<<End of the third change>>>>>>>>>>>>>> -Text omitted- <<<<<<<<<<<<<<<<<<<<<<Fourth Change>>>>>>>>>>>>>>>>>> 9.3.4PDU Definition -Text omitted- -Text omitted- -Text omitted- 9.2.5 Information element definition -Text omitted- maxnoofSMBR, maxnoofCellsTrajectoryPredict -Text omitted- -Text omitted- -Text omitted- 9.3.7 Constant Definition -Text omitted- --********************************* -- --Lists -- --********************************* -Text omitted- maxnoofSMBR INTEGER ::= 8 maxnoofCellsTrajectoryPredict INTEGER::=8 --*********************************** -- --IEs -- ―-********************************* -Text omitted- <<<<<<<<<<<<<<<<<<<End of changes>>>>>>>>>>>>>>>>

Claims

1. A method performed by a first network node, the method comprising: Obtaining (1412) a user equipment UE trajectory prediction; transmitting (1414) the UE trajectory prediction and an indication requesting feedback regarding the UE trajectory prediction to a second network node, wherein the indication requesting feedback includes assistance information for associating an identifier with the requested feedback; and Feedback regarding the UE trajectory prediction is received (1416) from a third network node based on the transmitted assistance information.

2. The method according to claim 1, wherein The second network node and the third network node are the same network node.

3. The method according to any one of claims 1 to 2, wherein The assistance information includes an identifier for associating the requested feedback with the UE trajectory prediction.

4. The method according to claim 3, wherein: The identifier includes an identifier of the UE.

5. The method according to any one of claims 3 to 4, wherein The received feedback includes the identifier for associating the requested feedback with the UE trajectory prediction.

6. The method according to any one of claims 1 to 5, wherein The assistance information includes an identifier of a network node for receiving the feedback.

7. The method according to any one of claims 1 to 6, wherein Receiving the feedback includes receiving artificial intelligence / machine learning assisted data update messages.

8. The method according to any one of claims 1 to 7, wherein The assistance information includes an indication to request feedback after a threshold number of handovers.

9. The method according to any one of claims 1 to 8, wherein The received feedback includes a list of UE trajectory cells.

10. The method according to any one of claims 1 to 9, wherein The received feedback includes the dwell time of each cell in the UE trajectory cell list.

11. The method of any one of claims 1-10, further comprising utilizing the received feedback to train an artificial intelligence or machine learning model.

12. A first network node (160), comprising a processing circuit (170), the processing circuit (170) being operable to: Obtaining a user equipment UE trajectory prediction; transmitting the UE trajectory prediction and an indication requesting feedback regarding the UE trajectory prediction to a second network node, wherein the indication requesting feedback includes assistance information for associating an identifier with the requested feedback; and Feedback regarding the UE trajectory prediction is received from a third network node based on the transmitted assistance information.

13. The network node of claim 12, the processing circuit being further operable to perform the steps of any one of claims 2-11.

14. A method performed by a second network node, the method comprising: receiving (1512) a user equipment (UE) trajectory prediction and an indication requesting feedback regarding the UE trajectory prediction, wherein the indication requesting feedback includes assistance information for associating an identifier with the requested feedback; as well as Feedback regarding the UE trajectory prediction is transmitted (1514) to a first network node based on the assistance information.

15. The method of claim 14, wherein: The first network node comprises a Radio Access Network (RAN) node or an Operation and Management (OAM) node.

16. The method according to any one of claims 14 to 15, wherein The assistance information includes an identifier for associating the requested feedback with the UE trajectory prediction.

17. The method of claim 16, wherein: The identifier includes an identifier of the UE.

18. The method according to any one of claims 16 to 17, wherein The transmitted feedback includes the identifier for associating the requested feedback with the UE trajectory prediction.

19. The method according to any one of claims 14 to 18, wherein The assistance information includes an identifier of a network node used to transmit the feedback.

20. The method according to any one of claims 14 to 19, wherein Transmitting the feedback includes transmitting an artificial intelligence / machine learning assisted data update message.

21. The method of any one of claims 14 to 20, wherein: The assistance information includes an indication to request feedback after a threshold number of handovers.

22. The method of any one of claims 14 to 21, wherein The transmitted feedback includes the UE trajectory cell list.

23. The method of any one of claims 14 to 22, wherein: The transmitted feedback includes the dwell time for each cell in the UE trajectory cell list.

24. A second network node (160), the second network node (160) comprising a processing circuit (170), the processing circuit (170) being operable to: receiving an indication of a user equipment (UE) trajectory prediction and requesting feedback on the UE trajectory prediction; and Feedback regarding the UE trajectory prediction is transmitted to the first network node.

25. The network node of claim 24, the processing circuit being further operable to perform the steps of any one of claims 15-23.

Images