WO2025173659A1 - Method, mobile device and access network node - Google Patents

Abstract

The present disclosure relates to methods performed by nodes of a communication system for using artificial intelligence and machine learning, AI/ML, models to enhance one or more beam management procedures.

Description

METHOD, MOBILE DEVICE AND ACCESS NETWORK NODE

　　The present disclosure relates to a communication system.

　　The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure has particular, although not necessarily exclusive, relevance to beam management using an artificial intelligence (AI) and machine learning (ML)('AI/ML') framework and related apparatus and procedures.

　　Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) is used to refer to an evolving communication technology that supports a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https://www.ngmn.org/5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

　　Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application may use the term access network node, RAN node (or simply RAN) or base station to refer to any such access nodes.

　　For simplicity, the present application will use the term mobile device, user device, or UE, to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and/or generally stationary) that can connect to a communication system for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

　　In the current 5G architecture, the base station structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more Dus that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of base stations may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each base station.

　　In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

　　The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, midhaul availability and network design.

　　In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), an Authentication Server Function (AUSF), a Unified Data Management (UDM) entity for managing user specific data, a Policy Control Function (PCF), an Application Function (AF), a Security Anchor Function (SEAF), an Authentication credential Repository and Processing Function (ARPF), and/or the like. The AMF generally corresponds to the mobility management entity (MME) in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

　　One of the main characteristics of more advanced communication systems is the ability to operate in two distinct frequency ranges (referred to as frequency range 1 or 'FR1', and frequency range 2 or 'FR2'). FR1 covers sub-6 GHz frequency bands (including more recent potential frequency spectrums from 410 MHz to 7125 MHz). FR2, on the other hand, includes so called millimeter wave (mmWave) frequency bands from around 24GHz to 71GHz and offers significantly higher capacities. As the availability of FR1 becomes more limited, FR2 frequency bands will become more prevalent.

　　However, characteristics of the radio medium such as propagation loss, signal blockage, and fading effects differ significantly between FR1 and FR2, which has the potential to affect the end-to-end throughput and communication quality experienced by a user. The provision of enhanced throughput is, in particular, a key goal of 5G (and beyond) communication systems.

　　To address these limitations, new PHY and MAC layer features have been developed to support directional, beamformed, communication that focuses radio signals (e.g., towards a specific recipient UE), rather than have that signal spread omnidirectionally. Beamforming in this way, together with other spatial multiplexing techniques, allow improved utilisation of the spatial domain to increase data throughput, improved communication reliability, and greater system capacity.

　　The coverage in more modern communication systems (e.g., 5G, 6G and beyond) will, therefore, become increasingly beam-based rather than cell based. In current beam-based systems there may be no cell-level reference channel from where the coverage of the cell could be measured. Instead, each cell may have one or more so-called synchronization signal / physical broadcast channel (PBCH) block (SSB) beams. SSB beams form a matrix of beams covering an entire cell area. Each SSB beam carries an SSB comprising a primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH).

　　The UE searches for and performs measurements on the SSB beams (e.g. of the synchronization signal reference signal received power, 'SS-RSRP', synchronization signal reference signal received quality, 'SS-RSRQ', and/or the synchronization signal to noise or interference ratio, 'SS-SINR'). The UE maintains a set of candidate beams which may contain beams from multiple cells. A Physical Cell Identity (PCI) and beam ID (or SSB index) thus distinguish the SSB beams from each other. Effectively, therefore, the SSB beams are like mini cells which may be within a larger cell. Once a UE has detected and selected a cell (and/or an SSB beam) it may attempt to access that cell and/or SSB beam using an initial RRC connection setup procedure comprising a random access channel (RACH) based procedure. The RACH procedure typically involves although, alternatively, the UE may attempt to access that cell and/or beam using a so-called two-step RACH procedure. Both the four step and two step RACH procedures are well known to those skilled in the art.

　　As beamforming becomes increasingly prevalent, therefore, efficient beam management techniques, which are used to acquire and maintain beams become increasingly important.

　　Specifically, whilst the higher frequencies associated with FR2 enable directional communication using a large number of antenna elements, and provides an additional beamforming gain to help compensate for propagation loss, such directional links need precise alignment of beams at the base station and UE. This results the need for increasingly efficient management of beams by which the UE and base station can identify optimal beams for transmission in both the downlink and uplink directions.

　　A number of beam management procedures for both idle and connected modes of operation have been developed. In the idle mode, when the UE does not have active data transmission and the UE is trying to connect to a network, for example, beam management can help to establishing a beam for initial access. In connected mode, on the other hand, when there is active communication between the UE and the base station, and the UE is moving within the cell, the signal can deteriorate rapidly due to the characteristics of high frequency communication. Accordingly, efficient beam management can help to maintain a strong communication link.

　　For the downlink, there are three core procedures (P1, P2, P3) that contribute to beam management - beam sweeping/selection (referred to as 'P1') for initial acquisition, transmitter (base station) side beam refinement (referred to as 'P2'), and receiver (UE) side beam refinement (referred to as 'P3').

　　The beam sweeping/selection (P1) procedure allows selection of an SSB beam for initial access, by a UE in idle mode, based on measurements of, for example the synchronisation signals provided via SSB transmissions. Here, it is assumed that the UE is already camped on an associated cell and is performing measurements (e.g., of RSRP/RSRQ) from the SSBs for the purposes of cell (re)selection. During the initial acquisition of a beam, beam sweeping is used at both the base station and UE. The UE selects the best transmit/receive beam pair (best transmit beam as measured using the best receive beam) based on, for example, SS-RSRP measurements and assumes uplink/downlink beam correspondence and thus also uses the selected downlink receive beam for the uplink transmission of a physical RACH preamble associated with the SSB of the selected downlink transmit beam pair. Thus, the base station can deduce the SSB and hence the selected beam to be used for downlink transmission and uplink reception. The beams that are selected are, however, relatively wide and may not represent the best beam pair for data transmission and reception. Accordingly, once a connection has been established via the initial beam, the beams are further refined based on reference signal (RS) measurements.

　　In more detail, after an initial downlink beam is selected and an associated RRC connection established (i.e., the UE is in RRC connected mode), the transmitter side beam refinement procedure (P2) can be used at the base station in which a beam is selected that is much finer than the selected SSB beam (e.g., in order to support unicast data transmission, with high directivity and high gain). This transmitter side beam refinement of the downlink beam is typically based on measurements, by the UE, of channel state information reference signals (CSI-RS) (e.g., non-zero-power (NZP) CSI-RS (NZP CSI-RS)). At least one CSI-RS resource is respectively configured for corresponding CSI-RS transmission via each of a plurality of different (finer) downlink transmission beams that extend in different directions within the angular range of the initially selected SSB beam. The UE receives, and respectively measures the RSRP of, the transmitted CSI-RS for each finer downlink transmission beam (using a fixed receive beam) and reports the results to the base station. The best/optimum downlink transmission beam is then selected by the base station based on the reported RSRP measurements for all the downlink transmission beams.

　　Where the UE also has a beamforming capability, the receiver side beam refinement procedure (P3) can be used at the UE to select an optimal receive beam. Specifically, CSI-RS transmissions by the base station may be repeated multiple times over time, while the UE carries out its own receive beam sweeping operation to identify and select a receive beam that provides the best reception.

　　For the uplink, similar transmitter (UE) side beam refinement procedures may be used (e.g., where downlink - uplink beam correspondence is not supported). However, in the uplink, the transmitter side beam refinement procedures are based on measurement by the base station of sounding reference signals transmitted by the UE (via different finer beams). The base station can thus select bot the best UE transmit beam and the best base station receive beam.

　　As support is developed for use cases such as enhanced mobile broadband (eMBB), ultra reliable and low latency communication (URLLC), and massive machine type communication (mMTC), efficient beam management has become even more important.

NPL 1: 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN), available from https://www.ngmn.org/5g-white-paper.html.

　　There are, however, a number of challenges for efficient beam management. For example, maintaining optimum transmit and receive beam alignment is particularly difficult in the context of rapidly changing channel conditions and/or when the orientation and/or position of the UE changes. Moreover, as the width of beams gets narrower and the number of beams required to cover a given area therefore increases, current beam management techniques for searching and tracking the best beam become more complex and time consuming. Moreover, current beam management techniques are based on mathematical methodologies that rely on idealised assumptions (e.g., the presence of pure additive white Gaussian noise), which may not be consistent with real world scenarios.

　　AI/ML-based algorithms offer the potential to enhance beam management functionality, delivering advantages that include the reduction of overhead, minimized latency, and improved accuracy in beam selection.

　　For example, two possible use cases that involve the application of AI/ML-based algorithms to beam management are spatial-domain downlink beam prediction and time-domain downlink beam prediction.

　　Spatial-domain downlink beam prediction takes measurements from a given set of 'measured' downlink beams ('Set B') for a given time to predict the most optimal beam or beams within another 'predicted' set of downlink beams ('Set A') at substantially the same time. Time-domain (or 'temporal') downlink beam prediction, on the other hand, takes historical measurement results derived from a given set of measured downlink beams ('Set B') to anticipate the most optimal beam within another 'predicted' set of downlink beams ('Set A') for one or more future time instances. Notably, the beams in Set A and in Set B may be different (i.e., Set B is not a subset of Set A) or the beams in Set B may be a subset of Set A (where Set B is smaller than Set A).

　　AI/ML enhanced beam management can, for example, be based on one or more single sided AI/ML models at the UE (UE-sided) and/or at the base station (network-sided). Nevertheless, this does not preclude the possibility of a two-sided AI/ML model being used.

　　For inference, for example, UE-sided model inference may be based on input data that is internally available at UE where the inference process is performed. For network-sided model inference, on the other hand, the UE can generate the necessary input data while the termination point for this input data lies within the base station where the inference process is performed.

　　For AI/ML model training, for example, training data for UE-sided models can be generated by the UE, while the termination point for the generated training data may be the UE itself and/or a UE-side over-the-top (OTT) server. For network-sided models, on the other hand, training data may be generated by the base station and/or UE, while the termination point for training data may be the base station and/or an operations, administration and management (OAM) function.

　　For AI/ML management, for example, management and control of the model/functionality (e.g., selection, (de)activation, switching, fallback, etc.) in the case of a UE-sided model may be performed by the UE where associated monitoring resides within the UE. For a network-sided model, the model/functionality management/control (e.g., selection, (de)activation, switching, fallback, etc.) may be performed by the base station where the associated monitoring resides within the base station and/or UE. For such monitoring, for example, the UE may simply monitor the performance of its own UE-sided model. On the other hand, for the purposes of monitoring a UE-sided model at the network side, the UE may generate, if needed, calculated performance metrics or data required for performance metric calculations, where the termination point for this information may be the base station. For a network-side model, the monitoring the base station may perform the monitoring.

　　However, in order to facilitate the implementation of enhanced beam management based on AI/ML-based algorithms, appropriate new/enhanced signalling and related mechanisms need to be defined to facilitate data collection, model inference, and performance monitoring for both UE-sided model and network (NW)-sided model. Moreover, as AI/ML models need to be developed, deployed, and managed during the entire lifecycle (a process known as AI/ML model life cycle management (LCM)) at the UE, appropriate new/enhanced signalling and related mechanisms potentially need to be specified for facilitating any necessary LCM operations (e.g., where the AI/ML model is a UE-sided model).

　　Ideally, any AI/ML enhanced beam management will be based around a common framework designed to support both spatial-domain based (downlink) transmit beam management (which may be referred to a beam management (BM)-Case1) and time-domain based (downlink) transmit beam management (which may be referred to a BM-Case2).

　　In order to facilitate the AI/ML model inference, enhanced or new configurations for UE reporting and/or UE measurement may be beneficial, for example, to support beam measurement and/or beam reporting. Enhanced or new signalling for measurement configuration and/or triggering may also be beneficial. The provision of appropriate assistance information also needs to be considered.

