WO2025087853A1

WO2025087853A1 - Beam-level user trajectory information collection

Info

Publication number: WO2025087853A1
Application number: PCT/EP2024/079703
Authority: WO
Inventors: Ethiraj Alwar; Anna Pantelidou
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2023-10-24
Filing date: 2024-10-21
Publication date: 2025-05-01
Anticipated expiration: 2026-04-24

Abstract

Various example embodiments relate to a base station method for collection of beam-level user trajectory information, and a base station and computer program product configured to perform that method. One aspect may provide a base station comprising: comprising: circuitry configured to obtain an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; circuitry configured to collect beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and circuitry configured to report collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event. The base station may comprise a distributed unit, configured to obtain the indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection from a centralised unit and configured to report the collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event to the centralised unit from which the indication was obtained. Accordingly, aspects and embodiments may provide a mechanism for performing appropriately cascaded data collection by using, for example, a cell level event, to serve as a trigger for collection of higher granularity, beam-level data.

Description

BEAM-LEVEL USER TRAJECTORY INFORMATION COLLECTION

TECHNOLOGICAL FIELD

Various example embodiments relate to a base station method for collection of beamlevel user trajectory information, and a base station configured to perform that method.

BACKGROUND

To meet the 5G network key performance requirements and increasing demand stemming from unprecedented growth of mobile network subscribers, millions of base stations (BSs) are being deployed in wireless communication networks. Such rapid growth brings associated issues relating to optimisation of a network.

Artificial Intelligence and Machine Learning (AIML) techniques are candidate methods to automate some degree of network optimisation. A 3GPP Technical Report (TR 37.817) identified various possible use cases for AIML enabled Radio Access Networks (RAN). Those use cases include: network energy saving optimisation, load balancing optimisation, and mobility optimisation.

In support of AIML techniques, collection of additional or enhanced data within a wireless communication network may be required.

BRIEF SUMMARY

The scope of protection sought for various example embodiments of the invention is set out in the independent claims. The example embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.

According to various, but not necessarily all, example embodiments there is provided a base station, comprising: at least one processor; and at least one memory storing instructions that when executed by the at least one processor cause the base station at least to perform: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event. The base station may comprise a distributed unit, configured to obtain the indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection from a centralised unit and configured to report the collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event to the centralised unit from which the indication was obtained.

In some embodiments, the base station or distributed unit of the base station is caused to perform: the reporting by transmitting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event to a centralised unit associated with the base station.

In some embodiments, the one or more trigger event comprises a cell-level event.

In some embodiments, the one or more trigger event comprises at least one of the following: a cell-level network energy saving action, or a cell-level radio link failure rate passing a predetermined threshold, or a cell-level average time of stay passing a predetermined threshold, or average time of stay of a user in a cell passing a predetermined threshold.

In some embodiments, passing may comprise exceeding a threshold.

In some embodiments, passing may comprise falling below a threshold.

In some embodiments, the base station or distributed unit of the base station is caused to perform: receiving an indication that the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection has occurred, and collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event based upon receipt of that indication.

In some embodiments, the one or more trigger event comprises at least one of the following: a beam-level event, or user-level event.

In some embodiments, the one or more trigger event comprises at least one of the following: a beam-level network energy saving action executed by a base station or distributed unit of the base station, or a beam-level mobility action, or a beam-level radio link failure rate passing a predetermined threshold, or a user-level radio link failure rate passing a predetermined threshold, or a user-level average time of stay in a beam passing a predetermined threshold.

In some embodiments, passing may comprise exceeding a threshold.

In some embodiments, passing may comprise falling below a threshold.

In some embodiments, the base station or distributed unit of the base station is caused to perform: monitoring for occurrence of the one or more trigger event; and collecting beam-level user trajectory information based upon the result of that monitoring.

In some embodiments, monitoring for occurrence comprises directly monitoring for occurrence of the one or more trigger event at a beam-level.

In some embodiments, the distributed unit is caused to perform: transmitting an indication of occurrence of the one or more trigger event to a control unit or centralised unit associated with the base station.

In some embodiments, the base station or distributed unit of the base station is caused to perform: receiving a request for beam-level user trajectory information collection in relation to the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection, and acknowledging beam-level user trajectory information collection capability in response to the request.

In some embodiments, the base station or distributed unit of the base station is caused to perform: receiving a request for beam-level user trajectory information collection in relation to the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection, wherein the request for beam-level user trajectory information collection comprises: an indication of one or more beam in relation to which to collect beam-level user trajectory information, or an indication of one or more user in relation to which to collect beam-level user trajectory information.

In some embodiments, the indication of one or more beam in relation to which to collect beam-level user trajectory information comprises at least one of the following: an identifier of at least one cell for which beam-level user trajectory information is to be collected, or an identifier of at least one beam for which beam-level user trajectory information is to be collected, or an identifier of at least one user for which beam-level user trajectory information is to be collected.

According to various, but not necessarily all, example embodiments there is provided a base station or distributed unit of a base station, comprising: means for obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; means for collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and means for reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event.

The means may perform the optional features set out in relation to the apparatus mentioned above.

According to various, but not necessarily all, example embodiments there is provided a base station or distributed unit of a base station, comprising: circuitry configured to obtain an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; circuitry configured to collect beamlevel user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and circuitry configured to report collected beamlevel user trajectory information in relation to one or more beam associated with the one or more trigger event.

The circuitry may be configured perform the optional features set out in relation to the apparatus mentioned above.

According to various, but not necessarily all, example embodiments there is provided a method performed by a base station or distributed unit of a base station, the method comprising: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event. The method may be performed by a distributed unit of a base station, configured to obtain the indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection from a centralised unit and configured to report the collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event to the centralised unit from which the indication was obtained.

In some embodiments, the method may comprise: reporting by transmitting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event to a centralised unit associated with the base station.

In some embodiments, passing may comprise exceeding a threshold.

In some embodiments, passing may comprise falling below a threshold.

In some embodiments, the method may comprise: receiving, at a base station or distributed unit of a base station, an indication that the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection has occurred, and collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event based upon receipt of that indication.

In some embodiments, the one or more trigger event comprises at least one of the following: a beam-level network energy saving action executed by a base station, or a beam-level mobility action, or a beam-level radio link failure rate passing a predetermined threshold, or a user-level radio link failure rate passing a predetermined threshold, or a user-level average time of stay in a beam passing a predetermined threshold.

In some embodiments, passing may comprise exceeding a threshold.

In some embodiments, passing may comprise falling below a threshold.

In some embodiments, the method may comprise: monitoring at a distributed unit of a base station for occurrence of the one or more trigger event; and collecting beam-level user trajectory information based upon the result of that monitoring.

In some embodiments, monitoring for occurrence comprises directly monitoring at a distributed unit of a base station for occurrence of the one or more trigger event at a beam-level.

In some embodiments, the method may comprise: transmitting an indication of occurrence of the one or more trigger event to a control unit or centralised unit of a base station associated with the base station.

In some embodiments, the method may comprise: receiving, at a distributed unit of a base station, a request for beam-level user trajectory information collection in relation to the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection, and acknowledging beam-level user trajectory information collection capability in response to the request.

In some embodiments, the method may comprise: receiving a request for beam-level user trajectory information collection in relation to the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection, wherein the request for beam-level user trajectory information collection comprises: an indication of one or more beam in relation to which to collect beam-level user trajectory information, or an indication of one or more user in relation to which to collect beamlevel user trajectory information.

According to various, but not necessarily all, example embodiments there is provided non-transitory computer readable medium comprising program instructions stored thereon for performing at least the following: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event and reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event.

The instructions may be for performing the optional features set out in relation to the method mentioned above.

According to various, but not necessarily all, example embodiments there is provided A computer program product operable, when executed on a computer, to perform the steps of: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event and reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event.

The computer program product may be operable, when executed on a computer, to perform the optional features set out in relation to the method mentioned above.

Further particular and preferred aspects are set out in the accompanying independent and dependent claims. Features of the dependent claims may be combined with features of the independent claims as appropriate, and in combinations other than those explicitly set out in the claims.

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

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

FIG. 1 illustrates schematically a functional framework for use of AIML techniques in support of Radio Access Network (RAN) intelligence as envisaged by a 3GPP Technical Report (TR 37.817);

FIG. 2 relates to a scenario in which AI/ML Model Training functionality is located in the Operations, Administration and Maintenance (OAM) layer of the communication network and AI/ML Model Inference functionality is located in a lower layer, for example, at a gNB;

FIG. 3 relates to a scenario in which AI/ML Model Training functionality and AI/ML Model Inference functionality are located in a lower layer of a communication network, for example, at a gNB;

FIG. 4 is a scheduling diagram illustrating schematically messaging according to one arrangement between a gNB-CU-CP and a gNB-DU;

FIG. 5 is a scheduling diagram illustrating schematically one possible implementation for beam-level UE trajectory data transfer between a gNB-DU and a gNB-CU-CP;

FIG. 6 is a signalling diagram relating to an implementation in which beam-level data collection is triggered by a cell-level event detectable by a gNB-CU;

FIG. 7 is a signalling diagram relating to an implementation in which beam-level data collection is triggered by a UE-level event detectable by a gNB-CU;

FIG. 8 is a signalling diagram relating to an implementation in which beam-level data collection is triggered by a gNB-DU detectable event;

FIG. 9 illustrates schematically some components of a wireless communication network including nodes according to some arrangements; and

FIG. 10 illustrates schematically steps of methods performed at nodes in accordance with some arrangements.

DETAILED DESCRIPTION

Before discussing the example embodiments in any more detail, first an overview of the context in which the mechanisms and approaches of arrangements is to be understood will be provided.

STRUCTURE OF AIML IN RAN