　　The disclosure aims to describe one or more apparatus and/or one or more associated methods that contributes to or at least partially addresses one or more of the above needs.

　　Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') telecommunication system; Fig. 2 illustrates a typical frame structure that may be used in the communication system of Fig. 1; Fig. 3 illustrates a functional framework for AI/ML models, and how various entities of the framework may interact with one another, that may be implemented in the communication system of Fig. 1; Fig. 4 schematically illustrates of a method of training an AI/ML model, and of monitoring the performance of the AI/ML model, that may be implemented in the communication system of Fig. 1; Fig. 5 illustrates a set of beams for measurement, and a set of beams for prediction, in accordance with a first arrangement for the purpose of AI/ML enhanced beam management that may be implemented in the communication system of Fig. 1; Fig. 6 illustrates a set of beams for measurement, and a set of beams for prediction, in accordance with a second arrangement for the purpose of AI/ML enhanced beam management that may be implemented in the communication system of Fig. 1; Fig. 7 is a simplified sequence diagram illustrating a first AI/ML enhanced beam management procedure that may be implemented in the communication system of Fig. 1; Fig. 8 is a simplified sequence diagram illustrating a second AI/ML enhanced beam management procedure that may be implemented in the communication system of Fig. 1; Fig. 9 illustrates different AI/ML models that may be used by a UE the communication system of Fig. 1 based on different beam transmission timings and beam prediction occasions; Fig. 10 illustrates prediction occasions and measurement occasions that may be indicated to the UE, by the RAN node, for one of the AI/ML models of Fig. 9; Fig. 11 illustrates a hybrid spatial / temporal approach to beam prediction using AI/ML models that may be used in the communication system of Fig. 1; Fig. 12 is a simplified sequence diagram illustrating a first method of activating AI/ML operation in the communication system of Fig. 1; Fig. 13 is a simplified sequence diagram illustrating a second method of activating AI/ML operation in the communication system of Fig. 1; Fig. 14 is a simplified sequence diagram illustrating a first method of activating AI/ML operation following AI/ML model update/reconfiguration in the communication system of Fig. 1; Fig. 15 is a simplified sequence diagram illustrating a second method of activating AI/ML operation following AI/ML model update/reconfiguration in the communication system of Fig. 1; Fig. 16 illustrates one example of how AI/ML beam prediction configurations may be configured in the communication system of Fig. 1; Fig. 17 is a schematic block diagram illustrating the main components of a UE the communication system of Fig. 1; and Fig. 18 is a schematic block diagram illustrating the main components of a RAN node for the communication system of Fig. 1.

Overview
　　An exemplary telecommunication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 8.

　　Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system (e.g., communication system 1) to which the examples described herein are applicable.

　　In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g. mobile telephones and/or other mobile devices) can communicate with each other via a corresponding radio access network (RAN) node 5-1, 5-2 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN node 5 (5-1, 5-2) comprises a base station 5 or 'gNB' that respectively operates one or more associated cells 9 (9-1, 9-2). In the illustrated communication system 1, the coverage provided by each RAN node 5 may be by means of a plurality of beams B (B₁, B₂ … B_r, B_r+1 … B_N). It will be appreciated that while, for clarity of illustration, only a selection of possible beams B are shown, the set of beams may include any suitable number of beams and each RAN node 5 may operate a respective set of beams or may provide coverage in a non-beamformed manner.

　　Communication via each RAN node 5 is typically routed through a core network 7 (e.g. a 5G or later generations core network or evolved packet core network (EPC)).

　　As those skilled in the art will appreciate, whilst three UEs 3 and two RAN nodes 5 are shown in Figure 1 for illustration purposes, the system, when implemented, will typically include other RAN nodes 5 and UEs 3.

　　Each RAN node 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and/or the like). It will be appreciated that the RAN nodes 5 may be configured to support 4G, 5G, 6G, and/or later generations and/or any other 3GPP or non-3GPP communication protocols.

　　The UEs 3 and their serving RAN node 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and/or the like). Neighbouring RAN nodes 5 may be connected to each other via an appropriate RAN node to RAN node interface (such as the so-called 'X2' interface, 'Xn' interface and/or the like).

　　The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE 3 and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and/or the like. It will be appreciated that the nodes or functions may have different names in different systems.