FIG. 1 illustrates schematically a functional framework for use of AIML techniques in support of Radio Access Network (RAN) intelligence as envisaged by a 3GPP Technical Report (TR 37.817). The framework is shown as functional blocks. The data collection block 10 is illustrative of a data collection function. The data collected can be used to provide training data to a “model training” functional block 20 and/or inference data to a “model inference” functional block 30. The model training block 20 is configured to perform AI/ML model training, validation, and testing. The model training block 20 may be configured to generate model performance metrics as part of a model testing procedure. The model training block may also be responsible for data preparation. Data preparation may, for example, comprise steps relating to data pre-processing and/or cleaning, formatting, and/or transformation. Data preparation may be performed upon training data delivered by the data collection function, as required.

Once a model is trained by the model training block, a model deployment or model update process can be used to deploy a trained, validated, and tested AI/ML model to a model inference functional block 30 or to deliver an updated model to the model inference functional block. The model inference block is typically configured to provide AI/ML model inference output. In other words, based on inference data provided to the model inference block 30 by the data collection block 10, the inference block 30 may be configured to output, using the model generated by the model training block 20, one or more prediction or decision. The model inference function 30 may be configured to provide model performance feedback to the model training functional block 20 when, or if, applicable. The model performance feedback may be used for monitoring the performance of the AI/ML model, when available.

The model inference function may also be responsible for data preparation, for example, data pre-processing and/or cleaning, formatting, and/or transformation, of inference data delivered to the model inference function 30 by the data collection function 10, as or if required.

The actor or actuation function 40 is a function configured to receive output from the model inference function 30. Based upon the output from the model inference function 30, the actuation function 40 may be configured to trigger or perform a corresponding or associated action. The actuation function 40 may be configured to trigger one or more actions as a direction or instruction to one or more other entity within the network or to itself. In the system illustrated by FIG. 1 , feedback may be used to improve overall operation of the system. The feedback may comprise information which may be useful to derive training data, inference data or information relevant to monitoring performance of an AI/ML Model and its impact to the network through, for example, updating of Key Performance Indicators (KPIs) and/or performance counter(s).

The model training and model inference functionalities may be located at, or across, one or more entity or location within a network. By way of example, two options relating to the model training and model inference functionalities are described in more detail:

FIG. 2 relates to a scenario in which AI/ML Model Training functionality is located in the Operations, Administration and Maintenance (OAM) layer of the communication network and AI/ML Model Inference functionality is located in a lower layer, for example, at a gNB.

FIG. 3 relates to a scenario in which AI/ML Model Training functionality and AI/ML Model Inference functionality are located in a lower layer of a communication network, for example, at a gNB.

FIG. 2 is a sequence diagram illustrating schematically interactions between network nodes in a network having AI/ML model training functionality in the OAM layer of the network in support of energy saving processes.

The network shown schematically in FIG. 2 comprises user equipment (UE) 100, Next Generation Radio Access Network Nodes (NG-RAN), 200a, 200b, and the Operations, Administration and Maintenance layer 300 of the network. As shown in FIG. 2 and as described in 3GPP TR 37.817, steps SO to S14 relate to implementation of AI/ML in support of energy saving in the network.

SO: Although described in relation to configuration of NG-RAN node 200a, NG-RAN node 200b may also be configured with an AI/ML model, received from OAM 300.

S1 : NG-RAN node 200a configures UE 100 with a measurement configuration.

S2: UE 100 performs measurement(s) in accordance with the measurement configuration.

S3: The UE 100 sends a measurement report to NG-RAN node 200a. S4: NG-RAN node 200a passes relevant input data for AI/ML model training to OAM 300.

S5: NG-RAN node 200b passes relevant input data for AI/ML model training to OAM 300.

S6: OAM 300 performs AI/ML model training.

S7: Having created, or updated the AI/ML model, the OAM 300 deploys or updates the model to NG-RAN node 200a.

S8: NG-RAN node 200b passes input data for energy saving model inference to NG-RAN node 200a.

S9: UE 100 passes measurement report data for energy saving model inference to NG-RAN node 200a.

S10: NG-RAN node 200a performs model inference.

S11 : NG-RAN node 200a may be configured to pass model performance feedback to OAM 300.

S12: In response to model inference performed by NG-RAN node 200a, one or more of UE 100, NG-RAN node 200a and/or NG-RAN node 200b may perform a network energy saving action.

S13: NG-RAN node 200b provides feedback to OAM 300.

S14: NG-RAN node 200a provides feedback to OAM 300.

FIG. 3 is a sequence diagram illustrating schematically interactions between network nodes in a network having AI/ML model training and model inference functionality in a lower network node layer in support of energy saving processes. As shown in FIG. 3 and as described in 3GPP TR 37.817, steps TO to T9 relate to implementation of AI/ML in support of energy saving in the network.

TO: Although described in relation to configuration of NG-RAN node 200a, NG-RAN node 200b may also be configured with an AI/ML model.

T 1 : NG-RAN node 200a configures UE 100 with a measurement configuration.

T2: UE 100 performs measurement(s) in accordance with the measurement configuration.

T3: The UE 100 sends a measurement report to NG-RAN node 200a.

T4: NG-RAN node 200b passes relevant input data for AI/ML model training to NG- RAN node 200a.

T5: NG-RAN 200a performs AI/ML model training. T6: NG-RAN node 200b passes input data for energy saving model creation/updates and model inference to NG-RAN node 200a.

T7: UE 100 passes measurement report data for energy saving model inference to NG-RAN node 200a.

T8: NG-RAN node 200a performs model inference.

T9: In response to model inference performed by NG-RAN node 200a, one or more of UE 100, NG-RAN node 200a and/or NG-RAN node 200b may perform a network energy saving action.

T10: NG-RAN node 200b provides feedback to NG-RAN node 200a.

UE TRAJECTORY PREDICTION

UE Trajectory Prediction at a cell level is already agreed in 3GPP TR 37.817. UE mobility history information can be collected from UE. The UE mobility history information may include, for example, a UE visited cell list and/or an associated time of stay in each visited cell. That UE mobility history information can be used as an input parameter for AI/ML training.

Typically, data collected which forms the UE mobility history information is collected at a UE without any network control or configuration. Full UE mobility history is typically collected by a NG-RAN node when a UE reports such mobility history information data availability.

AI/ML techniques applied to UE mobility history information to make a UE trajectory prediction output can be used in support of Xn Application Protocol (XnAP) : Handover Procedure to enable appropriate early resource reservation at a target.

It is possible to implement AI/ML approaches with a focus on cell level predicted UE trajectory. Such approaches may use UE mobility information such as, for example, visited cells and time spent in each cell. Mechanisms and approaches described recognise that AI/ML implementations which can predict UE Trajectory at a beam level may have relevance in other scenarios, for example, in the context of lower layer energy saving decisions made at a gNB Distributed Unit (gNB-DU) where a gNB-DU may be configured to decide to switch-off a beam. Described approaches recognise that access to predicted UE trajectory at a beam level may provide information relating to how load is expected to change on a beam level to enable intelligent decision making in relation to actions such as switching off a beam. UE trajectory projection at a beam level is also of relevance in relation to beam prediction performed by AI/ML in support of physical layer enablers to allow a UE or a NG-RAN node to predict future beam sequences.

In support of AI/ML UE trajectory projection, appropriate data collection is performed. Data collection in a Radio Access Network (RAN) may be performed on a UE-based approach and/or a network-based approach.

UE-based data collection typically exhibits some or all of the following features: UE- based UE mobility history data collection is typically such that a UE does not collect information related to visited beams and time spent on a beam. If the mechanism to collect mobility history information from the UE is enhanced to also consider trajectory information on a beam level it would not represent an efficient mechanism for data collection. In particular, there is no network control and configuration of UE collection, and all UE(s) supporting UE mobility history are assumed to collect mobility history information at a cell level which would have negative impacts on the UE side due to processing and memory overheads at the UE. This would further have negative impacts on the network side due to possibly unnecessary data collection and storage required at the NG-RAN Node. Furthermore, UE mobility history does not typically support data relating to a finer granularity than cell-level information.

In a typical 5G network, a 5G base station node called a gNB can be considered generally as two physical entities: a centralized unit (CU) and distributed unit (DU). The CU is configured to provide support for higher layers of the protocol stack: Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers. Within the CU, functionality may be split between a Control Plane (CP) User Plane (UP). For example, a CU-CP may be configured to handle the RRC and PDCP control layers and a CU-UP may be configured to handle the PDCP user plane data layer. The DU is configured to provide support for the lower layers of the protocol stack: Radio Link Control (RLC), Media Access Control (MAC) and Physical layers. There is a single CU for each gNB. One CU controls multiple DUs.

Network-based data collection typically exhibits some or all of the following features: a gNB-DU manages L2 beam-based mobility and a gNB-CU manages L3 cell-based mobility. However, when it comes to predicted cell-based and predicted-beam based trajectory there is a strong correlation to corresponding data collection in support of appropriate model training. Accordingly, cell based trajectory prediction may be insufficient in support of prediction of beam-based action(s).

Approaches described in more detail below recognise that because beam information may change very frequently, it is possible that it may be preferable to collect such information only when specific triggers are met, for example, triggers may depend on a specific prediction or event pertaining to an overarching cell-based trajectory. By way of example, beam-based trajectory information may be collected only when a UE visits a certain cell ID. By way of further example, beam-based trajectory information may be collected only when a UE visits a cell that is in a certain energy saving state, for example, when a UE reaches a cell that is operating in an energy saving mode or is in a specific energy state, for example, a cell operating in a discontinuous transmission or reception mode (DTX/DRX). In a yet further another example, beam-based trajectory information may be collected based on AI/ML model scope. For example, the beambased trajectory information may be collected only when a beam-level UE trajectory ML model is deployed in a network. In a yet further example, beam-level data collection may be triggered based upon one or more UE-specific event, for example, a Radio Link failure (RLF) event on a given cell.

Currently, such dynamic implementation of data collection is not supported because cell-based trajectory prediction is a gNB-CU functionality and no mechanism exists to enable a gNB-CU to configure and control beam-based data collection based on celllevel events or predictions.