　　Each RAN node 5 is respectively connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5 and each UPF 11 for the communication of user data. At least the non-IoT UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate interface (e.g. an N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communications are routed transparently via the RAN node 5.

　　Each UPF 11 is respectively connected to an external data network 21 (e.g. an IP network such as the internet) via an appropriate interface (e.g. an N6 reference point) for communication of the user data.

　　The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging.

　　The SMF 10-2 is connected to the AMF 10-1 via an appropriate interface (e.g. an N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates Internet Protocol (IP) addresses to each UE 3. The SMF 10-2 uses user information provided via the AMF 10-1 to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to each UE 3.

　　Each RAN node 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

　　The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides at least the UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. Specifically, a UE 3 may receive a Synchronization Signal / Physical Broadcast Channel (PBCH) Block (SSB), and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form a SS/PBCH block. The RAN node 5 may transmit a number of SSBs corresponding to different DL beams. The total number of SSBs may be confined, for example, within a 5ms duration as an SS burst.

　　The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

　　Similarly, the UEs 3 are configured for transmission of, and the RAN node 5 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and/or a physical random-access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control/data signal, and/or sounding reference signals (SRS) used for UL channel measurement.

　　When the UE 3 initially establishes a radio resource control (RRC) connection with a RAN node 5 via a cell 9 it registers with an appropriate core network node (e.g., AMF 10-1, MME). The UE 3 is in the so-called RRC connected state and an associated UE context is maintained by the network. When the UE 3 is in the so-called RRC idle state, or is in the RRC inactive state, it selects an appropriate cell for camping so that the network is aware of the approximate location of the UE 3 (although not necessarily on a cell level).

Frame Structure
　　Referring to Fig. 2, which illustrates a typical frame structure that may be used in the communication system 1, the RAN node 5 and UEs 3 of the communication system 1 communicate with one another using resources that are organised, in the time domain, into frames of length 10ms. Each frame comprises ten equally sized subframes of 1ms length. Each subframe is divided into one or more slots comprising 14 Orthogonal frequency-division multiplexing (OFDM) symbols of equal length.

　　As seen in Fig. 2, the communication system 1 supports multiple different numerologies (subcarrier spacing (SCS), slot lengths and hence OFDM symbol lengths). Specifically, each numerology is identified by a parameter, μ, where μ=0 represents 15 kHz (corresponding to the LTE SCS). Currently, the SCS for other values of μ can, in effect, be derived from μ=0 by scaling up in powers of 2 (i.e. SCS = 15 x 2^μ kHz). The relationship between the parameter, μ, and SCS (Δf) is as shown in Table 1:

Bandwidth Parts (BWPs)
　　In the communication system 1, the cell bandwidth can be divided into multiple bandwidth parts (BWPs) that each start at a respective common resource block (RB) and respectively comprises of a set of contiguous RBs with a given numerology (sub-carrier spacing, 'SCS', and cyclic prefix, 'CP') on a given carrier. It will be appreciated that conventionally the number of downlink symbols, uplink symbols, and flexible symbols in each slot of the slot configuration (e.g., common or dedicated) would be common to each configured BWP.

　　The UEs 3 and RAN node 5 of the communication system 1 are thus configured for operation using BWPs. For each serving cell of a UE 3, the RAN node 5 can configure at least one downlink (DL) BWP (e.g., an initial DL BWP). The RAN node 5 may configure the UE 3 with up to a maximum (typically four) DL BWPs with only a single DL BWP being active at a given time. The UE 3 is not expected to receive PDSCH, PDCCH, or CSI-RS (except for radio resource management (RRM)) outside an active bandwidth part. Where the serving cell is configured with an uplink (UL), the RAN node 5 can configure at least one UL BWP (e.g., an initial UL BWP). The RAN node 5 may configure the UE 3 with up to a maximum (typically four) UL BWPs with only one UL BWP being active at a given time. The UE 3 does not transmit PUSCH or PUCCH outside an active bandwidth part. For an active cell, the UE 3 does not transmit SRS outside an active bandwidth part. It will be appreciated that the slot format indicator (SFI) (e.g., an SFI-index field value) in the dynamic slot configuration DCI format may indicate to a UE 3 a slot format for each slot in a number of slots for each DL BWP or each UL BWP.

　　A BWP identifier or index (BWP-ID) is used to refer to BWPs (in UL and DL independently). Various radio resource control (RRC) configuration procedures can thus use the BWP-ID to associate themselves with a particular BWP.

　　While for paired spectrum (FDD), DL BWPs and UL BWPs are configured separately, for unpaired spectrum (TDD), a DL BWP is effectively linked to (paired with) a UL BWP, with the paired DL BWP and UL BWP sharing the same BWP-ID and centre frequency (but possibly different bandwidths).

　　Specifically, the RAN node 5 is able to configure an initial DL BWP (e.g. by means of an initialDownlinkBWP IE) via system information (e.g. system information block 1, 'SIB1') and/or via dedicated (e.g. RRC) signalling (e.g. an RRC reconfiguration, RRC resume, or RRC setup message). For example, the common parameters for the initial DL BWP may be provided via system information whereas UE specific parameters may be provided via dedicated signalling (e.g. in a ServingCellConfig IE within an RRC message that contains a dedicated, UE-specific, BWP configuration). The dedicated signalling may also contain some cell-specific information which may be useful for specific scenarios (e.g. handover).

　　The RAN node 5 is able to configure an initial UL BWP (e.g. by means of an initialUplinkBWP IE) via system information (e.g. system information block 1, 'SIB1') and/or via dedicated (e.g. RRC) signalling (e.g. an RRC reconfiguration, RRC resume, or RRC setup message). For example, the common parameters for the initial UL BWP (or BWPs) may be provided via system information whereas UE specific parameters may be provided via dedicated signalling (e.g. in a ServingCellConfig IE within an RRC message that contains a dedicated, UE-specific, BWP configuration). This provides configuration information either for a so-called special cell (SpCell) - which is a primary cell (PCell) of a master cell group (MCG) or secondary cell group (SCG) - or a secondary cell (SCell).

　　The initial DL and UL BWPs are used at least for initial access before an RRC connection is established. The initial BWP is known as BWP#0 as it has a BWP identifier (or 'index') of zero. Prior to receiving system information defining a UE's initial DL BWP, the DL BWP for each UE 3 has a frequency range and numerology corresponding to a control resource set (CORESET) - e.g. CORESET #0 - defined by a master information block (MIB) (or possibly dedicated RRC signalling). The CORESET is used to carry downlink control information (DCI) transmitted via a PDCCH for scheduling system information blocks.

　　After receiving the system information (e.g. SIB1) a UE 3 uses the BWP configuration defined by that system information to configure the initial DL BWP and initial UL BWP. The configured initial UL BWP is then used to initiate a random-access procedure for setting up an RRC connection. The RAN node 5 configures the frequency domain location and bandwidth of the initial DL BWP in the system information so that the initial DL BWP contains the entire CORESET #0 in the frequency domain.

　　For each DL BWP in a set of DL BWPs for a primary cell (PCell), a UE 3 can be configured with CORESETs for every type of common search space (CSS) set (sometimes referred to as a cell-specific search space (CSS)) and for a UE-specific search space (USS) set. For each UL BWP in a set of UL BWPs of a PCell, or of a PUCCH-secondary cell, the UE 3 is configured resource sets for PUCCH transmissions.

　　The UE 3 is configured for switching its active BWP between its configured BWPs when required. For example, switching at the UE 3 may be initiated by receipt of a scheduling DCI, by expiry of an inactivity timer (e.g., a BWPInactivityTimer), and/or by initiation of a random-access procedure.

Beam Management Procedures (without AI/ML enhancement)
　　Each UE 3 and each RAN node 5 are configured for taking its respective part in performing conventional beam management procedures without AI/ML enhancement.

　　Specifically, for the downlink, the UE 3 and each RAN node 5 are able to perform their respective parts in the three core beam management procedures (P1, P2, P3) including beam sweeping/selection (P1) for initial acquisition, transmitter (base station) side beam refinement (P2), and receiver (UE) side beam refinement (P3). Similarly, for the uplink, the UE 3 and each RAN node 5 are able to perform their respective parts in transmitter (UE) side beam refinement procedures (if needed), for example where downlink - uplink beam correspondence is not supported.

　　When performing these conventional beam management procedures, initially a UE 3 that is camped on a cell 9 of the RAN node 5 in RRC idle mode is able to establish uplink and downlink beam pairs, during a RACH procedure, using the beam sweeping/selection procedure (P1). An SSB beam for initial access is selected by the UE 3, based on measurements of the SSBs respectively transmitted via each transmit beam during beam sweeping by the RAN node 5 (and respectively received by the UE in each receive beam during receive beam sweeping by the UE). The UE selects the best transmit/receive beam pair (best transmit beam as measured using the best receive beam) based on, for example, SS-RSRP measurements and assumes uplink/downlink beam correspondence and thus also uses the selected downlink receive beam for the initial access uplink transmission of a physical RACH (PRACH) preamble (i.e., in message 1 or 'Msg1') that is specifically associated with the SSB transmitted via the selected beam.

　　An association between the SSBs and corresponding PRACH preambles can be derived by the UE 3 from system information (e.g., SIB1) received from the RAN node 5 after camping on the cell 9.

　　The RAN node then deduces the SSB from the initial access uplink transmission and hence the selected beam to be used for downlink transmission and uplink reception.

　　After the initial downlink beam is selected and an associated RRC connection established, the transmitter side beam refinement procedure (P2) can then be used to refine the downlink beam selection at the RAN node 5. This transmitter side beam refinement of the downlink beam is based on measurements, by the UE 3, of CSI-RS (e.g., NZP CSI-RS). The UE receives, and respectively measures the RSRP of, CSI-RS respectively transmitted via each of a plurality of downlink transmission beams (using a fixed receive beam) and reports the results to the RAN node 5. The best/optimum downlink transmission beam is then selected by the RAN node 5 based on the reported RSRP measurements for all the downlink transmission beams.

　　In this example, the UE 3 also has a beamforming capability and can therefore perform the receiver side beam refinement procedure (P3) to select an optimal receive beam. Specifically, CSI-RS transmissions may be repeated by the RAN node 5 multiple times while the UE 3 carries out its own receive beam sweeping operation to identify and select a receive beam that provides the best reception.

Support for Artificial Intelligence (AI)/Machine Learning (ML)
　　The communication system 1 supports the use of artificial intelligence (AI) and machine learning (ML), often abbreviated to AI/ML in accordance with recent developments in cellular communication technology (e.g., as part of the work of the 3GPP) that those skilled in the art will be familiar with. These AI/ML features make use of trained AI/ML models to make one or more predictions or inferences, from a set of one or more input vectors, that can be used in the network (e.g., for improving the reliability or efficiency of communication in the network).

　　In respect of the communication system 1, for example, AI/ML models could potentially be trained and used for predicting the path of a UE 3 based on previous mobility of the UE 3, used for beam management, or used in methods of encoding and transmitting information. An AI/ML model may be hosted at a RAN node 5 (or any other suitable network node), and the RAN node 5 may perform control of communication resources for UEs 3 it serves, and/or perform control related to the status of a UE 3 (e.g. control of UE mobility, or control of a radio resource control, RRC, state of the UE) based on an inference (e.g. determination or prediction) generated using the AI/ML model. The RAN node 5 may also transmit an inference generated using the model to another node in the network, for use at the other node. An AI/ML model may also be hosted the UE 3, or at a plurality of locations within the network, for example at both a RAN node and at a UE 3. For example, the RAN node 5 and the UE 3 may both make determinations and/or predictions using the same model or different models.

　　The support for such AI/ML features may involve different levels of collaboration between the network (RAN node 5 and/or core network 7) and a UE 3 served by the network when deploying and using such AI/ML features. For example, three possible 'network-UE collaboration levels' that may be supported are:
- Level x: Involving no collaboration between the network and the UE. Specifically, level x is an implementation-based AI/ML operation without any dedicated AI/ML-specific enhancement.
- Level y: Signalling-based collaboration without AI/ML model transfer. For example, this level is applicable when model training is performed offline, and models are registered to both a RAN node 5 and the UE 3. Here, the RAN node 5 and the UE 3 are aware of available models (before operation), and the RAN node 5 is only required to activate/deactivate the models residing at the UE 3 when needed.
- Level z: Signalling-based collaboration with AI/ML model transfer (e.g., where an AI/ML model is transferred to the UE 3 when needed).

　　The AI/ML model types that are supported in the communication system 1 may include, for example:
- Single-sided model: A single-sided AI/ML model is an AI/ML model that is deployed (hosted) only at the UE side or at the network side. An example of this type of model is an AI/ML model for beam prediction in time, which can be deployed at the UE side. However, even when the model is a single-sided model, it will be appreciated that the model need not necessarily be trained at the node at which it is deployed (e.g. a UE 3 or a RAN node 5). For example, the model could be trained at the RAN node 5 (or at another node in the network such as a core network node/function), and then is transferred to the UE 3 for use at the UE 3.
- Two-sided model: A 'two-sided' model is an AI/ML model (or model pair) that has one AI/ML model hosted at one node (e.g., the UE 3), and a corresponding AI/ML model hosted at another node (e.g., a RAN node 5) - it will be appreciated that any pair of network nodes may be used. Such a two-sided model may also be referred to as a 'paired' AI/ML model. Inference using a two-sided model is performed jointly across the nodes at which the AI/ML models of the two-sided model are deployed. The joint inference may comprise, for example, a first part of the inference being performed at one node (e.g. the UE 3 or RAN node 5), and then the remaining part may be performed by the other (e.g., the RAN node 5 or UE 3). It will be appreciated that whilst the AI/ML model hosted at the different nodes may be the same AI/ML model, they need not necessarily be the same model. One example of this type of model is, for example only, channel state information (CSI) compression, where the UE performs CSI compression and network performs CSI decompression. As with the single-sided model case, the two-sided model (or models) may be trained at any suitable network node, and then transmitted to the UE 3 and the RAN node 5 (or other respective node or nodes).

　　A general discussion of how AI/ML may be implemented in the communication system 1 will now be provided, by way of example only, with reference to Figs. 3 and 4.

　　Fig. 3 illustrates a functional framework for AI/ML models, and how various entities of the framework may interact with one another, that may be implemented in the communication system 1.

　　The entities include a data collection entity 341, a model training function 343, a model inference function 345, an actor 347, a management function 349, and a model storage entity 351.

　　The model storage entity 351 may be a reference point for protocol terminations for model transfer and delivery. The AI/ML models could be stored at any suitable node in the network.

　　The data collection entity 341 provides training data to the model training function 343, inference data to the model inference function 345, and monitoring data to the management function 349. The collected data may be, for example, data regarding mobility (e.g. handover of a UE 3, or a location of the UE 3). The data may be obtained, for example, by a UE 3 or a RAN node 5 (e.g. by receiving a measurement report from a UE 3, or by receiving data from another RAN node 5 or a core network node/function) and transmitted to another RAN node 5 or core network node that generates the AI/ML model inference output (or alternatively, the same RAN node that obtains the data may generate the AI/ML model output).

　　The model training function 343 performs the ML model training, validation, and testing, and may generate model performance metrics as part of a model testing procedure. The model training function 343 may output a trained AI/ML model to the model storage 351 (though it will be appreciated that the output model may be stored at locations other than model storage entity 351).

　　The model inference function 345 provides AI/ML model inference output (e.g., predictions or decisions), and the actor 347 is a function or node that receives the output from the model inference function 345 and triggers or performs corresponding actions (e.g. a RAN node 5 that increases/reduces its transmit power, or initiates a handover procedure for a UE 3). The AI/ML model inference output may be, for example, a prediction of mobility (e.g. expected path, route or trajectory, inter-cell, or inter-beam mobility, or expected handover) of the UE 3, or one or more parameters for use in encoding or decoding transmissions between the RAN node 5 and the UE 3. The model inference function 345 may receive an AI/ML model from the model storage entity 351, and inference data from the data collection entity 341 for use with the AI/ML model. The model inference function 345 may also output monitoring data for use at the management function 349, and receive information indicating an AI/ML to activate or deactivate from the management function 349.

　　The management function 349 receives monitoring data from the data collection entity 341, and may also receive monitoring data from the model inference function 345. The management function 349 may transmit, to the model storage entity 351, an indication of an AI/ML model to be transmitted for use at the model inference function 345. The management function 349 may also transmit, to the model training function 343, performance feedback or a retraining request for the AI/ML model.

　　The functions illustrated in Fig. 3 may be co-located at a single node of the communication system 1 (e.g. at a RAN node 5 or core network node/function), or may be distributed amongst a plurality of network nodes (e.g. a plurality of RAN nodes 5).

　　By way of example only, terms referred to by 3GPP in the context of this framework include:
- AI/ML model training: A process to train an AI/ML Model [by learning the input/output relationship] in a data driven manner and obtain the trained AI/ML Model for inference. Model training can be performed offline or online or combination of both.
- AI/ML model validation: A subprocess of training, to evaluate the quality of an AI/ML model using a dataset different from one used for model training, that helps selecting model parameters that generalize beyond the dataset used for model training.
- AI/ML model testing: A subprocess of training, to evaluate the performance of a final AI/ML model using a dataset different from one used for model training and validation. Differently from AI/ML model validation, testing does not assume subsequent tuning of the model.
- AI/ML model Inference: A process of using a trained AI/ML model to produce a set of outputs based on a set of inputs.
- Data collection: A process of collecting data by the network nodes, management entity, or UE for the purpose of AI/ML model training, data analytics and inference.
- Model monitoring: A procedure that monitors the inference performance of the AI/ML model.
- Model activation: Enable an AI/ML model for a specific function.
- Model deactivation: Disable an AI/ML model for a specific function.
- Model switching: Deactivating a currently active AI/ML model and activating a different AI/ML model for a specific function.
- Supervised learning: A process of training a model from input and its corresponding labels.
- Unsupervised leaning: A process of training a model without labelled data.
- Semi-supervised learning: A process of training a model with a mix of labelled data and unlabelled data.
- Reinforcement Learning (RL): A process of training an AI/ML model from input (also referred to as 'state') and a feedback signal (also referred to as 'reward') resulting from the model's output (also referred to as 'action') in an environment the model is interacting with.

　　The data collection by the data collection entity 341 may be performed at various nodes of the communication system 1 (e.g., at one or more RAN nodes 5 or UEs 3). Particularly advantageous methods of obtaining, at a UE 3, data for an AI/ML model, and transmitting the AI/ML data from the UE 3 to a RAN node 5, will be described in more detail later.

　　Fig. 4 schematically illustrates of a method of training an AI/ML model, and of monitoring the performance of the AI/ML model. As illustrated in Fig. 4, stored data/features may first be extracted in a data extraction step. In the data validation step, a determination of whether to proceed with training or retraining the AI/ML model is made (e.g., based on the extracted data). In the data preparation stage, the data is prepared for use in training the AI/ML model. For example, the data may be cleaned (e.g., filtered), subject to a transformation, or modified in any other suitable manner. The data may also be divided in training data, validation data and test data sets in the data preparation stage.

　　In the model training step, the AI/ML model is trained (or retrained) using training data prepared in the data preparation step. It will be appreciated that any suitable training method can be used to train the AI/ML model (e.g. a method that comprises supervised learning or unsupervised learning). In the model evaluation step, the AI/ML model is evaluated (e.g. a prediction accuracy of the AI/ML model is evaluated) using a test data set (which may be generated in the data preparation step). In the model validation step, a determination of whether the AI/ML model is suitable for deployment in the communication system 1 is made (e.g. based on the results of the model evaluation step).

　　In the model serving step, the AI/ML model is deployed for use in the communication system 1. AI/ML model deployment may comprise compiling a trained AI/ML model, packaging the model into an executable format, and delivering the AI/ML model to a target device. For example, the AI/ML model may be transmitted to the RAN node 5 and/or the UE 3, for use at the RAN node 5 and/or the UE 3 to generate predictions or determinations using the AI/ML model as part of a prediction service step, as illustrated in Fig. 4. In the performance monitoring step, the performance of the deployed AI/ML model is monitored. The predictive performance of the AI/ML model may be monitored by comparing predictions generated using the model with one or more measurements. For example, when the AI/ML model is used to predict a location of a UE 3, the prediction accuracy of the AI/ML model may be assessed using a measurement of an actual location of the UE 3. If the AI/ML model is used for predicting future measurement results (e.g., the measured RSRP of reference signals) at some point in time, the prediction accuracy of the AI/ML model may be assessed using actual measurement results acquired by the UE 3 when that point in time is reached. If the AI/ML model is used for determining parameters for use in encoding and decoding data transmitted between a RAN node 5 and a UE 3, the model may be assessed based on the performance of the encoding and/or decoding processes. In the retraining trigger step, retraining of the AI/ML model is triggered (e.g. because the prediction accuracy of the AI/ML model has fallen below an acceptable threshold accuracy, or because a performance of a method that uses inferences from the AI/ML model has fallen below an acceptable threshold performance), and the method returns to the data extraction step.

　　As described above with reference to Fig. 3, each step of the method of Fig. 4 may be executed at a single node of the communication system 1 (including at the UE 3), or alternatively steps of the method may be distributed between a plurality of different nodes (or indeed one or more of these steps may be performed online or offline).

　　As discussed above with reference to Figs. 3 and 4, information collected by nodes/functions in the communication system 1 (e.g. at a UE 3) can be used as training data for an AI/ML model, and used as inference data for use in generating one or more model inferences using the AI/ML model. The information used as training data, monitoring data, and/or to generate the one or more model inferences may be referred to as 'AI/ML information' or 'AI/ML data'.

Beam Management Procedures (with AI/ML enhancement)
　　Whilst each UE 3 and each RAN node 5 are able to perform conventional beam management procedures (without AI/ML enhancement) based entirely on real measurements (e.g., of reference signals or the like), each UE 3 and each RAN node 5 are beneficially configured to make use of AI/ML models to provide enhanced 'predictive' beam management procedures.

　　A number of such beam management procedures will now be described in overview, by way of example only, with reference to Figs. 5 to 8.

　　Referring to Figs. 5 and 6, in particular, the AI/ML enhanced beam management procedures beam beneficially use predictions for a set of beams (Set A) that are based on measurements in respect of another set of beams (Set B) that may be spatially and/or temporally shifted relative to at least some of the beams in Set A.

　　Fig. 5 illustrates a set of beams for measurement, and a set of beams for prediction, in accordance with a first arrangement for the purpose of AI/ML enhanced beam management that may be implemented in the communication system 1.

　　Fig. 6, on the other hand, illustrates a set of beams for measurement, and a set of beams for prediction, in accordance with a second arrangement for the purpose of AI/ML enhanced beam management that may be implemented in the communication system 1.

　　As seen in Fig. 5, the beams in Set A and in Set B may be different (i.e., Set B is not a subset of Set A). For example, the beams in Set B may comprise relatively wide beams, while Set A may comprise a set of narrower beams than those in Set B. As seen in Fig. 6, the beams in Set B may be a subset of Set A (where Set B is smaller than Set A).

　　In the exemplary communication system 1, the UE 3 and RAN node 5 are configured to support both spatial-domain based (downlink) transmit beam management and time-domain based (downlink) transmit beam management. Nevertheless, it will be appreciated that the communication system 1 need not implement both spatial-domain and time-domain based beam management. The AI/ML enhanced beam management in the communication system 1 will still provide commensurate benefits if only spatial-domain based beam management, or time-domain based beam management, is implemented.

　　The spatial-domain downlink based beam management involves performing downlink beam predictions for the set of predicted downlink beams (i.e., Set A) for a given time frame based on real measurement results for the 'measured' set of downlink beams (i.e., Set B) during substantially the same time frame. The time-domain (or 'temporal') downlink beam prediction, on the other hand, takes historical measurement results derived from the set of measured downlink beams (i.e., Set B) to anticipate the most optimal beam within the predicted set of downlink beams (i.e., Set A) for one or more future time instances.

　　Whilst Set A and Set B in Figs. 5 and 6 are different it will, nevertheless, be appreciated that, for the temporal downlink beam prediction, the beams in Set B that are the subject to 'historic' measurement may be the same as those of Set A to which one or more 'future' predictions relate.

　　Any appropriate measurement may be used as an input to the AI/ML model for the downlink beam prediction (whether spatial or temporal). For example, layer 1 (L1) measurements (e.g., L1-RSRP measurements) of the beams within Set B may be used as an input to an AI/ML model for producing one or more outputs representing one or more predicted top ranked beams in Set A. It will be appreciated that the AI/ML model training and inference may be network side (e.g., located at the RAN node 5) or UE side. Where AI/ML inference occurs at the UE side, the UE 3 may, for example, report one or more predicted top ranked beams to the RAN node 5, whereas if AI/ML inference takes place at the RAN node 5, his may be based on measurements (e.g., of L1-RSRP) for the beams within Set B that have been reported to the RAN node 5 by the UE 3.

RAN Node-Sided Model
　　An exemplary AI/ML enhanced beam management procedure in which AI/ML inference takes place at the network side will now be described by way of example only with reference to Fig. 7, which is a simplified sequence diagram illustrating a first AI/ML enhanced beam management procedure that may be implemented in the communication system 1.

　　As seen in Fig. 7, the exemplary procedure is based around the three core beam management procedures described earlier (beam sweeping/selection (P1) transmitter side beam refinement (P2), and receiver side beam refinement (P3)).

　　In this example, the AI/ML model training and inference resides at the RAN node side. Initially, at S700, the RAN node 5 sweeps through the transmit beams in Set B and the UE 3 performs, at S702, associated measurements (e.g., L1-RSRP in the illustrated example).

　　In the example of Fig. 7, the UE 3 reports the measurements to the RAN node 5 at S703. The RAN node 5 then uses, at S704, the RAN node side AI/ML model to predict the top ranked (e.g., 'top-k') one or more transmit beams of Set A from the received measurement results for the beams in Set B. The output of the AI/ML model may, for example, include: one or more predicted L1-RSRPs corresponding to one or more downlink transmit beams (or beam pairs); information identifying one or more predicted top ranked beams; and/or confidence/probability information related to the output of AI/ML model inference (e.g., predicted beams). In the case of the temporal based AI/ML enhanced beam management, the AI/ML model may provide at least a (pre)configured number (e.g., 'F') predictions for that number ('F') of future time instances (i.e., where each prediction is for a respective time instance).

　　The RAN node 5 then sweeps, at S708, the identified top ranked transmit beams from Set A and the UE 3 performs associated measurements (e.g., L1-RSRP in the illustrated example) of those ranked transmit beams from Set A to identify the best transmit beam. Once the UE 3 has identified the best transmit beam the UE 3 reports an identifier of the best transmit beam from Set A to the RAN node 5 at S712.

　　If needed, the RAN node 5 can perform repeated transmissions using the best Set A beam at S714 while the UE 3 performs receive beam sweeping at S718 for the purposes of receive beam refinement to identify and select the best receive beam.

UE-Sided Model
　　An exemplary AI/ML enhanced beam management procedure in which AI/ML inference takes place at the UE side will now be described by way of example only with reference to Fig. 8, which is a simplified sequence diagram illustrating a second AI/ML enhanced beam management procedure that may be implemented in the communication system 1.

　　As seen in Fig. 8, the exemplary procedure is based around the three core beam management procedures described earlier (beam sweeping/selection (P1) transmitter side beam refinement (P2), and receiver side beam refinement (P3)).

　　In this example, the AI/ML model training and inference resides at the UE side. Initially, at S800, the RAN node 5 sweeps through the transmit beams in Set B and the UE 3 performs, at S802, associated measurements (e.g., L1-RSRP in the illustrated example).

　　In the example of Fig. 8, the UE 3 uses, at S804, the UE side AI/ML model to predict the top ranked (e.g., 'top-k') one or more transmit beams of Set A from the acquired measurement results for the beams in Set B. The output of the AI/ML model may, for example, include: one or more predicted L1-RSRPs corresponding to one or more downlink transmit beams (or beam pairs); information identifying one or more predicted top ranked beams; and/or confidence/probability information related to the output of AI/ML model inference (e.g., predicted beams). In the case of the temporal based AI/ML enhanced beam management, the AI/ML model may provide at least a (pre)configured number (e.g., 'F') predictions for that number ('F') of future time instances (i.e., where each prediction is for a respective time instance).

　　The UE 3 then reports, at S806, identifiers (IDs) of the top ranked one or more (e.g., 'top-k') transmit beams of Set A to the Ran node 5.

　　The RAN node 5 then sweeps, at S808, the identified top ranked transmit beams from Set A and the UE 3 performs associated measurements (e.g., L1-RSRP in the illustrated example) of those ranked transmit beams from Set A to identify the best transmit beam. Once the UE 3 has identified the best transmit beam the UE 3 reports an identifier of the best transmit beam from Set A to the RAN node 5 at S812.

　　If needed, the RAN node 5 can perform repeated transmissions using the best Set A beam at S814 while the UE 3 performs receive beam sweeping at S818 for the purposes of receive beam refinement to identify and select the best receive beam.

Information for AI/ML Model Selection/Determination
　　To support the UE-sided AI/ML enhanced beam management procedure, the UE 3 may need to be able to identify a particular AI/ML model to be used for inference and/or training from among a plurality of possible different AI/ML models that may be stored at the UE 3. The selection of the AI/ML model may be based on network configuration and/or assistance information/parameters.

　　This information will typically include, for example, information identifying the Set A and Set B beams, in the communication system 1. Beneficially, however, other configuration and/or assistance information/parameters may alternatively or additionally be provided to the UE 3 to facilitate AI/ML model selection at the UE 3, as described in more detail later.

Activation of an AI/ML Model
　　It will be appreciated that, in some scenarios, it may be beneficial for the network to be able to explicitly activate inference operation of an AI/ML feature (e.g., a beam prediction AI/ML model) after initial configuration (or reconfiguration) of that AI/ML feature (e.g., by means of an explicit activation command). This may be helpful, for example, to allow fine tuning network control. Nevertheless, in some scenarios, it may be beneficial for AI/ML operation to start automatically after initial configuration of an associated AI/ML feature/model (i.e., without an explicit activation command), e.g., to reduce implementation burden of activation/deactivation of an AI/ML model.

　　As described in more detail later, therefore, the UE 3 and RAN node 5 of the communication system 1 are mutually configured to coordinate with one another to support either option depending on requirements. Nevertheless, it will be appreciated that either one of the options may be supported in isolation and still provide a commensurate benefit.

Reconfiguration of an AI/ML Model
　　It will be appreciated that, in some scenarios, it may be beneficial for the network to be able to update a configuration of an AI/ML model at the UE 3 while beam prediction is on-going. This may be beneficial, for example, to allow reconfiguration in the event that model monitoring indicates that more optimal performance may be achievable by adjusting one or more model parameters (e.g., the identity of the beams forming Set B beams). This may also be beneficial, for example, to allow reconfiguration in the event that the network to provide different model parameters for different scenarios (e.g. a low signal-to-noise ratio (SNR) scenario verses a high SNR scenario). This may also be beneficial when an AI/ML model is running and the network wants to enable or disable or update the AI/ML monitoring parameters by reconfiguring the AI/ML model.

　　As described in more detail later, therefore, to support the UE-sided AI/ML enhanced beam management procedure, the UE 3 and RAN node 5 may be mutually configured to coordinate with one another to support the UE 3 handling scenarios in which one or more parameters of an AI/ML model require reconfiguration after an AI/ML model has been activated (and is therefore running). In one example described in more detail later, the AI/ML operation pauses but continues running the new/reconfigured AI/ML model immediately upon reconfiguration (e.g., following a short reconfiguration processing interval). In another example described in more detail later, the UE 3 deactivates/disables the running of the current AI/ML model and only activates the new/reconfigured AI/ML model when instructed to do so.

BWP/Carrier Aggregation Operation
　　It will be appreciated that the UE 3 may be configured to communicate via a plurality of different serving cells (for example, different cells corresponding to different carriers in a carrier aggregation (CA) or dual connectivity (DC) scenario). These different cells can, potentially, have a different requirement for beam management prediction in the context of AI/ML enhanced beam management. For example, a first serving cell may be deployed on a carrier in FR1 while a second serving cell may be deployed in FR2 (or vice versa) and hence each serving cell may have different beam configurations.

　　As described in more detail later, therefore, the communication system 1 beneficially supports the possible generation of a plurality of beam prediction configurations for a given AI/ML model where each beam prediction configuration may be respectively associated with one or more serving cells.

　　Moreover, whilst within a given serving cell, the beam prediction requirements may not change across different BWPs, different BWPs generally require different RS resources.

　　As described in more detail later, therefore, the communication system 1 beneficially supports the possible generation of a one or more beam prediction configurations for a given AI/ML model where each beam prediction configuration may respectively include a plurality of independent BWP associated parameter sets. Each independent BWP associated parameter set may respectively comprise one or more BWP specific parameters that are associated with a different corresponding BWP. Different sets of BWP specific parameters within the beam prediction configuration may, therefore, be associated with different BWPs whereas other parameters in the beam prediction configuration may be common to all (or a subset of) the different BWPs.

　　Moreover, as described in more detail, the UE 3 is beneficially configured to perform AI/ML enhanced beam management in a manner that takes appropriate account of any change in the serving cell or the BWP at the UE 3 (e.g., depending on any differences in the cell specific beam prediction configurations / BWP specific parameters that are associated with the old/new BWP).

Information for AI/ML Model Selection/Determination
　　As mentioned above, the selection of the AI/ML model may be based on network configuration and/or assistance information/parameters that are provided by the RAN node 5 to the UE 3 to facilitate AI/ML model selection at the UE 3.

　　The UE 3 uses the given set of information (which may represent one or more conditions) to determine an AI/ML model to be used.

　　The network configuration and/or assistance information/parameters may for example identify one or more of the following information types (or conditions): a number of Set B beams; a number of Set A beams; time occasions of measurement occasions for and/or transmission of the Set B beams; one or more prediction output configurations (e.g., time occasions for beam predictions and/or a type of beam prediction to be spatial-domain, time-domain, or hybrid); one or more pattern indices, data set identifiers, model identifiers and/or the like; and/or a radio frequency band or frequency for which the AI/ML beam prediction is to be performed (it will be appreciated that this information may be determined from the serving cell/BWP on which beam prediction is being performed). It will be appreciated that one or more of these may be indicated implicitly by the RAN node 5, to the UE 3, simply using a functionality identifier, model identifier, and/or the like where the model identifier or functionality identifier is associated with the associated information (e.g. measurement and/or prediction occasions) and the UE 3 and RAN node 5 are both aware of this association (for example by means of UE capability exchange and/or model identification).

　　It will nevertheless be appreciated that, in some circumstances, it may also be appropriate for the network (e.g., RAN node 5) to be made aware of the conditions of each AI/ML model (e.g., where the AI/ML model is trained at UE 3 or an external server). To facilitate this, one or more of the above information types (or conditions), such as (but not limited to) the number of Set A and/or Set B beams associated with a particular AI/ML model may be provided to the RAN node 5 as part of a model identification procedure. A UE 3 may, for example, be responsible for model identification signalling to the RAN node 5, in which case the UE 3 may indicate the necessary information (or conditions) associated with each identified AI/ML model/functionality supported at UE 3.

　　Some of the above information types (or conditions), for example frequencies and/or RF band information associated with an AI/ML model may form part of a UE capability and may therefore be indicated to the RAN node 5 as part of a UE capability exchange. For example, the UE 3 may indicate one or more of the above information types (e.g. an RF band and/or frequency) respectively for association with each AI/ML model/functionality supported by the UE 3.

Indication of Set-A and Set-B beams
　　When providing an indication of the beams forming Set A and Set B, the following information may, for example, be provided to a UE 3 (e.g., as part of an AI/ML beam management model configuration, or as separate related information, for the UE 3).

　　Beneficially, as the UE 3 performs real measurements for the beams of Set B, the AI/ML beam management model configuration may include information respectively identifying any SSB and/or CSI-RS resources that are associated with each of the Set B beams identified in that AI/ML beam management model configuration (and hence identify each Set B beam). For example, the beams of Set B may be identified by means of information identifying one or more NZP-CSI resource sets (e.g. by reusing an existing information element such as, NZP-CSI-RS-ResourceSet, NZP-CSI-RS-Resource, and/or the like that would be familiar to those skilled in the art).

　　It will be appreciated here that where a plurality of AI/ML beam management model configurations are provided to the UE 3 each such configuration may include information identifying both the beams of Set A and the beams of Set B.

　　The configuration in respect of Set A may, beneficially, simply indicate the number of beams to be predicted by the UE 3 without including any association to an actual SSB and/or CSI-RS resource (e.g., in a case where a monitoring operation is not required). Nevertheless, the network may beneficially indicate whether the Set A beams are of a CSI-RS type or an SSB type (and hence beneficially support a scenario in which different AI/ML models may be selectable for performing CSI-RS and SSB Set A beam predictions).

　　It will be appreciated, that in a case where the network also enables monitoring of and/or training of an AI/ML model, the RAN node 5 may beneficially indicate one or more SSB and/or CSI-RS resources respectively associated with each Set A beam (e.g., by association with a Set A beam index) thereby allowing the UE 3 to perform evaluation of its beam prediction accuracy. In this case, the reference signals for Set A may, for example, be indicated by means of information identifying one or more NZP-CSI resource sets (e.g. by reusing an existing information element such as, NZP-CSI-RS-ResourceSet, NZP-CSI-RS-Resource, and/or the like that would be familiar to those skilled in the art).

　　It will be appreciated, therefore, that any association between Set A and actual SSB and/or CSI-RS resources may be an optional feature (e.g., that is configurable depending on requirements).

　　Moreover, a pattern identifier, an antenna configuration identifier, a model identifier, and/or data set identifier may be provided within the model configuration. This may be beneficial, for example, to support scenarios in which multiple AI/ML models have been defined for the same number of Set A and Set B beam sets but have been trained with different hyperparameters such as, for example, antenna configuration and/or UE speed.

Timing information for beam measurements and prediction
　　It will be appreciated that the prediction output of an AI/ML beam management model may vary significantly depending on the periodicity of the measurement occasions (for Set B beams) and/or predictions (for Set A beams).

　　Hence, associated timing information may, beneficially, be provided to the UE 3 (e.g., as part of an AI/ML beam management model configuration, or as separate related information, for the UE 3), thereby allowing the UE 3 to select an appropriate AI/ML model based on the timing information.

　　Fig. 9, for example, illustrates different models that may be used by a UE 3 in the communication system 1 based on different beam transmission timings and beam prediction occasions. In Fig. 9, T1 represents an 'observation' or 'measurement' window or period during which measurement of Set B beams is performed and T2 represents a 'prediction' window or period for which a UE 3 performs predictions in respect of Set A beams. As seen in Fig. 9, even where different models used by the UE 3 are based on the same number of Set A beams and Set B beams the timings can be different.

　　Referring to Fig. 10, which illustrates prediction occasions and measurement occasions that may be indicated to the UE 3, by the RAN node 5, for one of the AI/ML models of Fig. 9, the Set B beam measurement occasions, and the AI/ML prediction occasions repeat with a specific periodicity. Accordingly, as described in more detail below, the Set B beam measurement occasions and/or the AI/ML prediction occasions may be indicated to and/or inferred by the UE 3 based on an AI/ML beam prediction period representing this periodicity.

Timing for Measurements of Set B Beams
　　The timing for measurement occasions for the Set B beams for the purposes of performing measurements to act as inputs for beam prediction may be indicated in any suitable manner.

　　For example, the UE 3 may be configured to determine the measurement occasions for beam prediction implicitly to have the same periodicity (e.g., corresponding to the AI/ML beam prediction period in Fig. 10) as the transmission of SSB and/or CSI-RS associated with the Set B beams. By way of illustration only, if a CSI-RS resource (associated with a Set B beam) is transmitted with a periodicity of 10ms, then the UE 3 may assume that measurements (or inputs) for the purposes of beam prediction shall also be performed (or acquired) with a periodicity of 10ms.

　　It will be appreciated that, to support time-domain based prediction, the RAN node 5 may be configured to support pattern based periodic transmission of reference signals. For example, a reference signal transmission pattern may consist of a certain number (e.g., 'N1') transmission occasions that repeats with a periodicity of 'N' occasions. The RAN node 5 may then indicate which of these N occasions within a pattern are used for reference signal transmission (e.g., corresponding to Set B measurement occasions) and/or which of these N occasions within a pattern are not used for reference signal transmission (e.g., corresponding to Set A prediction occasions). For example, the RAN node 5 may be configured to be able to indicate the reference signal transmissions by means of a bitmap where each bit within the bitmap corresponds/points to a transmission occasion and the value of the bit ('1' or '0') indicates whether that transmission occasion is actually used for a reference signal transmission (e.g. with the bit set to '1' or '0') or not (e.g. with the bit set to '0' or '1'). Alternatively or additionally, the RAN node 5 may be configured to be able to indicate the reference signal transmissions by means of configuration information that indicates (or points to) an index value where each index value respectively maps to a predefined reference signal transmission pattern. Alternatively or additionally, the N transmission occasions may be configurable as part of a pattern comprising a group of (e.g., the first 'N1') transmission occasions during which one or more reference signals are transmitted and another group of (e.g. the latter 'N-N1') occasions where reference signals are not transmitted. It will be appreciated that the value of N1 may, itself, be configurable. It will also be appreciated that, in these examples, all the resources belonging to same Set B beams will, beneficially, have the same periodicity value and transmission pattern.

　　Nevertheless, alternatively or additionally, for each AI/ML beam management model configuration, the RAN node 5 may be configured to be able to respectively indicate the measurement occasions for beam prediction to the UE 3. For example, to support time-domain based prediction, the RAN node 5 may be configured to be able to explicitly indicate a pattern for periodic measurements (or inputs) for an AI/ML beam management model where the pattern consists of a certain number (e.g., 'N1') measurement occasions that repeats with a periodicity of 'N' occasions. The RAN node 5 may, for example, indicate which of the 'N' reference signal transmission occasions within a pattern are to be used for beam prediction measurements.

　　For example, the RAN node 5 may be configured to be able to indicate which of the 'N' reference signal transmission occasions within a pattern are to be used for beam prediction measurement by means of a bitmap where each bit within the bitmap corresponds/points to a transmission occasion and the value of the bit ('1' or '0') indicates whether that transmission occasion is to be used for beam prediction measurement (e.g. with the bit set to '1' or '0') or not (e.g. with the bit set to '0' or '1'). Alternatively or additionally, the RAN node 5 may be configured to be able to indicate the beam prediction measurement occasions by means of configuration information that indicates (or points to) an index value where each index value respectively maps to a predefined beam prediction measurement pattern. Alternatively or additionally, the N transmission occasions may be configurable as part of a pattern comprising a group of (e.g., the first 'N1') reference signal transmission occasions during which one or more beam prediction measurements are performed and another group of (e.g. the latter 'N-N1') reference signal transmission occasions beam prediction measurements are not performed. It will be appreciated that the value of N1 may, itself, be configurable.

　　It will be appreciated that whilst the indication of the measurement occasions for beam prediction can be provided explicitly to UE 3 (e.g., using one or more information elements indicating the pattern information), the RAN node 5 may alternatively or additionally be able to provide the indication indirectly, e.g., using a variable/parameter such as a model identifier where an association between that variable/parameter and the pattern of measurement occasions for beam prediction to be used for measurements (or inputs) has been (pre)configured at the UE 3.

Timing for beam prediction
　　The timing for beam predictions may also be indicated in any suitable manner.

　　For example, the UE 3 may be configured to determine the beam prediction occasions based on configured AI/ML based reporting occasions. Specifically, the RAN Node 5 may respectively configure the UE 3 with reporting occasions for each AI/ML model during which the AI/ML prediction output needs to be reported back by the UE 3. Based on the occasions of these reports, the UE 3 may implicitly determine the occasions for performing beam prediction. For example, if the RAN node 5 configures the UE 3 with an AI/ML reporting periodicity of 20ms, where each reporting occasion is to contain the result of a single AI/ML output, then the UE 3 may assume that the AI/ML output is also to be generated every 20ms.

　　It will be appreciated that the reporting occasions may be configured, in a similar manner to the reference signal measurement occasions described above, to follow a periodic pattern (e.g., in which the RAN node 5 indicates using a bitmap, or some other mechanism, which of a number 'M1' of possible reporting occasions - which are repeated with a periodicity of 'M' reporting occasions - should be used for AI/ML based reporting and hence for which an associated measurement prediction should be performed).

　　Nevertheless, alternatively or additionally, for each AI/ML beam management model configuration, the RAN node 5 may be configured to be able to respectively indicate the time occasions to be used for beam predictions to the UE 3. This may be provided as part of configuration information which indicates a format for the output of beam prediction. For example, the RAN node 5, may be able to provide configuration information indicating that each beam prediction output should comprise results of X time occasions and indicating a time gap between the time occasions.

　　It will be appreciated that whilst the indication of the timing for the prediction occasions can be provided explicitly to a UE 3 (e.g., using one or more information elements indicating the time occasions for beam prediction), the RAN node 5 may alternatively or additionally be able to provide the indication indirectly, e.g., using a variable/parameter such as a model identifier where an association between that variable/parameter and the time occasions of beam prediction has been (pre)configured at the UE 3.

Hybrid Temporal and Spatial based Beam Prediction
　　Fig. 11 illustrates a hybrid spatial / temporal approach to beam prediction using AI/ML models that may be used in the communication system 1.

　　As seen in Fig 11, in this hybrid approach beam prediction is based on a spatial based approach during some prediction occasions and a temporal approach during other prediction occasions.

　　Specifically, the beam prediction occasions may also be defined in a manner in which the UE 3 is configured by the RAN node 5 to perform beam predictions for a given number of (e.g., 'N') occasions where the beam prediction output for a subset of (e.g. 'N1') occasions (where N1 is less than N) is based on a different type of AI/ML prediction (spatial verses temporal) than the beam prediction output for the remaining (i.e., N-N1) occasions.

　　For example, the subset of (i.e., the initial N1) prediction occasions may be configured to coincide with transmission occasions of Set B beams, and so the UE 3 may be configured to perform spatial-domain based beam prediction for these occasions. Contrastingly, for the remaining (N-N1) prediction occasions the UE 3 may be configured to perform temporal based beam prediction.

Temporal vs. Spatial (and/or Hybrid) based Beam Prediction
　　It will be appreciated that, the UE 3 may also be informed as to whether an AI/ML model to be used should be an AI/ML model for time-domain based prediction or spatial-domain based prediction, thereby allowing the UE 3 to select an appropriate AI/ML model based on this information.

　　It will be appreciated that the RAN node 5 may explicitly indicate to the UE 3 whether the AI/ML model is for time-domain or spatial-domain based beam prediction (e.g., as part of an AI/ML beam management model configuration, or as separate related information, for the UE 3). Moreover, where the communication system 1 supports combined (or hybrid) temporal/spatial based models, the RAN node 5 may also be configured to indicate whether the AI/ML model is a combination of temporal and spatial (for example, for the scenario discussed with reference to Fig. 11 in which some beam prediction occasions are of a spatial domain type while the remaining beam prediction occasions are of a temporal type).

　　Nevertheless, it will be appreciated that the UE 3 may be configured to determine a type of beam prediction (spatial, temporal, or combined (or hybrid) where applicable) implicitly based on a configuration provided for the measurement occasions of the Set B beams and/or prediction occasions for AI/ML based beam predictions. For example, if the RAN node 5 indicates to a UE 3 that each beam prediction output comprises more than one time occasions, then the UE 3 may assume that the beam prediction is of a temporal type. Contrastingly, if the RAN node 5 indicates to a UE 3 that the beam prediction occasions and measurement occasions (at least partially) coincide, then the UE 3 may assume that the beam prediction is of a spatial (or possibly combined (or hybrid)) type.

Activation of an AI/ML Model
　　As mentioned above, the UE 3 and RAN node 5 of the communication system 1 may be mutually configured to coordinate with one another to support: explicit activation of an inference operation at the UE 3, by the RAN node 5, after an initial configuration (or reconfiguration) of an associated AI/ML feature/model; and 'automatic' activation after initial configuration (or reconfiguration) of an associated AI/ML feature/model (i.e., without an explicit activation command) albeit potentially after a (pre)configured activation delay.

　　It will be appreciated that whilst these activation techniques will be described in the context of AI/ML models for beam prediction, the activation techniques may be applied, where appropriate, to any type of AI/ML model/feature (e.g., for beam prediction, for CSI compression, and/or the like).

　　Fig. 12 is a simplified sequence diagram illustrating a first method of activating AI/ML operation in the communication system 1.

　　As seen in Fig. 12, in this method the UE 3 automatically activates AI/ML following initial configuration of the AI/ML model to be used for AI/ML enhanced beam management.

　　Specifically, when the RAN node 5 configures AI/ML beam prediction as indicated at S1202, the RAN node 5 indicates, within the AI/ML beam prediction configuration whether: 'activation on configuration' (i.e., activation automatically by the UE 3 after receipt and processing of the configuration) is to be used or whether an explicit activation command is required to activate/deactivate the AI/ML model associated with the AI/ML beam prediction configuration. In this example, activation on configuration is configured by setting an activation on configuration information element (e.g., a flag, single bit, or the like) in the AI/ML beam prediction configuration to 'true' (e.g., '1'). However, it will be appreciated that activation on configuration may be indicated in any suitable manner, for example, by setting an explicit 'activation required' information element (e.g., a flag, single bit, or the like) to 'false' (e.g., '0')), implicitly based on other information in the AI/ML beam prediction configuration, or the like.

　　The AI/ML beam prediction configuration may also include any other information required for selection/configuration of the AI/ML model at the UE 3 (e.g., all or an appropriate subset of the configuration and/or assistance information/parameters described earlier. In this example, the AI/ML beam prediction configuration includes (but is not limited to) a Set B measurement configuration, a beam prediction output configuration, and a reporting configuration in addition to the activation on configuration information element.

　　This AI/ML beam prediction configuration may, for example, be provided via RRC signalling.

　　 The UE 3 then selects/configures an AI/ML model to be used for beam prediction appropriately and, following an appropriate activation delay (T_AD), the UE 3 automatically activates AI/ML beam prediction operation at the UE 3 at S1206.

　　The activation delay in this example (where an explicit activation command is not required) may, for example, comprise a time period associated with an RRC message processing delay and implementing the AI/ML configuration at UE. This delay may, for example, be specified by means of a dedicated AI/ML configuration update delay parameter (which may be preconfigured at the UE 3 or provided by the RAN node 5) indicating an AI/ML delay time to be used at the UE 3. This AI/ML delay time may then be added to an assumed RRC processing delay for processing RRC messages at that UE 3 to provide an overall activation delay to be used at the UE 3. The AI/ML delay time value may be variable (or selectable from a number of alternatives), for example, it may depend on the size/composition of the AI/ML model to be used (e.g., based on the number of inputs, number of outputs, and/or number of layers). It will also be appreciated that the delay value may, alternatively or additionally, depend on the AI/ML application type/feature being used (e.g., whether for beam prediction (as in this example), CSI compression, and/or the like).

　　Alternatively, the activation delay may be a new dedicated value (which may be preconfigured at the UE 3 or provided by the RAN node 5) that is specified for combined processing and updating of an AI/ML configuration at UE 3. This dedicated AI/ML delay time value may also be variable (or selectable from a number of alternatives).

　　Accordingly, after the activation delay, when the RAN node 5 performs, at S1208-1, reference signal transmissions for the Set B beams the UE 3 can perform associated measurements for the Set B beams at S1210-1 (e.g., in configured measurement occasions), for example as described with reference to Fig. 8, steps S800 and S802. Hence the UE 3 can perform one or more corresponding Set A predictions at S1212-1 (e.g., for one or more configured prediction occasions) and provide one or more associated AI/ML reports to the RAN node 5 (at S1214-1), for example as described with reference to Fig. 8, steps S804 and S806. The AI/ML report may, for example, indicate one or more top ranked beams of Set A according to the prediction (e.g., as described with reference to step S806 in Fig. 8).

　　It will be appreciated that, whilst not illustrated, where more than one predicted top ranked beam is indicated for set A, the Set A beams may be subject to further refinement, for example in the manner described with reference to Fig. 8, steps S808 to S812. Moreover receive beam refinement may also take place (e.g., as described with reference to Fig. 8, steps S814 and S818).

　　The measurement, prediction, and reporting steps may be performed periodically (e.g., in accordance with periodic reference signal transmissions in the Set B beams) as indicated at S1208-2 to S1214-2.

　　Fig. 13 is a simplified sequence diagram illustrating a second method of activating AI/ML operation in the communication system 1.

　　As seen in Fig. 13, in this method the UE 3 only activates AI/ML after receiving an explicit AI/ML activation command from the RAN node 5.

　　Specifically, when the RAN node 5 configures AI/ML beam prediction as indicated at S1302, the RAN node 5 indicates, within the AI/ML beam prediction configuration whether: 'activation on configuration' (i.e., activation automatically by the UE 3 after receipt and processing of the configuration) is to be used or whether an explicit activation command is required to activate/deactivate the AI/ML model associated with the AI/ML beam prediction configuration. In this example, a requirement for an explicit activation command is configured by setting an activation on configuration information element (e.g., a flag, single bit, or the like) in the AI/ML beam prediction configuration to 'false' (e.g., '0'). However, it will be appreciated that activation on configuration may be indicated in any suitable manner, for example, by setting an explicit 'activation required' information element (e.g., a flag, single bit, or the like) to 'true' (e.g., '1')), implicitly based on other information in the AI/ML beam prediction configuration, or the like.

　　The AI/ML beam prediction configuration may also include any other information required for selection/configuration of the AI/ML model at the UE 3 (e.g., all or an appropriate subset of the configuration and/or assistance information/parameters described earlier. In this example, the AI/ML beam prediction configuration includes (but is not limited to) a Set B measurement configuration, a beam prediction output configuration, and a reporting configuration in addition to the activation on configuration information element.

　　This AI/ML beam prediction configuration may, for example, be provided via RRC signalling.

　　The UE 3 then selects/configures an AI/ML model to be used for beam prediction appropriately. However, the UE 3 waits to activate AI/ML beam prediction operation at the UE 3 until the RAN node 5 sends an explicit AI/ML activation command at S1304 (which the RAN node 5 may be configured to be able to provide via an AI/ML activation MAC control element (CE) and/or via DCI).

　　After receiving the AI/ML activation command, following an appropriate activation delay (T_AD), the UE 3 activates AI/ML beam prediction operation at the UE 3 at S1306.

　　The activation delay in this example (where an explicit activation command is required) may, for example, comprise a time period ('T₁') in combination with a time period/delay associated with AI/ML processing. The time period, T₁, may, for example, correspond to a time period associated with providing acknowledgement feedback to the RAN node 5 (e.g., a hybrid automatic repeat request (HARQ) feedback time associated with the transmission of a HARQ acknowledgement of the AI/ML activation MAC CE (if used for activation of the AI/ML configuration)). It will be appreciated that T₁ may be zero for DCI based activation of the AI/ML configuration.

　　The AI/ML processing delay time value may be variable (or selectable from a number of alternatives), for example, it may depend on the size/composition of the AI/ML model to be used (e.g., based on the number of inputs, number of outputs, and/or number of layers). It will also be appreciated that the delay value may, alternatively or additionally, depend on the AI/ML application type/feature being used (e.g., whether for beam prediction (as in this example), CSI compression, and/or the like). It will be appreciated that this d AI/ML processing delay be same as the AI/ML configuration update delay parameter defined for the RRC based ('automatic') activation described with reference to Fig. 12 above.

　　Accordingly, after the activation delay, when the RAN Node 5 performs, at S1308-1, reference signal transmissions for the Set B beams the UE 3 can perform associated measurements for the Set B beams at S1310-1 (e.g., in configured measurement occasions), for example as described with reference to Fig. 8, steps S800 and S802. Hence the UE 3 can perform one or more corresponding Set A predictions at S1312-1 (e.g., for one or more configured prediction occasions) and provide one or more associated AI/ML reports to the RAN node 5 (at S1314-1), for example as described with reference to Fig. 8, steps S804 and S806. The AI/ML report may, for example, indicate one or more top ranked beams of Set A according to the prediction (e.g., as described with reference to step S806 in Fig. 8).

　　It will be appreciated that, whilst not illustrated, where more than one predicted top ranked beam is indicated for set A, the Set A beams may be subject to further refinement, for example in the manner described with reference to Fig. 8, steps S808 to S812. Moreover receive beam refinement may also take place (e.g., as described with reference to Fig. 8, steps S814 and S818).

　　The measurement, prediction, and reporting steps may be performed periodically (e.g., in accordance with periodic reference signal transmissions in the Set B beams) as indicated at S1308-2 to S1314-2.

Reconfiguration of an AI/ML Model
　　As mentioned above, to support the UE-sided AI/ML enhanced beam management procedure, the UE 3 and RAN node 5 may be mutually configured to coordinate with one another to support the UE 3 handling scenarios in which one or more parameters of an AI/ML model require reconfiguration after an AI/ML model has been activated (and is therefore running).

　　It will be appreciated that whilst these reconfiguration techniques will be described in the context of AI/ML models for beam prediction, the reconfiguration techniques may be applied, where appropriate, to any type of AI/ML model/feature (e.g., for beam prediction, for CSI compression, and/or the like).

　　As mentioned above, in one example the AI/ML operation pauses but continues running the new/reconfigured AI/ML model immediately upon reconfiguration, whereas in another example, the UE 3 deactivates/disables the running of a current AI/ML model and only activates the new/reconfigured AI/ML model when instructed to do so. It will be appreciated that the behaviour that the UE 3 that UE adopts in response to receiving a new/updated AI/ML model configuration may be dependent on whether or not the new/updated (or possibly the currently implemented) AI/ML configuration indicates that 'activation on configuration' is allowed or an 'activation command is required' to activate the configuration (e.g., as described with reference to Figs. 12 and 13 above).

　　Fig. 14 is a simplified sequence diagram illustrating a first method of activating AI/ML operation following AI/ML model update/reconfiguration in the communication system 1.

　　As seen in Fig. 14, in this example the AI/ML operation pauses but continues running the new/reconfigured AI/ML model immediately upon reconfiguration (e.g., because explicit activation is not required), and so the UE 3 can start operating the new/updated AI/ML model immediately after receiving and applying the new/updated configuration (which may or may not also lead to change in AI/ML model). In some aspects, the UE 3 may continue running the AI/ML model upon reconfiguration if the reconfiguration does not modify the AI/ML model inference operation. For example, if the reconfiguration modifies the monitoring parameters of the AI/ML model but does not change the inference parameters (no change in Set-A beams, Set-B beams, Set-B measurement occasions, predictions occasions), then UE shall continue to run the AI/ML model and shall apply the new configuration for the monitoring procedure after receiving reconfiguration message.

　　Specifically, in Fig. 14, initially a previously activated AI/ML beam prediction is ongoing at the UE 3 at S1400. Then at S1402 the RAN node 5 provides an updated/new configuration for AI/ML beam prediction as indicated at S1402 (e.g., using appropriate RRC signalling or the like). This updated/new configuration for AI/ML beam prediction may be a full configuration or partial (e.g., delta) and may include all, or a subset of the information described above with reference to Fig. 12 and/or Fig. 13.

　　After receiving the updated/new configuration for AI/ML beam prediction as indicated at S1402 ongoing AI/ML operation is only paused for the time required for the UE to process and apply the new/updated AI/ML beam prediction configuration. After the processing delay ('T_P') associated with this, the UE 3 continues, at S1407, running AI/ML based beam prediction based on the new/reconfigured AI/ML model arising from the reconfiguration.

　　It will be appreciated that the time to apply the updated configuration (and hence the processing delay, T_P) may be different depending on whether or not an AI/ML model change is required at the UE 3. It will also be appreciated that the processing delay may depend on several factors including, for example, the AI/ML model type/feature, the size/composition of the AI/ML model (number of inputs, number of outputs, number of layers, or the like), whether the update results in an AI/ML model which has the same shape/size as the current AI/ML model operating at UE 3, and/or the like.

　　Accordingly, after the processing delay, when the RAN Node 5 performs, at S1408-1, reference signal transmissions for the Set B beams the UE 3 can perform associated measurements for the Set B beams at S1410-1 (e.g., possibly in newly/updated configured measurement occasions), for example as described with reference to Fig. 8, steps S800 and S802. Hence the UE 3 can perform one or more corresponding Set A predictions at S1412-1 (e.g., possibly for one or more newly/updated configured prediction occasions) and provide one or more associated AI/ML reports to the RAN node 5 (at S1414-1), for example as described with reference to Fig. 8, steps S804 and S806. The AI/ML report may, for example, indicate one or more top ranked beams of Set A according to the prediction (e.g., as described with reference to step S806 in Fig. 8).

　　It will be appreciated that, whilst not illustrated, where more than one predicted top ranked beam is indicated for set A, the Set A beams may be subject to further refinement, for example in the manner described with reference to Fig. 8, steps S808 to S812. Moreover receive beam refinement may also take place (e.g., as described with reference to Fig. 8, steps S814 and S818).

　　The measurement, prediction, and reporting steps may be performed periodically (e.g., in accordance with periodic reference signal transmissions in the Set B beams) as indicated at S1408-2 to S1414-2.

　　Fig. 15 is a simplified sequence diagram illustrating a second method of activating AI/ML operation following AI/ML model update/reconfiguration in the communication system 1.

　　As mentioned above, in another example, the UE 3 deactivates/disables the running of a current AI/ML model and only activates the new/reconfigured AI/ML model when instructed to do so.

　　As seen in Fig. 15, in this example the AI/ML operation is deactivated/disabled and the new/reconfigured AI/ML model is only activated when the UE 3 is instructed to do so (e.g., because explicit activation is required).

　　Specifically, in Fig. 15, initially a previously activated AI/ML beam prediction is ongoing at the UE 3 at S1500. Then at S1502 the RAN node 5 provides an updated/new configuration for AI/ML beam prediction as indicated at S1502 (e.g., using appropriate RRC signalling or the like). This updated/new configuration for AI/ML beam prediction may be a full configuration or partial (e.g., delta) and may include all, or a subset of the information described above with reference to Fig. 12 and/or Fig. 13.

　　In this example, after receiving the updated/new configuration for AI/ML beam prediction as indicated at S1502 ongoing AI/ML operation is disabled/deactivated at S1503 and is only resumed after receipt of an explicit AI/ML activation command at S1504 from the RAN node 5 (which the RAN node 5 may be configured to be able to provide via an AI/ML activation MAC control element (CE) and/or via DCI). It will be appreciated that, where activation is required the UE 3 may disable/deactivate the currently running model when it receives a new configuration which leads to change in the AI/ML model. Nevertheless, the UE 3 may switch to a new model immediately after receiving a new configuration, if the previous model was already activated.

　　After receiving the AI/ML activation command, following an appropriate activation delay (T_AD), the UE 3 activates AI/ML beam prediction operation based on the new/updated AI/ML configuration at the UE 3 at S1506.

　　The activation delay in this example may, for example, comprise a time period ('T₁') in combination with a time period/delay associated with AI/ML processing. The time period, T₁, may, for example, correspond to a time period associated with providing acknowledgement feedback to the RAN node 5 (e.g., a hybrid automatic repeat request (HARQ) feedback time associated with the transmission of a HARQ acknowledgement of the AI/ML activation MAC CE (if used for activation of the AI/ML configuration)). It will be appreciated that T₁ may be zero for DCI based activation of the AI/ML configuration.

　　The AI/ML processing delay time value may be variable (or selectable from a number of alternatives), for example, it may depend on the size/composition of the AI/ML model to be used (e.g., based on the number of inputs, number of outputs, and/or number of layers). It will also be appreciated that the delay value may, alternatively or additionally, depend on the AI/ML application type/feature being used (e.g., whether for beam prediction (as in this example), CSI compression, and/or the like). It will be appreciated that this d AI/ML processing delay be same as the AI/ML processing delay described with reference to Fig. 14 above.

　　Accordingly, after the activation delay, when the RAN Node 5 performs, at S1508-1, reference signal transmissions for the Set B beams the UE 3 can perform associated measurements for the Set B beams at S1510-1 (e.g., possibly in newly/updated configured measurement occasions), for example as described with reference to Fig. 8, steps S800 and S802. Hence the UE 3 can perform one or more corresponding Set A predictions at S1512-1 (e.g., possibly for one or more newly/updated configured prediction occasions) and provide one or more associated AI/ML reports to the RAN node 5 (at S1514-1), for example as described with reference to Fig. 8, steps S804 and S806. The AI/ML report may, for example, indicate one or more top ranked beams of Set A according to the prediction (e.g., as described with reference to step S806 in Fig. 8).

　　It will be appreciated that, whilst not illustrated, where more than one predicted top ranked beam is indicated for set A, the Set A beams may be subject to further refinement, for example in the manner described with reference to Fig. 8, steps S808 to S812. Moreover receive beam refinement may also take place (e.g., as described with reference to Fig. 8, steps S814 and S818).

　　The measurement, prediction, and reporting steps may be performed periodically (e.g., in accordance with periodic reference signal transmissions in the Set B beams) as indicated at S1508-2 to S1514-2.

BWP/Carrier Aggregation Operation
　　As mentioned above the communication system 1 may support the possible generation of a plurality of beam prediction configurations for a given AI/ML model where each beam prediction configuration may be respectively associated with one or more serving cells. Moreover, as mentioned above, the communication system 1 may support the possible generation of a one or more beam prediction configurations for a given AI/ML model where each beam prediction configuration may respectively include a plurality of independent BWP associated parameter sets.

　　Fig. 16 illustrates one example of how AI/ML beam prediction configurations may be configured in the communication system 1.

　　Referring to Fig. 16, each beam prediction configuration for a model may be associated with one or more serving cells. Moreover, as seen in Fig. 16, each serving cell may be associated with one or more beam prediction configurations.

　　A beam prediction configuration may, for example, be identified using a specific index value which is associated with one or more serving cells, for example a plurality of serving cells that share a common beam set, (e.g. cells within the same RF band).

　　Moreover, each beam prediction configuration for a UE 3 may include one or more 'BWP specific' sets of parameters which are provided independently for different BWPs configured for that UE 3. For example, the RAN node 5 may be configured to be able to configure at least some parameters (such as Set B resources, e.g., CSI-RS and/or SSB resources) on a per BWP basis. Similarly, the RAN node 5 may also be configured to be able to configure the resources for reporting AI/ML predictions (e.g., PUCCH resources) on a BWP specific basis.

　　Nevertheless, other parameters on which determination of the beam prediction model at UE may be based (e.g., the number of Set B and/or number of Set A beams and/or the beam prediction output configuration) may be common for different BWPs.

Action on BWP/Cell change
　　As mentioned above, the UE 3 may be configured to perform AI/ML enhanced beam management in a manner that takes appropriate account of any change in the serving cell or the BWP at the UE 3 (e.g., depending on any differences in the cell specific beam prediction configurations / BWP specific parameters that are associated with the old/new BWP).

　　For example, when there is a change in a BWP at the UE 3, if there are no resources available for the Set B beams/RS, or no reporting resources are available, then the UE 3 may be configured not to enable an AI/ML model / AI/ML enhanced beam management for that BWP. Otherwise, if all necessary configuration information is available for the new BWP, then the UE 3 may be configured to simply continue the AI/ML model operation (albeit potentially reconfigured based a different set of configuration parameters for that BWP).

　　Similarly, when the cell configuration is modified at the UE 3, the UE 3 may be configured to continue to run the AI/ML model for the modified cell configuration, unless the AI/ML configuration related to running AI/ML enhanced beam management has been updated as a result of the cell configuration change.

Activation command implementation
　　Beneficially, in support of one or more of the above methods, where an activation command is used in respect of AI/ML operation (e.g., as described with reference to Figs. 13 and/or 15) the activation command may be enhanced to be able to indicate additional information (beyond simply that the AI/ML model should be activated).

　　For example, the activation command may be able to indicate AI/ML feature/model type, for example, whether the activation command is for beam management, CSI-compression, and/or the like. It will be appreciated that whilst this information may be provided explicitly within a single common activation command, it is possible that different activation command messages may be defined for different AI/ML features/model types.

　　The activation command may also be configurable to provide serving cell information and/or an AI/ML beam prediction config identifier. Nevertheless, some information (e.g., serving cell information) may be derivable implicitly by the UE 3 based on the serving cell or radio resources via which the activation command is received. For example, where the activation command is DCI based then the serving cell via which the UE 3 receives the activation command may be determined to be the serving cell for which the AI/ML beam prediction configuration to which the activation command relates is applicable.

　　Moreover, serving cell information and a beam prediction configuration identifier may be provided separately or jointly coded. For example, the activation command may be configurable to include serving cell information and an AI/ML beam prediction config identifier separately within that activation command.

　　Alternatively or additionally, the activation command may be configurable to only include a beam prediction configuration identifier and the beam prediction config identifier may be uniquely defined for each beam prediction configuration on a per UE basis. Thus, the UE 3 may be able to determine the serving cell information by looking up the serving cells which are associated with a beam prediction configuration identified by a received (unique) prediction config identifier.

　　It will be appreciated that the activation command may also be used for deactivation of AI/ML operation in which case, the activation command may also indicate whether the associated AI/ML configuration is to be activated or deactivated.

　　It will be appreciated that a plurality of sets of any of the above information may be included in the activation command, e.g., respectively for each of a plurality of different beam prediction configurations provided within the activation command.

　　Upon receiving the activation command, the UE 3 may activate (or deactivate) the associated AI/ML beam prediction configuration applicable to the current active BWP.

User Equipment
　　Fig. 17 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

　　As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN node 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE 3 (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and/or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and/or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

　　The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communication control module 43.
The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5 (and other communication devices connected to the RAN node 5, such as further UEs and/or core network nodes). The communication control module 43 is configured for the overall handling of uplink communication via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and/or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communication via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and/or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission/reception of UL/DL communication (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots/symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

　　It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

　　The communication control module 43 is configured, in particular, to control the UE's communication, where applicable, in accordance with any of the methods described herein.

RAN node
　　Figure 18 is a schematic block diagram illustrating the main components of the RAN node 5 for the communication system 1 shown in Figure 1. As shown, the RAN node 5 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antennas 53 (e.g. a single or multi-panel antenna array / massive antenna), and a core network interface 55 (e.g. comprising the N2, N3 and other reference points/interfaces) for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5 may also be coupled to other RAN nodes via an appropriate interface (e.g. the so-called 'Xn' interface in NR). The RAN node 5 has a controller 57 to control the operation of the RAN node 5. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and/or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5 by, in this example, program instructions or software instructions stored within memory 59.

　　As shown, these software instructions include, among other things, an operating system 61, and a communication control module 63.

　　The communication control module 63 is operable to control the communication between the RAN node 5 and UEs 3 and other network entities that are connected to the RAN node 5. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communication, via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), a random-access channel (RACH), and/or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 63 is also configured for the overall handling the transmission of downlink communication via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and/or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communication control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots/symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

　　It will be appreciated that the communication control module 63 may include a number of sub-modules (or 'layers') to support specific functionalities. For example, the communication control module 63 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc.

　　The communication control module 63 is configured, in particular, to control the RAN node's communication, where applicable, in accordance with any of the methods described herein.

Modifications and Alternatives
　　As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above example embodiments whilst still benefiting from the disclosure embodied therein.

　　Whilst the above examples have been described with reference to an AI/ML model, it will be appreciated that the above described methods are advantageous even when the model is not an AI/ML model. Any other suitable type of model or function may be used to generate inferences (e.g. determinations or predictions).

　　It will be appreciated, for example, that whilst cellular communication generation (2G, 3G, 4G, 5G, 6G etc.) specific terminology may be used, in the interests of clarity, to refer to specific communication entities, the technical features described for a given entity are not limited to devices of that specific communication generation. The technical features may be implemented in any functionally equivalent communication entity regardless of any differences in the terminology used to refer to them.

　　In the above description, the UEs and the RAN node are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

　　In the above example embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the RAN node or the UE in order to update their functionalities.

　　Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

　　The RAN node may comprise a 'distributed' RAN node having a central unit 'CU' and one or more separate distributed units (DUs).

　　The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

　　It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

　　The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for a long period of time.

　　A UE may, for example, be an item of equipment for production or manufacture and/or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and/or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and/or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and/or related machinery; paper converting machinery; chemical machinery; mining and/or construction machinery and/or related equipment; machinery and/or implements for agriculture, forestry and/or fisheries; safety and/or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and/or application systems for any of the previously mentioned equipment or machinery etc.).

　　A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.). A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

　　A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and/or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

　　A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

　　A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and/or system, a weapon, an item of cutlery, a hand tool, or the like.

　　A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

　　A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and/or wireless communication technologies.

　　Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and/or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and/or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored/tracked.

　　It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

　　It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

　　Applications, services, and solutions may be an MVNO (Mobile Virtual Network Operator) service, an emergency radio communication system, a PBX (Private Branch eXchange) system, a PHS/Digital Cordless Telecommunications system, a POS (Point of sale) system, an advertise calling system, an MBMS (Multimedia Broadcast and Multicast Service), a V2X (Vehicle to Everything) system, a train radio system, a location related service, a Disaster/Emergency Wireless Communication Service, a community service, a video streaming service, a femto cell application service, a VoLTE (Voice over LTE) service, a charging service, a radio on demand service, a roaming service, an activity monitoring service, a telecom carrier/communication NW selection service, a functional restriction service, a PoC (Proof of Concept) service, a personal information management service, an ad-hoc network/DTN (Delay Tolerant Networking) service, etc.

　　Further, the above-described UE categories are merely examples of applications of the technical ideas and example embodiments described in the present document. Needless to say, these technical ideas and example embodiments are not limited to the above-described UE and various modifications can be made thereto.

　　Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

　　For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes.
　　(Supplementary note 1)
　　A method performed by a mobile device, the method comprising:
　　receiving configuration information indicating which model for artificial intelligence / machine learning (AI/ML) should be used for beam management; and
　　performing the beam management using the configuration information, and
　　wherein the configuration information includes:
　　　　first information regarding a set 'B' of measured beams used for measurements for the beam management;
　　　　second information regarding a set 'A' of beams to be predicted, based on the measurements.
　　(Supplementary note 2)
　　The method according to supplementary note 1, wherein
　　the configuration information includes an identity indicating at least one property which at least one of beams in the set 'B' or beams in the set 'A' has.
　　(Supplementary note 3)
　　The method according to supplementary note 2, wherein
　　the at least one property includes at least one of:
　　　　configuration of at least one transmission pattern for beams,
　　　　antenna configuration,
　　　　a model or a functionality of the model, for the AI/ML to be used for prediction, or
　　　　a data set to be used for prediction.
　　(Supplementary note 4)
　　The method according to any one of supplementary notes 1 to 3, wherein
　　the configuration information includes information indicating a respective resource of each of beams in the set 'A' and/or the set 'B'.
　　(Supplementary note 5)
　　The method according to any one of supplementary notes 1 to 4, wherein
　　the configuration information includes information indicating a number of beams in the set 'A' and/or the set 'B'.
　　(Supplementary note 6)
　　The method according to any one of supplementary notes 1 to 5, wherein
　　the configuration information includes information indicating a respective type of beams per beam in the set 'A' and/or the set 'B'.
　　(Supplementary note 7)
　　The method according to any one of supplementary notes 1 to 6, wherein
　　the configuration information includes at least one of:
　　　　information indicating measurement occasions for the measurements of the measured beams, or
　　　　information indicating prediction occasion for prediction of the beams to be predicted.
　　(Supplementary note 8)
　　The method according to any one of supplementary notes 1 to 7, wherein
　　the configuration information includes information indicating a domain type for prediction, and
　　the domain type includes:
　　　　a time domain, or
　　　　a spatial domain.
　　(Supplementary note 9)
　　The method according to any one of supplementary notes 1 to 8, wherein
　　the configuration information includes information indicating a domain type for prediction.
　　(Supplementary note 10)
　　The method according to any one of supplementary notes 1 to 9, wherein
　　a respective prediction occasion for the beams to be predicted corresponds to at least one of:
　　　　a respective measurement occasion for the measured beams, or
　　　　a reporting occasion for an output of prediction.
　　(Supplementary note 11)
　　The method according to any one of supplementary notes 1 to 10, wherein
　　the configuration information includes information indicating a frequency band or a frequency for prediction.
　　(Supplementary note 12)
　　The method according to any one of supplementary notes 1 to 11, further comprising:
　　determining a domain type of prediction based on the configuration information.
　　(Supplementary note 13)
　　The method according to any one of supplementary notes 1 to 12, further comprising:
　　determining a model used for prediction based on the configuration information.
　　(Supplementary note 14)
　　The method according to any one of supplementary notes 1 to 13, wherein
　　the configuration information includes information indicating when the performing the beam management should be initiated.
　　(Supplementary note 15)
　　The method according to any one of supplementary notes 1 to 14, wherein
　　the performing the beam management is performed upon:
　　　　receiving the configuration information, or
　　　　receiving an activation command for the beam management.
　　(Supplementary note 16)
　　The method according to supplementary note 15, wherein
　　the activation command includes at least one of:
　　　　information indicating at least one feature of the AI/ML,
　　　　information indicating a part of the configuration information, or
　　　　information indicating a respective serving cell for which the part of the configuration information is applied.
　　(Supplementary note 17)
　　The method according to any one of supplementary notes 1 to 16, further comprising:
　　receiving information for updating the configuration information; and
　　performing the beam management using updated configuration information.
　　(Supplementary note 18)
　　The method according to supplementary note 17, further comprising:
　　changing a model for prediction based on the updated configuration information.
　　(Supplementary note 19)
　　The method according to any one of supplementary notes 1 to 18, wherein
　　the configuration information corresponds to one or more serving cells for the mobile device.
　　(Supplementary note 20)
　　The method according to any one of supplementary notes 1 to 19, wherein
　　the configuration information includes parameters correspond to one or more bandwidth parts configured by the mobile device.
　　(Supplementary note 21)
　　The method according to any one of supplementary notes 1 to 20, further comprising:
　　in a case where the mobile device changes a bandwidth part or a serving cell for transmission, determining whether to continue the beam management based on whether all configuration configured by the configuration information is available for a changed bandwidth part.
　　(Supplementary note 22)
　　A method performed by an access network node, the method comprising:
　　transmitting configuration information indicating which model for artificial intelligence / machine learning (AI/ML) should be used for beam management,
　　wherein the configuration information is used by a mobile terminal to perform the beam management, and
　　wherein the configuration information includes at least one of:
　　　　first information regarding a set 'B' of measured beams used for measurements for the beam management, or
　　　　second information regarding a set 'A' of beams to be predicted, based on the measurements.
　　(Supplementary note 23)
　　A mobile device comprising:
　　means for receiving configuration information indicating which model for artificial intelligence / machine learning (AI/ML) should be used for beam management; and
　　means for performing the beam management using the configuration information, and
　　wherein the configuration information includes at least one of:
　　　　first information regarding a set 'B' of measured beams used for measurements for the beam management, or
　　　　second information regarding a set 'A' of beams to be predicted, based on the measurements.
　　(Supplementary note 24)
　　An access network node comprising:
　　means for transmitting configuration information indicating which model for artificial intelligence / machine learning (AI/ML) should be used for beam management,
　　wherein the configuration information is used by a mobile terminal to perform the beam management, and
　　wherein the configuration information includes at least one of:
　　　　first information regarding a set 'B' of measured beams used for measurements for the beam management, or
　　　　second information regarding a set 'A' of beams to be predicted, based on the measurements.

　　This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2402146.1, filed on February 15, 2024, the disclosure of which is incorporated herein in its entirety by reference.

1 COMMUNICATION SYSTEM
3 USER EQUIPMENT
5 BASE STATION
7 CORE NETWORK
9 CELL
10 CONTROL PLANE FUNCTIONS
11 USER PLANE FUNCTIONS
21 EXTERNAL DATA NETWORK
31 TRANSCEIVER CIRCUIT
33 ANTENNA
35 USER INTERFACE
37 CONTROLLER
39 MEMORY
41 OPERATING SYSTEM
43 COMMUNICATIONS CONTROL MODULE
51 TRANSCEIVER CIRCUIT
53 ANTENNA
55 CORE NETWORK INTERFACE
57 CONTROLLER
59 MEMORY
61 OPERATING SYSTEM
63 COMMUNICATIONS CONTROL MODULE
341 DATA COLLECTION
343 MODEL TRAINING
345 INFORENCE
347 ACTOR
349 MANAGEMENT
351 MODEL STORAGE

Claims (24)

1. 　　A method performed by a mobile device, the method comprising:
   　　receiving configuration information indicating which model for artificial intelligence / machine learning (AI/ML) should be used for beam management; and
   　　performing the beam management using the configuration information, and
   　　wherein the configuration information includes:
   　　　　first information regarding a set 'B' of measured beams used for measurements for the beam management;
   　　　　second information regarding a set 'A' of beams to be predicted, based on the measurements.
2. 　　The method according to claim 1, wherein
   　　the configuration information includes an identity indicating at least one property which at least one of beams in the set 'B' or beams in the set 'A' has.
3. 　　The method according to claim 2, wherein
   　　the at least one property includes at least one of:
   　　　　configuration of at least one transmission pattern for beams,
   　　　　antenna configuration,
   　　　　a model or a functionality of the model, for the AI/ML to be used for prediction, or
   　　　　a data set to be used for prediction.
4. 　　The method according to any one of claims 1 to 3, wherein
   　　the configuration information includes information indicating a respective resource of each of beams in the set 'A' and/or the set 'B'.
5. 　　The method according to any one of claims 1 to 4, wherein
   　　the configuration information includes information indicating a number of beams in the set 'A' and/or the set 'B'.
6. 　　The method according to any one of claims 1 to 5, wherein
   　　the configuration information includes information indicating a respective type of beams per beam in the set 'A' and/or the set 'B'.
7. 　　The method according to any one of claims 1 to 6, wherein
   　　the configuration information includes at least one of:
   　　　　information indicating measurement occasions for the measurements of the measured beams, or
   　　　　information indicating prediction occasion for prediction of the beams to be predicted.
8. 　　The method according to any one of claims 1 to 7, wherein
   　　the configuration information includes information indicating a domain type for prediction, and
   　　the domain type includes:
   　　　　a time domain, or
   　　　　a spatial domain.
9. 　　The method according to any one of claims 1 to 8, wherein
   　　the configuration information includes information indicating a domain type for prediction.
10. 　　The method according to any one of claims 1 to 9, wherein
    　　a respective prediction occasion for the beams to be predicted corresponds to at least one of:
    　　　　a respective measurement occasion for the measured beams, or
    　　　　a reporting occasion for an output of prediction.
11. 　　The method according to any one of claims 1 to 10, wherein
    　　the configuration information includes information indicating a frequency band or a frequency for prediction.
12. 　　The method according to any one of claims 1 to 11, further comprising:
    　　determining a domain type of prediction based on the configuration information.
13. 　　The method according to any one of claims 1 to 12, further comprising:
    　　determining a model used for prediction based on the configuration information.
14. 　　The method according to any one of claims 1 to 13, wherein
    　　the configuration information includes information indicating when the performing the beam management should be initiated.
15. 　　The method according to any one of claims 1 to 14, wherein
    　　the performing the beam management is performed upon:
    　　　　receiving the configuration information, or
    　　　　receiving an activation command for the beam management.
16. 　　The method according to claim 15, wherein
    　　the activation command includes at least one of:
    　　　　information indicating at least one feature of the AI/ML,
    　　　　information indicating a part of the configuration information, or
    　　　　information indicating a respective serving cell for which the part of the configuration information is applied.
17. 　　The method according to any one of claims 1 to 16, further comprising:
    　　receiving information for updating the configuration information; and
    　　performing the beam management using updated configuration information.
18. 　　The method according to claim 17, further comprising:
    　　changing a model for prediction based on the updated configuration information.
19. 　　The method according to any one of claims 1 to 18, wherein
    　　the configuration information corresponds to one or more serving cells for the mobile device.
20. 　　The method according to any one of claims 1 to 19, wherein
    　　the configuration information includes parameters correspond to one or more bandwidth parts configured by the mobile device.
21. 　　The method according to any one of claims 1 to 20, further comprising:
    　　in a case where the mobile device changes a bandwidth part or a serving cell for transmission, determining whether to continue the beam management based on whether all configuration configured by the configuration information is available for a changed bandwidth part.
22. 　　A method performed by an access network node, the method comprising:
    　　transmitting configuration information indicating which model for artificial intelligence / machine learning (AI/ML) should be used for beam management,
    　　wherein the configuration information is used by a mobile terminal to perform the beam management, and
    　　wherein the configuration information includes at least one of:
    　　　　first information regarding a set 'B' of measured beams used for measurements for the beam management, or
    　　　　second information regarding a set 'A' of beams to be predicted, based on the measurements.
23. 　　A mobile device comprising:
    　　means for receiving configuration information indicating which model for artificial intelligence / machine learning (AI/ML) should be used for beam management; and
    　　means for performing the beam management using the configuration information, and
    　　wherein the configuration information includes at least one of:
    　　　　first information regarding a set 'B' of measured beams used for measurements for the beam management, or
    　　　　second information regarding a set 'A' of beams to be predicted, based on the measurements.
24. 　　An access network node comprising:
    　　means for transmitting configuration information indicating which model for artificial intelligence / machine learning (AI/ML) should be used for beam management,
    　　wherein the configuration information is used by a mobile terminal to perform the beam management, and
    　　wherein the configuration information includes at least one of:
    　　　　first information regarding a set 'B' of measured beams used for measurements for the beam management, or
    　　　　second information regarding a set 'A' of beams to be predicted, based on the measurements.