A gNB-DU can monitor certain beam level events. However, currently a gNB-DU cannot trigger data collection based upon a configuration that depends on the occurrence of specific events. Mechanisms and approaches described recognise that it could be useful to trigger data collection in relation to a specific beam(s) when a certain event(s) is observed, for example, when a beam change rate exceeds a certain limit or preselected threshold.

Mechanisms and approaches described in detail below may enable a network to efficiently collect data related to a UE predicted trajectory and support collection of fine granularity UE trajectory information. Some implementations, for example, are such that collection of information based at a beam level, can be triggered based upon a coarser granularity trigger, for example, a UE trajectory prediction or event detected at a cell level. Mechanisms and approaches described relate to triggering of finer granularity UE information, for example, beam -based UE information, based upon less granular UE information, for example, cell-based UE information. In other words, mechanisms described use one or more trigger to create a cascaded UE trajectory data collection and exchange. The trigger may, for example, be a cell-level trigger. In various described implementations, the trigger may be gNB-CU-based or gNB-DU-based. gNB-CU-based Triggering

According to implementations associated with a gNB-CU-based trigger for collection of additional information relating to UE trajectory, a gNB-CU (-CP) may be configured to trigger a reguest for data collection pertaining to beams, for example, comprising information relating to a UE trajectory at a beam level, from a gNB-DU. The gNB-CU trigger may, for example, be based on L3 events.

L3 trigger events may, for example, comprise the following:

Cell Level Network Energy Saving Action

A cell level network energy saving action may comprise a trigger according to which a gNB-CU is configured to trigger beam-level trajectory information collection. Because a gNB-CU-CP may be responsible for triggering a cell level network energy saving action, a gNB-CU-CP may be configured to issue a UE trajectory data collection reguest to a gNB-DU. The reguest may comprise a list of cell(s) a gNB-CU-CP plans to de-activate. In response to the received reguest, a gNB-DU may be configured to collect beam trajectory information relating to UE(s) operating in the indicated cell(s) and send it to, for example, the gNB-CU-CP. The gNB-CU-CP may be configured to further analyze the received details relating to UE distribution over beams. In some implementations, for example, if it is determined that a UE distribution over beams is indicative of one or more specific trends (e.g UE(s) are primarily distributed only on a few beams) a gNB-CU-CP may be configured to co-ordinate with gNB-DU to decide whether a beam level network saving action can be applied instead of a cell level deactivation.

Cell Level Average Time of Stay

According to one implementation, if UE average time of stay in a cell exceeds a predetermined threshold (meaning that many UE(s) are staying in a cell for a longer than expected time) or decreases below a preselected threshold (meaning that UE(s) are staying in a cell for a short duration only) a gNB-Cll may be configured to trigger collection of beam-level UE trajectory information from gNB-Dll. The thresholds may be configured by a network operator. Further analysis of UE behaviour across beam(s) within the cell may be performed. For example, if the average time of stay for a UE in a cell is exceeded, a gNB-CU-CP may be configured to trigger beam-level UE trajectory information collection from a gNB-DU to enable assessment of an average time of stay trend/pattern in different beams of a cell. Based upon collected beam-level information, a gNB-CU-CP may be able to identify whether a cell level average time of stay is heavily impacted because a time of stay on one or more specific beam within a cell happens to be higher or lower than expected.

Radio Link Failure (RLF) Rate

According to one implementation, if an average number of RLF events, for example, as detected by a RAN Node or detected or reported by UE, for a given cell exceeds a threshold (configured by operator), a gNB-CU-CP may be configured to trigger beamlevel trajectory data collection from the relevant specific cell. That beam-level information may be analysed to determine whether there is a RLF trend across different beams of the relevant cell. For example, a gNB-CU-CP may be configured to identify any trend regarding whether the RLF events are occurring in all beams of a cell or whether RLF events are distributed primarily on one or more particular beam of the cell. Accordingly, a gNB-CU-CP may be configured to identify, based on beam-level data, whether a beam-specific configuration is a candidate for adjustment. gNB-DU-based Triggering

According to implementations associated with a gNB-DU-based trigger for collection of additional information relating to UE trajectory, a gNB-DU may be configured to trigger a reguest for data collection pertaining to beams by gNB-DU- based events. Those events may be selected by a configuration received or communicated to the gNB-DU from a gNB-CU. By way of example, a gNB-DU may trigger collection of beam-level information (e.g.: pertaining to a UE beam trajectory) based on one or more event(s) taking place or determinable at the gNB-DU. gNB-DU trigger events may, for example, comprise the following:

Beam level Network Energy saving action executed by gNB-DU

According to one implementation, if a gNB-DU switches off one or more beams, it may be configured to trigger collection of beam level information, for example, relating to trajectories that UEs from switched-off beam(s) followed in order to monitor how UE(s) are transferred to other beams as a result of the bean-level energy saving event(s).

According to some implementations, beam-level trajectory information may be collected before and/or after a beam level network energy saving action in order to compare, for example, UE trajectory trends. Accordingly, a trigger for beam level information collection may be set such that if one or more beam in a gNB-Dll is a candidate for energy saving, additional information may be collected.

By way of example in relation to beam-level energy saving techniques, consider a 3- beam cell with n1 , n2 and n3 UE(s) in served by each beam respectively. gNB-Dll decides t o de-activate beam 1 with n1 UE(s). The deactivation causes the n1 UE(s) to move to beam 2 and beam 3 with the new count of UE(s) as n2’ and n3’ respectively. A gNB-Dll may be configured, if collecting beam-level information, to compare the change in UE distribution and the corresponding load across the two beams ie: n2, n3 compared to n2’, n3’.

Beam level Mobility Actions

According to one implementation, a gNB-DU may be configured to monitor or evaluate a beam change rate (ie number of beam changes in a time T) or average beam change rate (number of beam changes reported in a specific duration) either for a given UE or for a givem beam across users in that beam. The gNB-DU may be configured to start beam-level information collection, for example, trajectory information collection, in relation to beams where the beam change rate has been determined to exceed a predetermined threshold.

The trigger events to be monitored by the gNB-DU and particular configuration in relation to each trigger event can be provided to the gNB-DU by the gNB-CU. gNB-DU detected Radio Link Failure

Similar to the RLF implementation described in relation to a gNB-CU triggered collection of beam-level information, it is possible to implement a similar mechanism with a gNB-DU trigger. In one implementation, if an average number of gNB-DU detected RLF events reported for a given cell exceeds a certain threshold, the gNB-DU may be configured to start beam-level information collection and/or further measurements. The information and measurements may be used to evaluate whether there is a specific beam(s) on which RLF events typically occur and reconfigure the beam(s) in accordance with that evaluation. The RLF trigger threshold may be configured by a network operator.

Having described various approaches in overview, a more detailed description of various example implementations is now provided.

Mechanisms and approaches in accordance with described arrangements support a new procedure which enables a higher layer network node, for example, a gNB-CU- CP, to trigger additional data collection in a lower layer of a network, that additional data providing improved granularity compared to information and data already being collected. Implementations described relate to collection of UE trajectory data collection for one or more UE(s). Some described implementations augment existing F1AP procedures. F1AP provides the signalling service between a gNB-Cll and a gNB-Dll of a gNB. Alternative implementations provide a specific additional procedure, such as a Class 1 procedure including UE Trajectory Data Collection Request/Response (or failure) message exchange and/or a Class 2 procedure to report UE Trajectory information from a gNB-DU to a gNB-CU.

FIG. 4 is a scheduling diagram illustrating schematically messaging according to one arrangement between a gNB-CU-CP and a gNB-DU. As shown in FIG. 4 a gNB-CU- CP 400 is configured to transmit at step 600 a beam-level UE trajectory data collection request to a gNB-DU 500. The beam-level UE trajectory data collection request may comprise: a “List of Cells” indicating a list of cell(s) for which the beam trajectory data collection shall be triggered. In this case, the beam trajectory is collected across all beams of the cell in the indicated cells; a “List of Beams” indicating a subset of beams for a given cell which are to be included in beam trajectory data collection; and/or a “List of UE ID” in accordance with which beam trajectory information may be collected only for those specific listed UE(s). At step 700 the gNB-DU may be configured to acknowledge safe receipt of the data collection configuration sent by gNB-CU-CP at step 600. It will be appreciated that FIG. 4 illustrates schematically a F1AP UE trajectory data collection request in accordance with one implementation.

FIG. 5 is a scheduling diagram illustrating schematically one possible implementation for beam-level UE trajectory data transfer between a gNB-DU 500 and a gNB-CU-CP 600. Once configured as shown in FIG. 4, a gNB-DU may operate in accordance with the configuration set by gNB-CU-CP 400 to provide UE beam-level trajectory information to the gNB-CU-CP at step 800. Step 800 comprises a class 2 procedure which transfers the collected UE Trajectory from gNB-Dll 500 to the gNB-CU-CP 400.

FIGS. 6 to 8 are signalling diagrams illustrating schematically messaging between nodes in a communications network configured to adopt approaches and mechanisms in accordance with possible arrangements. In particular, FIGS. 6 to 8 relate to beamlevel data collection scenarios in support of UE trajectory prediction and show signalling exchanges between nodes in a network (gNB-DU 500 and gNB-CU-CP 400) triggered by: a gNB-CU cell level event; a gNB-CU UE level event, and a gNB-DU beam level event respectively.

FIG. 6 is a signalling diagram relating to an implementation in which beam-level data collection is triggered by a cell-level event detectable by a gNB-CU 400. gNB-CU Cell level event

The call flow illustrated in FIG. 6 shows one possible implementation of cascaded UE trajectory data collection based upon a gNB-CU detectable event as a trigger for beamlevel data collection.

U1 : according to one implementation, the gNB-CU-CP 400 is configured to monitor for L3 trigger events. In this implementation, the trigger event may be a cell-level network energy saving action.

U2: in the illustrated implementation, when the trigger event is identified, the gNB-CU 400 is configured to identify one or more DU(s) 500 identified as hosting the one or more cell(s) on which CU-CP 400 plans to execute the cell level network energy saving action (e.g cell de-activation)

U3: the gNB-CU 400 is configured to commence a F1AP procedure to the identified gNB-DUs instructing initiation of beam-level data collection in support of UE trajectory prediction in relation to the relevant cells.

U4: the gNB-DU is configured to acknowledge receipt of the instruction to collect beamlevel information.

In response to an instruction to commence beam-level data collection, the gNB-DU may be configured to collection data appropriately: for example, if a cell ID is included in instructions from the gNB-CU, then the gNB-DU may be configured to start beam trajectory data collection for all beams in that cell. If specific set of beam identifiers is indicated, the gNB-DU starts the data collection only in those specific beams. In some implementations, a gNB-DU 500 may be configured to collect beam-level UE trajectory information as a snapshot single report. In some implementations, a gNB-DU 500 may be configured to collect and report beam-level UE trajectory information periodically over an indicated period for an indicated duration. The measured beam trajectory information may, for example, in some implementations, comprise an indication of a time of stay of UE(s) camping on a specific beam(s).

U5: Each gNB-Dll may be configured to send a message comprising beam-level trajectory information in relation to the requested cell(s) to the gNB-Cll 400.

The received beam-level information may enable a gNB-CU-CP to identify the possible load on the cell beam(s) which would be offloaded to neighbouring cells after cell switch-off. If the offloading action is determined to be likely to result in a higher level of load on one or more beams than a threshold, the gNB-CU-CP may be configured to delay the cell level network energy saving action until this condition is resolved.

FIG. 7 is a signalling diagram relating to an implementation in which beam-level data collection is triggered by a UE-level event detectable by a gNB-CU. qNB-CU UE level event

The call flow illustrated in FIG. 7 shows one possible implementation of cascaded UE trajectory data collection based upon a UE-level event detectable at a gNB-CU as a trigger for beam-level data collection.

V1: according to one implementation, the gNB-CU-CP 400 is configured to monitor for L3 trigger events at a UE Level. In this implementation, the trigger event may be a number of UE reported RLF events exceeding a threshold.

V2: in the illustrated implementation, when the trigger event is identified, the gNB-CU 400 is configured to identify the DUs 500 which support the cells containing the specific UE(s) for which beam-level UE trajectory data is to be collected.

V3: the gNB-CU 400 is configured to commence a F1AP procedure to the identified gNB-DUs instructing initiation of beam-level data collection in support of UE trajectory prediction in relation to the relevant UE(s).

V4: the gNB-DU is configured to acknowledge receipt of the instruction and configuration according to which it is to collect beam-level information.

In response to an instruction to commence beam-level data collection, the gNB-DU may be configured to collection data appropriately: for example, if a cell ID is included in instructions from the gNB-CU, then the gNB-DU may be configured to start beam trajectory data collection for all beams in that cell. If specific set of beam identifiers is indicated, the gNB-DU starts the data collection only in those specific beams. In some implementations, a gNB-Dll 500 may be configured to collect beam-level UE trajectory information as a snapshot single report. In some implementations, a gNB-Dll 500 may be configured to collect and report beam-level UE trajectory information periodically over an indicated period for an indicated duration. The measured beam trajectory information may, for example, in some implementations, comprise an indication of a time of stay of UE(s) camping on a specific beam(s).

V5: Each gNB-DU may be configured to send a message comprising beam-level trajectory information in relation to the requested UE(s) to the gNB-CU 400.

The received beam-level information may enable a gNB-CU-CP to identify whether, in this implementation, there is a particular beam or beams associated with the UE RLF and flag that beam for further investigation.

FIG. 8 is a signalling diagram relating to an implementation in which beam-level data collection is triggered by a gNB-DU detectable event. gNB-DU level event

The call flow illustrated in FIG. 8 shows one possible implementation of cascaded UE trajectory data collection based upon a gNB-DU detectable event as a trigger for beamlevel data collection.

W1 : according to one implementation, the gNB-CU-CP 400 is configured to select one or more events which occur at the gNB-DU level as beam-level data collection trigger trigger events. In this implementation, each trigger event may have an associated trigger event beam-level data collection configuration. The gNB-CU is configured to transmit the beam-level data request triggers to the gNB-DU 500.

W2: the gNB-DU 500 is configured to acknowledge receipt of the event triggers and the instruction to collect beam-level information.

W3: the gNB-DU 500 is configured to monitor for occurrence of an event trigger.

W4: if the gNB-DU 500 identifies that a beam-level event trigger is met, beam level data collection may commence in accordance with the configuration set by the gNB- CU-CP 400.

The gNB-DU may be configured to collection data appropriately: for example, if a cell ID is included in instructions from the gNB-CU, then the gNB-DU may be configured to start beam trajectory data collection for all beams in that cell. If specific set of beam identifiers is indicated, the gNB-DU starts the data collection only in those specific beams. In some implementations, a gNB-DU 500 may be configured to collect beam- level UE trajectory information as a snapshot single report. In some implementations, a gNB-Dll 500 may be configured to collect and report beam-level UE trajectory information periodically over an indicated period for an indicated duration. The measured beam trajectory information may, for example, in some implementations, comprise an indication of a time of stay of UE(s) camping on a specific beam(s). W5: Each gNB-DU may be configured to send a message comprising beam-level trajectory information in accordance with a collection configuration associated with an event to the gNB-CU 400.

The gNB-CU-CP 400 may be configured to use the received fine granularity information in conjunction with the coarse granularity information that it already has and, for example, enrich data which can be used for AI/ML training in relation to a network.

FIG. 9 illustrates schematically some components of a wireless communication network including nodes according to some arrangements; and FIG. 10 illustrates schematically steps of methods performed at nodes in accordance with some arrangements.

FIG. 9 illustrates schematically some components of a network including nodes according to some arrangements. The network 1000 comprises a core network 1100 and a plurality of base stations 1200 in communication with user equipment 1300. The base stations 1200 comprise a centralised unit 1400 and a plurality of distributed units 1500.

In one arrangement, the base station centralised unit 1400 takes the form of an apparatus, comprising: circuitry 1410 configured to obtain an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; and circuitry 1420 configured to request beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event.

In one arrangement, the base station distributed unit 1500 takes the form of an apparatus, comprising: circuitry 1510 configured to obtain an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; circuitry 1520 configured to collect beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and circuitry 1530 configured to report collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event.

FIG. 10 illustrates schematically steps of methods performed at some network nodes in accordance with some arrangements.

In one arrangement, the base station centralised unit 1400 may be configured to perform a method comprising the steps of:

2410: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; and 2420: requesting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event.

In one arrangement, the base station distributed unit 1500 may be configured to perform a method comprising the steps of:

2510: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection;

2520: collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and

2530: reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event.

A person of skill in the art would readily recognize that steps of various abovedescribed methods can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machineexecutable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of said above-described methods. The program storage devices may be, e.g., digital memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. The embodiments are also intended to cover computers programmed to perform said steps of the above-described methods. The tern non-transitory as used herein, is a limitation of the medium itself (i.e. , tangible, not a signal) as opposed to a limitation on data storage persistency (e.g. RAM vs ROM).

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A base station, comprising: at least one processor; and at least one memory storing instructions that when executed by the at least one processor cause the base station at least to perform: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event.

2. A base station according to claim 1, wherein the base station is caused to perform: the reporting by transmitting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event to a centralised unit associated with the base station.

3. A base station according to any preceding claim, wherein the one or more trigger event comprises a cell-level event.

4. A base station according to claim 1 , wherein the one or more trigger event comprises at least one of the following: a cell-level network energy saving action, or a cell-level radio link failure rate passing a predetermined threshold, or a cell-level average time of stay passing a predetermined threshold, or average time of stay of a user in a cell passing a predetermined threshold.

5. A base station according to claim 3 or claim 4, wherein the base station is caused to perform: receiving an indication that the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection has occurred, and collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event based upon receipt of that indication.

6. A base station according to claim 1 or claim 2, wherein the one or more trigger event comprises at least one of the following: a beam-level event, or user-level event.

7. A base station according to claim 6, wherein the one or more trigger event comprises at least one of the following: a beam-level network energy saving action executed by a base station, or a beam-level mobility action, or a beam-level radio link failure rate passing a predetermined threshold, or a user-level radio link failure rate passing a predetermined threshold, or a user-level average time of stay in a beam passing a predetermined threshold.

8. A base station according to any preceding claim wherein the base station is caused to perform: monitoring for occurrence of the one or more trigger event; and collecting beam-level user trajectory information based upon the result of that monitoring.

9. A base station according to claim 8, wherein monitoring for occurrence comprises directly monitoring for occurrence of the one or more trigger event at a beam-level.

10. A base station according to claim 8 or claim 9, wherein the distributed apparatus is caused to perform: transmitting an indication of occurrence of the one or more trigger event to a control unit associated with the base station.

11. A base station according to any preceding claim, wherein the base station is caused to perform: receiving a request for beam-level user trajectory information collection in relation to the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection, and acknowledging beam-level user trajectory information collection capability in response to the request.

12. A base station according to any preceding claim, wherein the base station is caused to perform: receiving a request for beam-level user trajectory information collection in relation to the one or more trigger event which is a trigger for collection of beam-level user trajectory information collection, wherein the request for beam-level user trajectory information collection comprises: an indication of one or more beam in relation to which to collect beam-level user trajectory information, or an indication of one or more user in relation to which to collect beam-level user trajectory information.

13. A base station according to claim 12, wherein the indication of one or more beam in relation to which to collect beam-level user trajectory information comprises at least one of the following: an identifier of at least one cell for which beam-level user trajectory information is to be collected, or an identifier of at least one beam for which beam-level user trajectory information is to be collected, or an identifier of at least one user for which beam-level user trajectory information is to be collected.

14. A method performed by a base station, the method comprising: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event; and reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event.

15. A non-transitory computer readable medium comprising program instructions stored thereon for performing at least the following: obtaining an indication of one or more trigger event which is a trigger for collection of beam-level user trajectory information collection; collecting beam-level user trajectory information collection in relation to one or more beam associated with the one or more trigger event and reporting collected beam-level user trajectory information in relation to one or more beam associated with the one or more trigger event.