Unit 1

The method for monitoring and managing AI/ML models across distributed units in base stations addresses the inefficiencies in current communication networks, enhancing the performance and efficiency of AI/ML features.

JP2026522684APending Publication Date: 2026-07-08NEC CORP

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
NEC CORP
Filing Date
2024-07-17
Publication Date
2026-07-08

AI Technical Summary

Technical Problem

Current communication networks lack an effective method for managing artificial intelligence and machine learning (AI/ML) models in distributed base stations, particularly those with central units (CUs) and distributed units (DUs), leading to inefficiencies in monitoring and managing AI/ML features and functions.

Method used

A method is provided for a first unit of a distributed base station to send a request to monitor an AI/ML model to a second unit, receive reporting information, and transmit performance results, enabling effective monitoring and management of AI/ML models across distributed units.

Benefits of technology

This approach enhances the management and monitoring of AI/ML models in distributed base stations, improving the performance and efficiency of AI/ML features and functions within communication networks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026522684000001_ABST
    Figure 2026522684000001_ABST
Patent Text Reader

Abstract

A method is disclosed that is performed by a first unit of a distributed base station. The method includes sending a request to a second unit of the distributed base station to monitor an Artificial Intelligence (AI) / Machine Learning (ML) model, an AI / ML function, or an AI / ML feature; receiving from the second unit report information including at least one of the inference results of the AI / ML model in the second unit and measurements in the second unit that may be used for the monitoring; and sending performance results based on the report information to the second unit.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to a communication system. The present disclosure is not exclusive, but in particular relates to wireless communication systems and their devices operating according to 3rd Generation Partnership Project (3GPP (registered trademark)) standards or their equivalents or derivatives (including LTE Advanced, next generation or 5G networks, future generations, and beyond). The present disclosure is not necessarily exclusive, but is particularly related to providing improved signaling for leveraging artificial intelligence and machine learning (AI / ML) models in "New Radio" systems and similar systems (also referred to as "next generation" systems).

Background Art

[0002] Previous developments of 3GPP standards were referred to as the Long-Term Evolution (LTE) of the Evolved Packet Core (EPC) network and the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), and were generally also referred to as "4G". More recently, the terms "5G" and "new radio" (NR) have begun to be used to refer to evolving communication technologies expected to support various applications and services. Various details of 5G networks are described, for example, in the "NGMN 5G White Paper" V1.0 (Non-Patent Document 2) by the Next Generation Mobile Network (NGMN) Alliance, available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G with the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and 3GPP NextGen core network.

[0003] Under the 3GPP standard, a NodeB (or eNB in ​​LTE, and gNB in ​​5G) is a radio access network (RAN) node (or simply “access node,” “access network node,” or “base station”) through which communication devices (user equipment or “UE”) connect to the core network and communicate with other communication devices or remote servers. For simplicity, this application uses the terms access network node, RAN node, or base station to refer to any such access node.

[0004] For simplicity, this application uses the terms mobile device, user device, or UE to refer to any communication device that can connect to a core network via one or more base stations. While this application may refer to mobile devices in its description, it will be understood that the described technology can be implemented on any communication device (mobile and / or generally fixed) that can connect to a communication network to transmit / receive data, whether such communication device is controlled by human input or by software instructions stored in memory.

[0005] In current 5G architectures, the structure of a gNB can be divided into two or more parts. In some RAN implementations, there are two parts, sometimes called a “control unit,” known as a Central Unit (CU or gNB-CU), and a Distributed Unit (DU or gNB-DU), connected by an F1 interface. This allows for the use of a “split” architecture, typically separating a “higher” CU layer (e.g., not necessarily or not exclusively, such as the Packet Data Convergence Protocol (PDCP) layer and the radio resource control (RRC) layer) from a “lower” DU layer (e.g., not necessarily or not exclusively, such as the Radio Link Control (RLC) layer, the Medium (or sometimes “Multiple Mediums”) Access Control (MAC) layer, and the Physical (PHY) layer), between a particular CU and one or more DUs connected to and controlled by that CU via the F1 interface. Therefore, for example, the upper-layer CU functions of several gNBs can be centrally implemented (for example, by a single processing unit, or in a cloud-based or virtualized system) while each gNB maintains its own separate lower-layer DU functions locally.

[0006] More recently proposed distributed RAN architectures introduce the concept of a Radio Unit (RU), sometimes referred to as a "remote unit," in addition to the CU and DU. In this architecture, the RU is responsible for processing the digital front end (DFE), digital beamforming functions, and lower-level functions, typically related to the PHY layer, while the DU typically handles the upper-level functions of the PHY, RLC, and MAC layers. The CU in this architecture still controls one or more DUs (each DU corresponding to a different gNB) and is responsible for processing upper-layer signaling (typically the RRC and PDCP layers).

[0007] The actual functional partitioning between CUs and DUs (and RUs, where applicable) in these distributed architectures is flexible and allows for optimization of functionality to suit various use cases. In effect, the partitioned architecture enables 5G networks to use various distributions of the protocol stack between CUs and DUs (and RUs, where applicable), depending, for example, midhaul availability and network design.

[0008] The choice of how to partition functions within the architecture is also determined by factors related to the wireless network deployment scenario, constraints, and the corresponding desired use cases. Key considerations include the need to meet specific quality of service requirements for each service provided and for real-time / non-real-time applications, as well as addressing specific user density and load requirements within a given geographical area, and the availability of transport networks with varying performance levels.

[0009] Some of the additional developments in 3GPP concern the use of artificial intelligence (AI) and machine learning (ML), often abbreviated as AI / ML. Several AI / ML use cases are given below (though it should be understood that many more use cases may be defined). Channel State Information (CSI) feedback enhancements: e.g., overhead reduction, improved accuracy, and prediction; Beam management: e.g., beam prediction in the temporal and / or spatial domains for overhead and latency reduction, and improvement of beam selection accuracy; For example, positioning accuracy enhancements for different scenarios, including scenarios with heavy Non-Line-Of-Sight (NLOS) conditions.

[0010] In particular, predictions or inferences generated using AI / ML models can be used as part of various methods to improve the reliability or efficiency of communications within a network. For example, an AI / ML model can be used to predict the path of a UE based on its previous mobility, can be used for beam management (as described above), or can be used in methods of encoding and transmitting information. An AI / ML model may be hosted at a base station (or any other suitable network node), which may perform control over the communication resources of the UEs it serves and / or perform status-related controls for the UEs (e.g., control of UE mobility, or control of the UE's radio resource control (RRC) state) based on inferences generated using the AI / ML model (e.g., decisions or predictions). The base station may also transmit the inferences generated using the model to another node in the network for use by other nodes. Alternatively, an AI / ML model may be hosted at two nodes in the network, for example, at a base station and a UE. In this case, both the base station and the UE may use the model to make decisions and / or predictions. For example, a UE may use the model as part of an encoding process to encode (and / or compress) a CSI for transmission to a base station, as described above, and a base station may use the same model as part of a corresponding decoding (and / or decryption) process to decode a CSI received from a UE.

[0011] 3 rd The Generation Partnership Project (3GPP) is researching how AI / ML capabilities can be leveraged in the context of communication networks. For example, what level of coordination is necessary between the network and the user devices served by the network when deploying AI / ML features? Three "network-UE coordination levels" have been proposed to date. Level x: No coordination between the network and the UE. Specifically, Level x is an implementation-based AI / ML operation without dedicated AI / ML-specific extensions. Level y: Signaling-based coordination without model transfer. For example, this level is applicable when model training is performed offline, the model is registered with the base station, and the UE is offline. Here, the base station and UE are aware of the available models (before operation), and the base station is only required to activate / deactivate the UE-resident model. Level Z: Signaling-based coordination with model transfer.

[0012] Currently, two types of AI / ML models have been proposed. One-sided models: One-sided AI / ML models are deployed (hosted) only on the UE side or the network side. An example of this type of model is beam prediction in time, which can be deployed on the UE side. However, even when a model is one-sided, it will be understood that the model does not necessarily need to be trained at, for example, UE3 or base station 5. For example, the model may be trained at base station 5 or at another node in the network (e.g., a core network node / function) and then sent to UE3 for use at UE3. In other words, an AI / ML model may be trained at another network node and then transferred / deployed to UE3. Two-Sided Model: Alternatively, the AI / ML model may be a "two-sided" model where one AI / ML model is hosted on UE3 and a corresponding AI / ML model is hosted on base station 5 (however, the model does not necessarily have to be hosted on both UE3 and base station 5, and any two other suitable network nodes may be used instead). Such a model may be referred to as a "paired" AI / ML model, on which joint inference is performed (the AI / ML model hosted on UE3 and the AI / ML model hosted on base station 5 may be the same AI / ML model, but do not necessarily have to be the same model). Joint inference includes AI / ML inference where the inference is performed jointly across UE3 and the network. The first part of the inference may be performed by UE3, and then the remaining part may be performed by base station 5 (or on another network-side node). These roles may be reversed so that the first part of the inference is performed on the network side and the second part on the UE side. An example of this type of model may be CSI compression, where the UE performs channel state information (CSI) compression and the network performs CSI decompression. Similar to the one-sided model, one or more two-sided models may be trained at any suitable network node and then transmitted to UE3 and base station 5 (or one or more other nodes).

[0013] As part of 3GPP research, it has been proposed to study the impact on current specifications when supporting multiple AI models for the same function, such as aspects related to procedures and support signaling for model switching and / or selection.

[0014] Further aspects to be considered include the definition (if necessary) of components in AI / ML life cycle management (LCM) and their necessity. Model training Model deployment: This involves compiling the trained AI / ML model, packaging it into an executable format, and delivering it to the target device. Model inference behavior Model selection, activation, deactivation, switching, and fallback behavior: Model selection refers to choosing an AI / ML model from among models with similar functionality. Model switching, that is, switching between groups of models where each model is for a specific scenario / configuration / site. Fallback: Switches off AI / ML operation to run legacy RAN procedures (i.e., non-AI / ML based procedures). Model monitoring; To study AI / ML model monitoring for at least the following purposes: model activation, deactivation, selection, switching, fallback, and updating (including retraining). Model updates: This includes model fine-tuning, retraining, and redevelopment via online / offline training. Model updating, that is, using a single model whose parameters are flexibly updated as the scenarios / configurations / sites experienced by the device change over time. Fine-tuning is one example. Model transfer; UE ability.

[0015] It has been proposed to study LCM procedures based on the fact that AI / ML models have a model ID that has relevant information and / or model functions for at least some AI / ML operations.

[0016] Further proposals have been made to monitor AI / ML models when they are deployed on a communication network. Specifically, the following metrics / methods have been proposed for research on AI / ML model monitoring in lifecycle management. Monitoring based on inference accuracy, including metrics related to key performance indicators (KPIs), and Monitoring based on system performance, including metrics related to system performance KPIs.

[0017] The additional monitoring under consideration relates to monitoring based on data distribution, which can be either input-based, such as monitoring the validity of AI / ML inputs, detecting outliers from the distribution, detecting drifts in the input data, or checking SNR, delay spread, etc., or output-based, such as detecting drifts in the output data. The monitoring can also be based on applicable conditions in a communication system (e.g., related to load, path loss, etc.). The above model monitoring, and any related calculations, can be performed on the network side or the UE side.

[0018] However, an improved method for regulating the management of AI / ML features / functions / models is needed within a communication network, especially when the communication network uses a distributed base station (such as a gNB) that includes a central unit (CU) and one or more distributed units (DU).

Prior Art Documents

Non-Patent Documents

[0019] <00岁0088>

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

Summary of the Invention

Problems to be Solved by the Invention

[0020] The present disclosure aims to provide one or more devices and / or one or more related methods that contribute to meeting the above needs.

Means for Solving the Problems

[0021] In one embodiment, a method is provided that is performed by a first unit of a distributed base station, and the method is Sending a request to monitor an Artificial Intelligence (AI) / Machine Learning (ML) model, AI / ML function, or AI / ML feature to the second unit of a distributed base station, Receiving reporting information from the second unit, including at least one of the inference results of the AI / ML model in the second unit and measurements in the second unit that may be used for monitoring, The performance results based on the reported information will be sent to the second unit, Includes.

[0022] In one embodiment, a first unit of a distributed base station is provided, A means for transmitting a request to monitor an Artificial Intelligence (AI) / Machine Learning (ML) model, AI / ML function, or AI / ML feature to a second unit of a distributed base station, Means for receiving reporting information from a second unit, including at least one of the inference results of an AI / ML model in the second unit and measurements in the second unit that can be used for monitoring, The second unit includes means for transmitting performance results based on the reported information, It is equipped with. [Effects of the Invention]

[0023] According to this disclosure, methods performed by access network nodes, methods performed by user equipment, methods performed by core network nodes, access network nodes, user equipment, and core network nodes can be provided.

[0024] Here, an exemplary embodiment will be described with reference to the attached drawings. [Brief explanation of the drawing]

[0025] [Figure 1] This is a schematic diagram of a mobile ("cellular" or "wireless") communication system 1. [Figure 2] This figure shows a typical frame structure that can be used in communication system 1 shown in Figure 1. [Figure 3] This figure shows a framework for AI / ML models. [Figure 4] This diagram illustrates how to train an AI / ML model and monitor its performance. [Figure 5] This shows the relationships between AI / ML features, functions, and models. [Figure 6] This document describes a method for CU-based model monitoring. [Figure 7] This document describes a method for DU-based model monitoring. [Figure 8] Figure 1 is a schematic block diagram showing the main components of UE3 for communication system 1. [Figure 9] Figure 1 is a schematic block diagram showing the main components of the distributed base station 5 for the communication system 1. [Figure 10] Figure 1 is a schematic block diagram showing the main components of the core network nodes or functions for communication system 1. [Modes for carrying out the invention]

[0026] <Overview> Here, an exemplary communication system is described using general terminology, merely as an example, with reference to Figures 1 to 5.

[0027] Figure 1 schematically shows a mobile ("cellular" or "wireless") communication system 1 to which the examples of this disclosure can be applied.

[0028] In communication system 1, user equipment (UE) 3-1, 3-2, 3-3 (such as mobile phones and / or other mobile devices) can communicate with each other via radio access network (RAN) nodes 5 operating according to one or more compatible radio access technologies (RATs). In the illustrated example, RAN node 5 includes a distributed base station 5 or "gNB" operating one or more associated cells 9. Communication via RAN node 5 is typically routed through an associated core network 7 (such as a 5G / 6G or later generation core network or an evolved packet core network (EPC)).

[0029] As those skilled in the art will understand, three UE3s and one base station 5 are shown in Figure 1 for illustrative purposes, but the system, when implemented, typically includes other base stations 5 and UE3s.

[0030] Each base station 5 controls one or more associated cells 9 directly or indirectly through one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, etc.). It will be understood that base stations 5 may be configured to support 4G, 5G, 6G and / or later generations and / or any other 3GPP or non-3GPP communication protocols.

[0031] In this example, the illustrated RAN node 5 includes a distributed base station comprising at least one distributed unit (DU) 5b (e.g., gNB-DU) and a central unit (CU) 5c (e.g., gNB-CU). CU5c employs separate control plane and user plane functions and is therefore divided into control plane functions (CU-CP) and user plane functions (CU-UP), each communicating with DU5b via appropriate interfaces (e.g., F1-C interface) and (e.g., F1-U interface) (together forming the F1 interface (or "reference point")), and communicating with each other via appropriate interfaces (e.g., E1 interface). In this example, DU5b provides the functionality of the lower part of the PHY layer and therefore includes the physical and virtual elements necessary to communicate with UE3 via the air interface, although it will be understood that RAN node 5 may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing the functionality of the lower part of the PHY layer). Nevertheless, although a distributed RAN node 5 is shown and described, it will be understood that the RAN node 5 may also be provided in a non-distributed form, for example, as an integrated base station 5.

[0032] The UE3s and their service-providing base stations 5 are connected via appropriate air interfaces (such as the so-called "Uu" interface). Neighboring base stations 5 may be connected to each other via appropriate inter-base station interfaces (such as the so-called "X2" interface, "Xn" interface, etc.).

[0033] The core network 7 includes several logical nodes (or "functions") to support communication in the communication system 1. In this example, the core network 7 includes a control plane function (CPF) 10 and one or more network node entities for user data communication (e.g., a user plane function (UPF) 11). The CPF 10 includes one or more network node entities for control signaling communication (e.g., an Access and Mobility Management Function (AMF) 10-1), one or more network node entities for session management (e.g., a Session Management Function (SMF) 10-2), and several other functions 10-n (e.g., an Authentication Server Function (AUSF) to facilitate security processes, Unified Data Management (UDM) entities for managing user-specific data (e.g., access permissions, user registration, and data network profiles), a Policy Control Function (PCF), an Application Function (AF), etc.). It will be understood that nodes or functions may have different names in different systems.

[0034] RAN node 5 is connected to the core network nodes via appropriate interfaces (or "reference points"), such as the N2 reference point between RAN's CU5c (CU-CP) and AMF10-1 for control signaling communication, and the N3 reference point between RAN's CU5c (CU-UP) and each UPF11 for user data communication. Each of the multiple UE3s is connected to AMF10-1 via a non-access stratum (NAS) connection on an appropriate interface (e.g., an N1 reference point (similar to the S1 reference point in LTE)). It will be understood that N1 communication is routed transparently through the RAN.

[0035] One or more UPF11s are connected to an external data network (such as an IP network like the Internet) via an appropriate interface (such as an N6 reference point) for the communication of user data.

[0036] The AMF10-1 performs mobility management-related functions, maintains NAS signaling connections with each UE3, and manages UE registration. The AMF10-1 is also responsible for managing paging. The SMF10-2 provides session management functions (which form part of the MME function in LTE) and further combines several control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF10-2 also assigns IP addresses to each UE3.

[0037] The base station 5 of the communication system 1 may be configured to operate at least one cell 9 on an associated time-division duplex (TDD) carrier operating in an unpaired spectrum. It will be understood that the base station 5 may also operate at least one cell 9 on an associated frequency-division duplex (FDD) carrier operating in a paired spectrum.

[0038] Furthermore, base station 5 is configured to transmit control information and user data via multiple downlink (DL) physical channels, and UE3 is configured to receive them and transmit multiple physical signals. DL physical channels correspond to resource elements (REs) that carry information originating from higher layers, and DL physical signals correspond to REs used in the physical layer that do not carry information originating from higher layers.

[0039] 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 that shares the PDSCH's capacity on a time and frequency basis. The PDSCH can carry various data items, including, for example, user data, UE-specific upper-layer control messages mapped from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) to support several functions, including scheduling downlink transmissions on the PDSCH and uplink data transmissions on the physical uplink shared channel (PUSCH). The PBCH provides the Master Information Block (MIB) to the UE3. The PBCH also works in conjunction with the PDCCH to support time and frequency synchronization, which assists in cell acquisition, selection, and re-selection. UE3 can receive Synchronization Signal Blocks (SSBs), and UE3 can assume that the reception timings of the PBCH, primary synchronization signal (PSS), and secondary synchronization signal (SSS) are consecutive symbols, forming an SS / PBCH block. Base station 5 can transmit multiple synchronization signal (SS) blocks corresponding to different DL beams. The total number of SS blocks may be limited, for example, to a duration of 5 ms as an SS burst. The periodicity of SSB transmissions may be indicated to UE3 using any appropriate signaling (e.g., per serving cell using ssb-periodicityServingCell). The periodicity value of the SSB may be, for example, 20 ms or more. For initial cell selection, UE3 may be configured to assume that SS bursts occur with a periodicity of 2 frames.UE3 may also provide instructions on which SSBs to send within a 5ms duration (for example, using ssb-PositionsInBurst).

[0040] DL physical signals may include, for example, a reference signal (RS) and a synchronization signal (SS). The reference signal (sometimes known as a pilot signal) is a signal with a predetermined special waveform known to both the UE3 and the base station 5. The reference signal may include, for example, a cell-specific reference signal, a UE-specific reference signal (UE-RS), a downlink demodulation signal (DMRS), and a channel state information reference signal (CSI-RS).

[0041] Similarly, UE3 is configured to transmit control information and user data via several uplink (UL) physical channels corresponding to REs that carry information transmitted from higher layers, and UL physical signals used in the physical layer that correspond to REs that do not carry information transmitted from higher layers, and base station 5 is configured to receive them. Physical channels may include, for example, PUSCH, physical uplink control channel (PUCCH), and / or physical random-access channel (PRACH). UL physical signals may include, for example, demodulation reference signal (DMRS) for UL control / data signals, and / or sounding reference signal (SRS) used for UL channel measurement.

[0042] UE3 first establishes a radio resource control (RRC) connection with base station 5 via cell 9, and then registers with an appropriate core network node (e.g., AMF10-1, MME). UE3 is in a so-called RRC connected state, and the associated UE context is maintained by the network. When UE3 is in a so-called RRC idle state, or RRC inactive state, UE3 selects an appropriate cell to camp on so that the network (not necessarily at the cell level) can recognize UE3's approximate location.

[0043] As described above, in this example, base station 5 is a “distributed” base station 5 divided between one or more distributed units (DUs) 5b and central units (CUs) 5c, where the CUs 5c typically perform higher-level functions and communication with the next-generation core, and the DUs 5b perform lower-level functions and communication with neighboring UEs 3 (i.e., within the cell 9 operated by base station 5) via an air interface. The distributed base station 5 may include, for example, the following functional units that host the following functions: Central unit (CU) 5c: A logical node that controls the operation of one or more DU5b base stations and hosts the radio resource control (RRC) layer, Service Data Adaptation Protocol (SDAP) layer, and Packet Data Convergence Protocol (PDCP) layer of base station 5. CU5c terminates the appropriate interface (e.g., a so-called F1 interface) to which the DU5b base station will connect.

[0044] Distributed Unit (DU) 5b: A logical node that hosts the Radio Link Control (RLC) layer, Medium Access Control (MAC) layer, and Physical (PHY) layer of base station 5, and its operation is partially controlled by CU5c. One DU5b supports one or more cells 9. One cell 9 is supported by only one DU5b. The DU5b terminates the appropriate interface (e.g., F1 interface) to which it connects to CU5c.

[0045] CU-Control Plane (CU-CP): A logical node that hosts the control plane portion of the RRC and PDCP protocols for CU5c for base station 5. The CU-CP terminates with appropriate interfaces that connect to CU-UP (e.g., the so-called E1 interface) and appropriate interfaces that connect to DU5b (e.g., the F1-C (F1 control plane) interface).

[0046] CU-User Plane (CU-UP): A logical node that hosts the user plane portions of the PDCP and SDAP protocols for CU5c for base station 5. The CU-UP terminates the appropriate interface for connecting to CU-CP (e.g., the E1 interface) and the appropriate interface for connecting to DU5b (e.g., the F1-U (F1 user plane) interface).

[0047] <Framework> Referring to Figure 2, which shows a typical frame structure that can be used in communication system 1, the base station 5 and UE3 of communication system 1 communicate with each other using resources organized into frames with a time domain length of 10 ms. Each frame contains 10 subframes of equal size, each 1 ms long. Each subframe is divided into one or more slots, each containing 14 orthogonal frequency-division multiplexing (OFDM) symbols of equal length.

[0048] As shown in FIG. 2, the communication system 1 supports a plurality of different numerologies (subcarrier spacing (SCS), slot length, and thus OFDM symbol length). Specifically, each numerology is identified by a parameter μ, where μ = 0 represents 15 kHz (corresponding to LTE SCS). Currently, the SCS for other values of μ can actually be derived from μ = 0 by scaling up by a power of 2 (i.e., SCS = 15×2μ kHz). The relationship between the parameter μ and SCS (Δf) is as shown in Table 1.

[0049] Table 1 - Numerology

Table 1

[0050] <CU - DU Information Exchange> In the communication system 1, for example, in a setup procedure for configuring communication between DU5b and CU5c (such as the "F1 setup procedure"), various messages may be exchanged between CU5c and DU5b. The purpose of the setup procedure is to exchange application - level data required for DU5b and CU5c to operate correctly with each other (e.g., on the F1 interface). This procedure is an initial procedure triggered for control - plane communication (e.g., via the F1 - C interface) after the transport network layer (TNL) association becomes operational. Usually, this procedure uses non - UE - related signaling.

[0051] Among such procedures, DU5b may send a setup request message (such as an F1 setup request) to CU5c. If the setup request message is an F1 setup request, the setup request message may include, for example, the following information. DU serving cell list IE: Information regarding cells supported by the DU and related features (e.g., NR - U); DU system information IE.

[0052] It will be understood that differently named information elements serving similar purposes may be used.

[0053] Accordingly, CU5c typically sends an F1 setup response message to DU5b. The following information may be included in the F1 setup response message: List of cells to be activated: A list of cells that IE:CU5c requests DU5b to activate.

[0054] In addition to the messages described above, other messages (with relevant informational elements) may be used to update the configuration between CU5c and DU5b. For example, Public Land Mobile Network (PLMN) lists, serving cell information, GNB-DU configuration update, or GNB-CU configuration update messages may be used to exchange information between CU5c and DU5b.

[0055] For example, additional messaging may be used between CU5c and DU5b when establishing the UE context during the UE context setup procedure. The purpose of the UE context setup procedure is to establish the UE context, including the signaling radio bearer (SRB) and data radio bearer (DRB). This procedure uses UE-related signaling.

[0056] During this procedure, CU5c can send a UE context setup request message to DU5b (this message may include an RRC container used to carry additional information, for example, in RRC information IE). The following information may be included in the UE context setup request message: UE-CapabilityRAT-ContainerList:DU5b can take this information into consideration for UE-specific configurations; The DRX cycle IE:DU5b can use the value provided by CU5c; If RRC information IE;CU5c receives UEAssistanceInformation IE from UE3, UEAssistanceInformation IE may be included in RRC information IE. DU5b may take UE assistance information into consideration when configuring resources for UE3, if supported.

[0057] SRB setup target list; DRB setup target list.

[0058] In response, DU5b sends a UE context setup response message to CU5c. The following information may be included in the UE context setup response message. A list of DRBs (and SRBs) that were successfully established and those that were not. When DU5b reports a failure to establish a DRB or SRB, the relevant causal value should be accurate enough to allow CU5c to know the reason for the establishment failure. This could include the reason why a given feature is not supported by DU5b. As an octet string transparently included by CU5c within the RRC reconfiguration message sent to CellGroupConfig:UE3 As an octet string transparently included by CU5c within the RRC reconfiguration message sent to DRX Config:UE3.

[0059] Instead of the above message, an alternative message (containing relevant information elements) may be used to update the UE configuration between CU5c and DU5b.

[0060] For example, in order to further update the UE configuration (e.g., DRB / SRB) between CU5c and DU5b, a UE context modification request message (from CU5c to DU5b) or a UE context modification required message (from DU5b to CU5c) may be used for information exchange between CU5c and DU5b.

[0061] <System Information and SIB> It will be understood that transmissions in cell 9 of base station 5 may include one or more broadcast transmissions, one or more unicast transmissions for reception by UE3, and / or one or more multicast transmissions for reception by a group of UE3. System information (SI) transmitted within a cell may include "minimum SI" (MSI) and "other SI" (OSI). OSI may be broadcast on demand, for example, using a downlink shared channel (DL-SCH). OSI may be broadcast in response to a request from a UE3 that is in a radio resource control (RRC) idle or RRC inactive state. OSI may also be requested by a UE3 that is in an RRC connected state, for example, via one or more dedicated RRC transmissions.

[0062] The SI may include information to enable UE3 to complete cell selection (for example, to be configured to complete), information to enable UE3 to complete a cell re-selection procedure, or information to enable UE3 to receive one or more paging messages sent within a cell. The SI may be broadcast using a Master Information Block (MIB) and one or more System Information Blocks (SIBs).

[0063] The MSI comprises an MIB and a system information block 1 (SIB1). The MIB includes information used by the UE3 to receive SIB1, such as the subcarrier interval for SIB1. The MIB provides information corresponding to the Control Resource Set (CORESET) and the search space. SIB1 may be referred to as the “remaining MSI” (RMSI). SIB1 may be transmitted in a dedicated RRC message, and other SIBs (such as SIB2-SIB9) may be transmitted using one or more other appropriate RRC transmissions (such as another dedicated RRC message). The MIB and SIB1 can provide the UE3 with scheduling information instructions for receiving and decoding other SIBs such as SIB2-SIB9, and can provide information used by the UE3 to receive one or more paging messages. The OSI may comprise SIB2-SIB9 transmitted using the downlink shared channel (DL-SCH) in an SI message, for example. The mapping of SIB2-SIB9 to the corresponding SI messages may be provided to the UE3 by the base station 5. Details of MIB and SIB1-SIB9 are described, for example, in 3GPP TS 38.331 (Non-Patent Literature 1). SIB2 provides information on intra-frequency, inter-frequency, and inter-system cell reselection. SIB3 provides cell-specific information on intra-frequency cell reselection. SIB4 provides information on inter-frequency cell reselection. SIB5 provides information on inter-system cell reselection for 4G (LTE). SIB6 and SIB7 provide information on earthquake and tsunami warning systems (ETWS). SIB8 provides information on commercial mobile alert service (CMAS) notifications, for example, to provide warning messages to UE3. SIB9 includes information on coordinated universal time (UTC), global positioning system (GPS) time (for example, for GPS initial setup), and local time.

[0064] SIBs may be broadcast periodically (for example, according to a predetermined periodic pattern), or alternatively, they may be provided "on demand" in response to requests from, for example, UE3. For example, MIBs may be transmitted using a periodicity of 80ms and repetitions occurring within 80ms, while SIB1 may be transmitted using a periodicity of 15cm ms and a variable transmission repetition periodicity (for example, 20ms) within 15cm ms. SIB1 may be used to indicate to UE3 which SIBs are transmitted periodically and which SIBs are available on demand in response to requests from UE3. UE3 may be configured to request on-demand SIBs using message 1 (MSG1), which may be called an MSG1-based on-demand SI request, or message 3 (MSG3), which may be called an MSG3-based on-demand SI request.

[0065] A physical broadcast channel (PBCH) may be used to broadcast the MIB. Base station 5 can transmit the PBCH in an SS / PBCH block along with synchronization signals (SS) (e.g., primary synchronization signal (PSS) and secondary synchronization signal (SSS)). An SS / PBCH block comprises four orthogonal frequency-division multiplexed (OFDM) symbols mapped to PSS, SSS, and PBCH associated with a demodulation reference signal (DM-RS). In the frequency domain, an SS / PBCH block contains 240 consecutive subcarriers. When UE3 is in an RRC connection state, base station 5 can provide UE3 with instructions for the resources to be used for the SS / PBCH, for example, using dedicated signaling. SIB1 may be transmitted using a physical downlink shared channel (PDSCH). OSI may similarly be transmitted using a PDSCH, for example. If one or more beamformed transmissions are transmitted in a cell provided by base station 5, only some of the SIs (such as some SIBs) may be transmitted using specific beams or using specific transmission / reception points (TRPs).

[0066] <Artificial Intelligence(AI) / Machine Learning(ML)> Base station 5 and UE3 are configured to utilize AI / ML to enhance their respective interfaces with features that enable improved support for AI / ML-based algorithms for performance enhancement and / or reduced complexity / overhead. Enhanced performance may include, for example, improved throughput, robustness, accuracy, or reliability.

[0067] Here, a general explanation of how AI / ML can be implemented in communication system 1 is provided as a mere example, with reference to Figures 3 to 5.

[0068] Figure 3 shows a functional framework for AI / ML models that can be implemented in communication system 1, and how the various entities of the framework can interact with each other.

[0069] The entity includes a data collection function 41, a model training function 43, a model inference function 45, an actor 47, a management function 49, and a model storage entity 51.

[0070] The model storage entity 51 may be a reference point for the protocol termination of the model transfer and distribution. The AI / ML model may be stored on any suitable node in the network.

[0071] The data collection function 41 provides training data to the model training function 43, inference data to the model inference function 45, and monitoring data to the management function 49. The data collected may be, for example, mobility data (such as UE3 handover or UE3 location). The data may be acquired, for example, by UE3 or base station 5 (for example, by receiving measurement reports from UE3, or by receiving data from another base station 5 or core network node / function) and transmitted to another base station 5 or core network node that generates the AI / ML model inference output (or alternatively, the same base station 5 that acquires the data may generate the AI / ML model output).

[0072] The model training function 43 can perform training, validation, and testing of ML models and generate model performance metrics as part of the model testing procedure. The model training function 43 may output the trained AI / ML model to the model storage entity 51 (however, it is understood that the output model may be stored in a location other than the model storage entity 51).

[0073] The model inference function 45 provides an AI / ML model inference output (e.g., prediction or decision), and the actor 47 is a function or node that receives the output from the model inference function 45 and triggers or performs a corresponding action (e.g., base station 5 increasing / decreasing its transmit power or initiating a handover procedure for UE3). The AI / ML model inference output may be, for example, a prediction of UE3 mobility (such as expected path, route or trajectory, inter-cell or inter-beam mobility, or expected handover), or one or more parameters for use when encoding or decoding transmissions between base station 5 and UE3. The model inference function 45 may receive AI / ML models from the model storage entity 51 and inference data from the data acquisition function 41 for use with the AI / ML models. The model inference function 45 may also output monitoring data for use in the management function 49 and may receive information from the management function 49 indicating which AI / ML should be activated or deactivated.

[0074] The management function 49 receives monitoring data from the data collection function 41, but may also receive monitoring data from the model inference function 45. The management function 49 may send instructions for the AI / ML model to be used by the model inference function 45 to the model storage entity 51. The management function 49 may also send requests for retraining the AI / ML model or performance feedback to the model training function 43.

[0075] The functions shown in Figure 3 can be located in the same place on a single node of the communication system 1 (for example, on a base station 5 or core network node / function), or they can be distributed across multiple network nodes (for example, multiple base stations 5).

[0076] In the context of this framework, the terms referenced by 3GPP include the following: AI / ML model training: The process of training an AI / ML model using a data-driven method [by learning input / output relationships] and obtaining a trained AI / ML model for inference. Model training can be performed offline, online, or a combination of both.

[0077] AI / ML model validation is a training subprocess that evaluates the quality of an AI / ML model using a different dataset than the one used for training. It helps in selecting model parameters that generalize beyond the dataset used for training.

[0078] AI / ML Model Testing: A training subprocess to evaluate the performance of a final AI / ML model using a different dataset than the one used for training and validation. Unlike AI / ML Model Validation, testing does not anticipate any further tuning of the model.

[0079] AI / ML model inference: The process of using a trained AI / ML model to generate a set of outputs based on a set of inputs.

[0080] Data collection: The process of collecting data by network nodes, management entities, or UE3 for the purpose of training AI / ML models, data analysis, and inference.

[0081] Model monitoring: A procedure for monitoring the inference performance of AI / ML models.

[0082] Model activation: Enables the AI / ML model for a specific function.

[0083] Model deactivation: Disable the AI / ML model for specific functions.

[0084] Model Switching: Deactivates the currently active AI / ML model and activates a different AI / ML model for a specific function.

[0085] Supervised learning: The process of training a model from inputs and their corresponding labels.

[0086] Unsupervised learning: The process of training a model without labeled data.

[0087] Semi-supervised learning: A process of training a model using a mixture of labeled and unlabeled data.

[0088] Reinforcement Learning (RL): The process of training an AI / ML model using inputs (also called "states") and feedback signals (also called "rewards") resulting from the model's outputs (also called "actions") in the environment in which the model interacts.

[0089] Data collection may be performed at various nodes of the communication system 1 (for example, at one or more base stations 5 or UE3). A particularly advantageous method for acquiring AI / ML model data at UE3 and transmitting the AI / ML data from UE3 to base station 5 will be described in more detail later.

[0090] Figure 4 schematically illustrates how to train an AI / ML model and monitor its performance. As shown in Figure 4, stored data / features may first be extracted in the data extraction step. In the data validation step, a decision is made (for example, based on the extracted data) whether to proceed with training or retaining the AI / ML model. In the data preparation phase, the data is prepared for use in training the AI / ML model. For example, the data may be cleaned (e.g., filtered), transformed, or modified in any other appropriate way. The data may also be split into training data, validation data, and test datasets in the data preparation phase.

[0091] In the model training step, the AI / ML model is trained (or retrained) using the training data prepared in the data preparation step. It will be understood that the AI / ML model can be trained using any suitable training method (for example, a method including supervised or unsupervised learning). In the model evaluation step, the AI / ML model is evaluated using a test dataset (which may be generated in the data preparation step) (for example, the predictive accuracy of the AI / ML model is evaluated). In the model validation step, a determination is made (for example, based on the results of the model evaluation step) whether the AI / ML model is suitable for deployment in communication system 1.

[0092] In the model provision step, the AI / ML model is deployed for use in communication system 1. Deployment of the AI / ML model may include compiling the trained AI / ML model, packaging the model into an executable format, and delivering the AI / ML model to the target device. For example, the AI / ML model may be sent to base station 5 and / or UE3 for use in base station 5 and / or UE3 to generate predictions or decisions using the AI / ML model as part of the prediction service step, as shown in the figure. In the performance monitoring step, the performance of the deployed AI / ML model is monitored. The prediction performance of the AI / ML model may be monitored by comparing predictions generated using the model with one or more measured values. For example, when the AI / ML model is used to predict the location of UE3, the prediction accuracy of the AI / ML model may be evaluated using measured values ​​of the actual location of UE3. Alternatively, if the AI / ML model is used to determine parameters used when encoding and decoding data transmitted between base station 5 and UE3, the model may be evaluated based on the performance of the encoding and / or decoding processes. In the retraining trigger step, the AI / ML model is retrained (for example, because the prediction accuracy of the AI / ML model falls below an acceptable threshold accuracy, or because the performance of the method using inference from the AI / ML model falls below an acceptable threshold performance), and the method returns to the data extraction step.

[0093] As described above with reference to Figure 3, each step of the method in Figure 4 may be performed on a single node of communication system 1, or alternatively, the steps of the method may be distributed across multiple different nodes (or, in practice, one or more of these steps may be performed online or offline).

[0094] As described above with reference to Figures 3 and 4, the information collected by nodes / functions within the communication system 1 (for example, in UE3) can be used as training data for an AI / ML model and as inference data for use when generating one or more model inferences using the AI / ML model. The information used as training data, monitoring data, and / or for generating one or more model inferences may be referred to as "AI / ML information" or "AI / ML data".

[0095] Here, we refer to Figure 5, which illustrates the relationships between AI / ML features, functions, and models that may be used in communication system 1.

[0096] Typically, AI / ML features such as "Feature 1" and "Feature 2" shown in Figure 5 are generally considered to be AI / ML use cases (e.g., CSI compression-reconstruction, spatial beam prediction, etc.).

[0097] A single AI / ML feature may contain multiple (different) functions (as shown in the diagram, "Feature 1" has two "functions"), and each function may refer to one configuration of the associated AI / ML feature. For example, in the case of spatial beam prediction (AI / ML feature), different functions can be defined regarding the number of beams predicted by the AI / ML model. Thus, a function is defined by the configuration of inputs, outputs, and other applicable conditions (such as UE vendors and deployment scenarios) associated with a given AI / ML feature.

[0098] AI / ML models (or multiple models) can provide a finer granularity than AI / ML functions, but any such AI / ML model may be defined without referring to a function (i.e., each AI / ML feature may have multiple AI / ML models without a function definition). AI / ML models are associated with configurations related to AI / ML features (similar to the above definition of AI / ML functions) and may further include additional detailed aspects such as model versions. Thus, if one or more AI / ML functions are defined, each function can be associated with multiple AI / ML models. As shown in Figure 5, a given function may be associated individually with function-specific models. A given function may, alternatively or additionally, be associated with a shared model along with one or more other functions.

[0099] Beneficially, as will be described in more detail below, communication system 1 implements a general model management framework that advantageously provides effective coordination between network nodes such as CU5c and DU5b to achieve AI / ML LCM operation. This is beneficial because, given that AI / ML applications are physical layer based, the active involvement of DU5b may be required in the context of a distributed base station 5. Similarly, the involvement of CU5c may be required, for example, in the context of dealing with radio resource control protocols. The framework conveniently enables variations in AI / ML model management, including the use of the one-sided and two-sided models described above, as well as alternative reporting mechanisms (such as RRC-based, L1 / L2-based, etc.).

[0100] Model monitoring and management decisions can be CU-based or DU-based. Advantageously, the present disclosure provides improved apparatuses and methods for model monitoring, including improved coordination between CU5c and DU5b. These methods are discussed in more detail below. An improved method for processing model monitoring reports by a network is also disclosed. In the following examples, it will be understood that the set of information exchanged between CU5c and DU5b can be provided via existing CU-DU messages (such as, for example, UE context set-up requests and / or F1 set-up requests), or can be provided using newly defined message(s). These procedures can be implemented together within the same system, but it will also be understood that any of these procedures can be implemented independently to provide corresponding benefits.

[0101] <Model Monitoring> AI / ML model performance monitoring may be initiated by CU5c or DU5b to enable evaluation of the performance of AI / ML operations. Decisions based on the performance evaluation can be used, for example, for switching, fallback, or deactivation of AI / ML features, functions, or models.

[0102] Monitoring of the AI / ML model can be CU-based or DU-based. In the case of a two-sided model, some of the information required for AI / ML model monitoring may be available at UE3, and the remaining information may be available at DU5b. For example, AI / ML inputs and ground truth measurements are available at UE3, inference outputs are available at DU5b, and the node performing the AI / ML monitoring may need both parts of this information to evaluate the AI / ML function or model performance.

[0103] <CU-Based Model Monitoring> FIG. 6 shows an example of a CU-based model monitoring method. In this example, CU5c is an entity that collects (receives) reports associated with an AI / ML model and evaluates whether an action needs to be taken using the reports.

[0104] In step S601, CU5c sends an instruction to DU5b indicating its intention to start model monitoring. The model monitoring request may be included, for example, in a UE context modification request. The transmission in step S601 includes an instruction for the AI / ML feature, function, or model in which monitoring will be initiated.

[0105] CU5c can also send instructions for model monitoring parameters to DU5b. For example, CU5c may also send instructions to DU5b regarding the DU5b reporting periodicity and the information that should be included in the reports. Instructions for model monitoring parameters can be sent from CU5c to DU5b using a dedicated message, or alternatively, from CU5c to DU5b in a transmission that is part of an AI / ML model activation method.

[0106] Examples of information elements (IE) that may be sent to DU5b by CU5c in step S601 include (but are not limited to) the following: Selected AI / ML features: A list of AI / ML features requested for monitoring. The following IEs may be included: AI / ML Feature ID and / or AI / ML Feature Name Selected AI / ML functions: A list of AI / ML functions requested for monitoring.

[0107] Information indicating the selected AI / ML function may include the AI / ML function ID, the relevant cell, and / or DU reporting parameters (using the appropriate IE). The applicable cell is a list of cells 9 on which the function can be activated, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. The DU reporting parameters may include reporting periodicity and / or reporting content. Reporting content can be indicated using an IE that shows a list of parameters to report. Parameters may be defined specifically for each AI / ML application. Alternatively, DU reporting parameters may be provided per AI / ML function or per UE3, in which case they may be common to a group of AI / ML features and models.

[0108] The information transmitted by CU5c to DU5b in step S601 may optionally include instructions for the selected AI / ML models. These instructions may include a list of AI / ML models requested for monitoring and may be provided for each selected AI / ML function entry.

[0109] Each entry can include the following IE entries: AI / ML Model ID Applicable Cells: A list of cells 9 into which this model can be activated, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b.

[0110] DU Reporting Parameters: Reporting periodicity and / or reporting content. Reporting content can be indicated using an IE that shows a list of parameters to report. Parameters may be defined specifically for each AI / ML application.

[0111] In step S602, DU5b provides an acknowledgment (ACK) or a denial (or rejection) (NACK) for the request received in step S601. DU5b may, in step S602, send an updated RRC configuration for AI / ML operation and / or wireless operation to CU5c (for use by CU5c when sending the RRC model monitoring configuration to UE3 in step S603), as DU5b may need to change the AI / ML operation configuration for model monitoring (for example, if model monitoring requires a different L1 / L2 reporting format).

[0112] DU5b can also provide instructions for other parameters related to the model monitoring configuration that may be used by CU5c, such as UE reporting periodicity, updated DU reporting periodicity, and / or reporting content.

[0113] In step S602, the following IE may be sent from DU5b to CU5c. Successful Monitoring AI / ML Features: A list of AI / ML features activated for monitoring. Each entry may include the following IEs: AI / ML Feature ID and / or AI / ML Feature Name Successful Monitoring AI / ML Functions: A list of AI / ML functions activated for monitoring. Each entry may include the following IEs: AI / ML feature ID Applicable Cells: A list of cells 9 that this feature monitors, where each entry contains a cell ID value that maps to a cell 9 supported by DU5b. DU Reporting Parameters: These are DU reporting parameters updated by DU5b, and may include reporting periodicity and / or reporting content (IE, which indicates a list of parameters to report; parameters may be defined specifically for each AI / ML application, or alternatively, DU reporting parameters may be provided for each AI / ML feature or per UE3, in which case they may be common to groups of AI / ML features and models). Successful Monitoring AI / ML Models: A list of AI / ML models activated for monitoring (which may be provided for each successful monitoring AI / ML feature entry). For each entry, the following IEs may be included: AI / ML Model ID Applicable Cells: A list of cells 9 that this model monitors, where each entry contains a cell ID value that maps to a cell 9 supported by DU5b. DU Reporting Parameters: These are the DU reporting parameters that DU5b updates, and may include reporting periodicity and / or reporting content (IE, which shows a list of parameters to report; parameters may be defined for each AI / ML application). Monitoring Failure AI / ML Features: A list of AI / ML features that cannot be monitored. Each entry may include the following IEs: AI / ML Feature ID and / or AI / ML Feature Name Monitoring Failure AI / ML Functions: A list of AI / ML functions that could not perform monitoring. Each entry may include the following IEs: AI / ML feature ID Applicable Cells: A list of cells 9 that cannot monitor this function, each entry containing a cell ID value that maps to a cell supported by DU5b. Failure cause: Monitoring failure cause Monitoring Failure AI / ML Models: A list of AI / ML models that cannot perform monitoring (may be provided for each Monitoring Failure AI / ML feature entry). For each entry, the following IEs may be included: AI / ML Model ID Applicable Cells: A list of cells 9 that this model cannot monitor, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. Failure cause: Monitoring failure cause RRC Information: IE containing RRC configuration information to be transferred to UE3 by CU5c (in step S603).

[0114] Based on the information received from DU5b in step S602, CU5c can advantageously construct an RRC configuration message which will be sent to UE3 in step S603 (where CU5c sends the RRC model monitoring configuration to UE3).

[0115] In step S604, UE3 generates a UE L1 / L2 report (including, for example, inference results) and sends the report to DU5b. In step S605, DU5b forwards the report to CU5c (as a DU performance monitoring report sent to CU5c).

[0116] The IEs included in the reports of steps S604 and S605 may include monitoring results IEs that include the UE ID, cell ID, and measurement results. The measurement results may include an aggregated list of monitoring results for a single UE3, where each entry includes a resource ID and values ​​for each of a set of parameters (e.g., Param1 value, Param2 value, Param3 value, ...). The parameters may be measurement or inference results (obtained by UE3 and / or DU5b) for different metrics specific to each AI / ML application. The UE ID and cell ID are the identities of the UE3 and cell 9 to which the measurement is associated. The UE ID may be in the form of a gNB-CU UE F1AP ID and / or a gNB-DU UE F1AP ID (e.g., as described in 3GPP specification TS 38.473 (Non-Patent Literature 3)). The cell ID may be in the form of a SpCell ID and / or ServCellIndex. The resource ID is a resource identifier corresponding to the measurement, e.g., a timestamp or an index associated with the measurement instance.

[0117] The periodicity of the transmissions in steps S604 and S605 may be determined by DU5b or CU5c. DU5b may provide CU5c with instructions for a periodicity value to report. Alternatively, CU5c may provide DU5b with instructions for a periodicity value to report, and DU5b may approve or reject the periodicity value. In a further alternative, the periodicity for reporting may be determined based on the UE RRC reporting interval to CU5c or the UE L1 / L2 reporting to DU5b.

[0118] The information included in the report ("Report Information") may include inference results and other measurements available in DU5b that can be used for AI / ML monitoring in CU5c.

[0119] In step S606, UE3 sends a UE RRC report for performance monitoring to CU5c. The UE RRC report for performance monitoring may include measurement results of measurements performed in UE3.

[0120] The IE included in the UE RRC report sent by UE3 to CU5c in step S606 may include a monitoring report IE containing a list of monitoring results, each entry containing: Measurement Result - an aggregated list of monitoring results for a single UE3, each entry containing a measurement ID and values ​​for each of a set of parameters (e.g., Param1 value, Param2 value, Param3 value, ...). The parameters may be measurements of different metrics specific to each AI / ML application. The measurement ID is a resource identifier corresponding to the execution of the measurement, e.g., a timestamp or index associated with the measurement instance.

[0121] CU5c combines the report received from DU5b in step 605 with the UE RRC report received in step S606 and performs a performance evaluation in step S607. The report from DU5b received in step S605 may include an identifier that enables CU5c to identify the DU report associated with the corresponding UE RRC report. The identifier may be in the form of an indication of the radio resource associated with the report in step S606. For example, in step S606, UE3 may provide information indicating the radio resource (e.g., cell or time information) on which the measurement / estimation was performed. DU5b includes the same information in its transmission in step S605, enabling CU5c to associate the DU performance monitoring report received in step S605 with the UE RRC report received in step S606. Alternatively, the identifier may be in the form of an index value. UE3 may include the index value in the UE RRC report sent in step S606, and may also include the same index value in the L1 / L2 reports sent to CU5c via DU5b in steps S604 and S605. Thus, CU5c can associate the L1 / L2 reports received from UE3 via DU5b with the UE RRC reports received in step S606 in order to perform monitoring.

[0122] The performance evaluation may be performed on CU5c in step S607, as shown in Figure 6, or alternatively, CU5c may forward the reports received in steps S605 and S606 to another node in the network so that the performance evaluation may be performed on another node.

[0123] After a performance evaluation is performed (for example, in CU5c), a model management decision is made. The model management decision may be made by either CU5c or DU5b based on an activation, deactivation, switching, or fallback mechanism. If the model management decision is made by DU5b, CU5c provides DU5b with instructions on the performance evaluation results (from step S607). In a first alternative, CU5c provides DU5b with instructions on whether the AI / ML algorithm is functioning well enough or performing poorly (e.g., not meeting a given performance metric). This information may be provided per AI / ML feature / function or model. In a second alternative, CU5c may provide DU5b with recommendations for a model management decision (e.g., deactivation, switching, or fallback). Recommended actions may be provided per AI / ML feature / function or model. This may also include recommended AI / ML features / functions or models in the case of model switching. The performance evaluation results (in the case of the first alternative form) or the proposed model management decision (in the case of the second alternative form) are transmitted from CU5c to DU5b in step S608. The information may also be transmitted to DU5b in a UE context modification request (however, any other appropriate transmission may be used instead).

[0124] The information sent to DU5b in step S608 may be referred to as a monitoring and evaluation report (or sent as a monitoring and evaluation report IE). The monitoring and evaluation report IE may include a list of evaluation results, each entry including: AI / ML Feature ID and / or AI / ML Feature Name AI / ML Functions: A list of AI / ML functions supported by the evaluation report. Each entry may include the following IEs. AI / ML feature ID Applicable Cells: A list of cells 9 to which this evaluation report applies, which may be provided per AI / ML feature or per UE3, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. Performance scores that can be provided for each AI / ML feature or for each UE3 (e.g., Param1 value, Param2 value, …) Recommended actions that can be provided for each AI / ML feature or for each UE3 (e.g., activation, deactivation, switching, or fallback) - If the recommended action is "switching", an optional switching AI / ML function ID can be provided AI / ML model: A list of AI / ML models corresponding to the evaluation reports that can be provided for each selected AI / ML function entry. For each entry, the following IEs can be included AI / ML model ID Applicable cells: A list of cells 9 for which this evaluation report is applicable, and each entry includes a cell ID value that maps to a cell 9 supported by DU5b (e.g., Param1 value, Param2 value, …) Performance scores (e.g., activation, deactivation, switching, or fallback) Recommended actions - If the recommended action is "switching", an optional switching AI / ML function ID can be provided (e.g., Param1 value, Param2 value, …) Performance score parameters indicate performance metric values of the AI / ML application, which may or may not be specific to the AI / ML application. For example, the performance metric may include the prediction accuracy of the AI / ML model or function, or may include the performance metric reported to CU5c in the UE / DU report for the AI / ML application

[0125] <DU-based model monitoring> Figure 7 shows an example of a DU-based model monitoring method. In this example, DU5b is an entity that collects (receives) reports associated with the AI / ML model and uses the reports to evaluate whether an action needs to be taken. However, CU5c is involved in the overall monitoring method, for example, for RRC report configuration and collection

[0126] In step S701, DU5b sends an instruction to CU5c indicating the intention to start model monitoring. The model monitoring request may be included, for example, in a UE context modification request message. The transmission in step S601 includes an instruction for the AI / ML feature, function, or model for which monitoring will be initiated. DU5b may also send information to CU5c indicating the intended model monitoring parameters, such as L3-based UE reporting periodicity and informational content for reporting, as well as the expected CU reporting configuration (e.g., periodicity and content).

[0127] Since DU5b may need to change the AI / ML operation configuration for model monitoring (for example, model monitoring may require a different L1 / L2 reporting format), DU5b may, in step S701, send CU5c an updated RRC configuration for AI / ML operation and / or wireless operation (for use by CU5c when sending the RRC model monitoring configuration to UE3 in step S702). Based on the information received from DU5b in step S701, CU5c can advantageously construct an RRC configuration message which will be sent to UE3 in step S702 (where CU5c sends the RRC model monitoring configuration to UE3).

[0128] DU5b may include the following IE in the monitoring request message in step S701. Monitoring Request AI / ML Features: A list of AI / ML features intended for monitoring - each entry may include the following IEs. AI / ML Feature ID / AI / ML Feature Name Monitoring Request AI / ML Functions: A list of AI / ML functions for monitoring. Each entry can include the following IEs. AI / ML feature ID Applicable Cells: A list of cells 9 that this feature monitors, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. DU reporting parameters: These are DU reporting parameters updated by DU5b and may include the following: reporting periodicity Report content (e.g., Param1, Param2, ...): This is an IE showing a list of parameters to report, and the parameters are defined specifically for each AI / ML application. Monitoring Request AI / ML Models: A list of AI / ML models to be monitored (this information can be provided for each monitoring request AI / ML function entry or each monitoring request AI / ML feature entry) - Each entry may include the following IE: AI / ML Model ID Applicable Cells: A list of cells 9 that this model monitors, where each entry contains a cell ID value that maps to a cell 9 supported by DU5b. DU reporting parameters: These are DU reporting parameters updated by DU5b and may include the following: reporting periodicity Report content (e.g., Param1, Param2, ...): This is an IE showing a list of parameters to report, and the parameters are defined specifically for each AI / ML application. RRC Information: IE containing the RRC configuration that CU5c should transmit to UE3. Based on the information provided to CU5c in step S701, CU5c can advantageously construct an RRC configuration message (the RRC model monitoring configuration sent in step S702) to be sent to UE3 for model monitoring. CU5c may be configured to confirm reporting parameters, such as reporting periodicity, reporting content, or any other reporting parameters, with DU5b.

[0129] CU5c may send confirmation of the monitoring parameters configured in CU5c to DU5b (the transmission is not shown in Figure 7, but may be sent at any appropriate time after CU5c receives a model monitoring request from DU5b). The confirmation of the monitoring parameters configured in CU5c sent to DU5b may include one or more of the following IEs: Successful Monitoring AI / ML Features: A list of AI / ML features activated for monitoring. Each entry may include the following IEs: AI / ML Feature ID and / or AI / ML Feature Name Successful Monitoring AI / ML Functions: A list of AI / ML functions activated for monitoring. Each entry may include the following IEs: AI / ML feature ID Applicable Cells: A list of cells 9 that this feature monitors, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. CU Reporting Parameters: CU reporting parameters updated by CU5c, which may include reporting periodicity and / or reporting content (IE: a list of parameters to report; parameters may be defined specifically for each AI / ML application, or alternatively, CU reporting parameters may be provided per AI / ML feature or per UE3, in which case they may be common to groups of AI / ML features and models). Successful Monitoring AI / ML Models: A list of AI / ML models activated for monitoring (which may be provided for each successful monitoring AI / ML feature entry). For each entry, the following IEs may be included: AI / ML Model ID Applicable Cells: A list of cells 9 that this model monitors, where each entry contains a cell ID value that maps to a cell 9 supported by DU5b. CU Reporting Parameters: CU reporting parameters updated by CU5c, which may include reporting periodicity and / or reporting content (IE indicating a list of parameters to report; parameters can be defined separately for each AI / ML application). Monitoring Failure AI / ML Features: A list of AI / ML features that cannot be monitored. Each entry may include the following IEs: AI / ML Feature ID and / or AI / ML Feature Name Monitoring Failure AI / ML Functions: A list of AI / ML functions that could not perform monitoring. Each entry may include the following IEs: AI / ML feature ID Applicable Cells: A list of cells 9 that cannot be monitored by this feature, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. Failure cause: Monitoring failure cause Monitoring Failure AI / ML Models: A list of AI / ML models that cannot perform monitoring (may be provided for each Monitoring Failure AI / ML feature entry). For each entry, the following IEs may be included: AI / ML Model ID Applicable Cells: A list of cells 9 that this model cannot monitor, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. Failure cause: Monitoring failure cause In step S703, UE3 uses the monitoring configuration received in step S702 to send a UE L1 / L2 report (including, for example, inference results) to DU5b.

[0130] In step S704, UE3 sends a UE RRC report for performance monitoring to CU5c, and in step S705, CU5c sends a corresponding CU performance monitoring report to DU5b (forwarding the UE RRC report). CU5c is configured to send the report from step S705 to DU5b periodically (e.g., at a predetermined or agreed periodicity). DU5b may send an instruction to CU5c in step S705 for use in sending reports from CU5c to DU5b. CU5c may acknowledge or reject the indicated periodicity. Alternatively, CU5c may provide an instruction for the periodicity to be used for reporting to DU5b. In further alternatives, the periodicity may be determined based on the UE RRC reporting interval to CU5c (e.g., CU5c sends one CU performance monitoring report to DU5b for each UE RRC report received by UE3 in CU5c) or the periodicity of UE L1 / L2 reports sent from UE3 to DU5b.

[0131] The report sent from CU5c to DU5b in step S705 includes information reported to CU5c by UE3 in step S704 (such as radio measurements performed by UE3 and / or AI / ML model / function inputs), and may also include additional measurements available in CU5c that can be used for AI / ML monitoring.

[0132] DU5b combines the report received from CU5c in step S705 with the UE L1 / L2 report received in step S703 and performs a performance evaluation in step S706. The report from CU5c received in step S705 may include an identifier that enables DU5b to identify the CU report associated with the corresponding UE L1 / L2 report. The identifier may be in the form of an indication of the radio resource associated with the report in step S703. For example, in step S703, UE3 may provide information indicating the radio resource (e.g., cell or time information) on which the measurement / estimation was performed. CU5c includes the same information in the transmission in step S705, enabling DU5b to associate the CU performance monitoring report received in step S705 with the UE L1 / L2 report received in step S703. Alternatively, the identifier may be in the form of an index value. UE3 may include an index value in the UE L1 / L2 report sent in step S703, and the same index value may be included in the CU performance monitoring report sent in step S705. Therefore, DU5b can associate the L1 / L2 report received from UE3 with the CU performance monitoring report received in step S705 in order to perform monitoring.

[0133] In step S705, the IE included in the transmitted CU performance monitoring report includes a monitoring result IE which is a list of monitoring results for different UE3s, and each entry is UE ID Cell ID Measurement Results: An aggregated list of monitoring results for a single UE3 instance, with each entry including the following: Resource ID UE Measurement Container Param1 value, Param2 value, Param3 value, ... The "Resource ID" is a resource identifier (e.g., a timestamp or an index associated with the measurement instance) corresponding to where the measurement was performed. The Param1, Param2, and Param3 values ​​are measurement / inference results (obtained by UE3 and / or CU5c) for different metrics specific to each AI / ML application. The "UE Measurement Container" is an RRC container received from UE3 in an RRC message, which should be transparently forwarded by CU5c to DU5b. The container contains measurement / inference results obtained by UE3 and reported to CU5c via the AI / ML monitoring procedure. The UE ID and Cell ID are identifiers for UE3 and Cell 9 to which the measurement is associated, respectively. The UE ID may be the gNB-CU UE F1AP ID and / or the gNB-DU UE F1AP ID. The Cell ID may be the SpCell ID and / or ServCellIndex.

[0134] The IE included in the UE RRC report sent by UE3 to CU5c in step S704 may include a monitoring report IE containing a list of monitoring results, each entry containing: Measurement Result - an aggregated list of monitoring results for a single UE3, each entry containing a measurement ID and a value for each of a set of parameters (e.g., Param1 value, Param2 value, Param3 value, ...). The parameters may be measurements of different metrics specific to each AI / ML application. The measurement ID is a resource identifier corresponding to the execution of the measurement, e.g., a timestamp or index associated with the measurement instance.

[0135] The performance evaluation may be performed on DU5b in step S706 (as shown in Figure 7), or alternatively, DU5b may forward the measurements to another node in the network where the evaluation is performed (e.g., an external entity).

[0136] Following the performance evaluation in step S706, a model control decision is made. The model control decision may be made in either CU5c or DU5b based on activation, deactivation, switching, or fallback mechanisms.

[0137] When the model management decision should be made by CU5c, DU5b provides CU5c with instructions regarding the performance evaluation results (from step S706). In the first alternative, DU5b provides CU5c with instructions regarding whether the AI / ML algorithm is functioning well enough or performing poorly (e.g., not meeting a given performance metric). This information may be provided per AI / ML feature / function / model. In the second alternative, DU5b may provide CU5c with recommendations for a model management decision (e.g., deactivation, switching, or fallback). This instruction may be provided per AI / ML feature / function / model. This may also include recommended AI / ML features / functions or models in the case of model switching. In the optional step S707, the performance evaluation results (in the first alternative) or the proposed model management decision (in the second alternative) are sent from DU5b to CU5c. This information may be sent to DU5b in a UE context modification request (although any other appropriate transmission may be used instead).

[0138] The information sent to CU5c in step S707 may be referred to as a monitoring and evaluation report (or sent as a monitoring and evaluation report IE). The monitoring and evaluation report IE may include a list of evaluation results, each entry including: AI / ML Feature ID and / or AI / ML Feature Name AI / ML Functions: A list of AI / ML functions supported by the evaluation report. Each entry may include the following IEs. AI / ML feature ID Applicable Cells: A list of cells 9 to which this evaluation report applies, which may be provided per AI / ML feature or per UE3, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. Performance scores (e.g., Param1 value, Param2 value, etc.) may be provided for each AI / ML feature or each UE3. Recommended actions may be provided for each AI / ML feature or UE3 (e.g., activate, deactivate, toggle, or fallback) - if the recommended action is "toggle", an optional toggle AI / ML feature ID may be provided. AI / ML Models: A list of AI / ML models to which the evaluation report corresponds, which may be provided for each selected AI / ML feature entry. For each entry, the following IEs may be included. AI / ML Model ID Applicable Cells: A list of cells 9 to which this assessment report is applicable, with each entry containing a cell ID value that maps to a cell 9 supported by DU5b. Performance scores (for example, Param1 value, Param2 value, etc.) Recommended action (e.g., activate, deactivate, toggle, or fallback) - If the recommended action is "toggle", an optional toggle AI / ML function ID may be provided. Performance score parameters (e.g., Param1 value, Param2 value, etc.) represent performance metrics for an AI / ML application, which may or may not be specific to the AI / ML application. For example, performance metrics may include the predictive accuracy of an AI / ML model or function, or performance metrics reported in the UE report for the AI / ML application.

[0139] <User Equipment> Figure 8 is a schematic block diagram showing the main components of UE3 as shown in Figure 1.

[0140] As shown in the figure, UE3 has a transceiver circuit 310 capable of operating to send and receive signals to and from base station 5 via one or more antennas 330 (e.g., having one or more antenna elements). UE3 has a controller 370 that controls the operation of UE3. The controller 370 is associated with memory 390 and coupled to the transceiver circuit 310. Although not necessarily required for its operation, UE3 may, of course, have all the usual functions of a conventional UE3 (e.g., a user interface 350 such as a touchscreen / keypad / microphone / speaker to enable direct user control and interaction with the user), which may be provided by any one or any combination of hardware, software, and firmware, as appropriate. The software may be pre-installed in memory 390 and / or downloaded, for example, via communication system 1 or from a removable data storage device (RMD).

[0141] In this example, the controller 370 is configured to control the overall operation of UE3 by program instructions or software instructions stored in memory 390. As shown in the figure, these software instructions also include the operating system 410, the communication control module 430, and the AI / ML module 450.

[0142] The communication control module 430 is operable to control communication between the UE 3 and one or more service base stations 5 (and other communication devices connected to base station 5, such as additional UEs and / or core network nodes). The communication control module 430 is configured to handle uplink communication in general via associated uplink channels (e.g., via physical uplink control channel (PUCCH), random access channel (RACH), and / or physical uplink shared channel (PUSCH)), including both dynamic and quasi-static signaling (e.g., such as SRS). The communication control module 430 is also configured to handle the reception of downlink communication in general via associated downlink channels (e.g., via physical downlink control channel (PDCCH) and / or physical downlink shared channel (PDSCH)), including both dynamic and quasi-static signaling (e.g., such as CSI-RS). The communication control module 430 is responsible for, for example, determining where to monitor downlink control information (such as the locations of CSS / USS, CORESET, and associated PDCCH candidates to be monitored), determining resources used by UE3 for transmitting / receiving UL / DL communications (including interleaved resources and resources subject to frequency hopping), managing frequency hopping on the UE3 side, determining how slots / symbols are configured (for example, for UL, DL, or SBFD communications), determining which one or more bandwidth portions are configured for UE3, determining how uplink transmissions should be encoded, and appropriately applying any SBFD-specific communication configurations. The communication control module 430 may be configured to control communications in any of the ways described above (for example, to transmit measurement reports in any of the ways described above).

[0143] The AI / ML module 450 is configured to execute any of the AI / ML-related functions of the UE3 in any of the methods described above.

[0144] <RAN (Distributed)> FIG. 9 is a simplified block diagram showing the main components of a distributed RAN including a distributed base station 5 for implementation in the system of FIG. 1.

[0145] As shown in the figure, the RAN includes a central unit 5c and a distributed unit 5b (however, other DUs may be included as described above). Each unit 5c, 5b includes respective transceiver circuits 51c, 51b.

[0146] The transceiver circuit 51b of the distributed unit 5b is operable to transmit and receive signals to and from the UE3 via the air interface 53b and one or more antennas, and is also operable to transmit and receive signals to and from the central unit 5c via an interface, for example, the distributed unit side of the F1 interface (which may be provided via a satellite radio interface).

[0147] The transceiver circuit 51c of the central unit 5c is operable to transmit and receive signals between the functions of the core network 7 and / or the functions of other RANs via the network interface 55c. The network interface typically includes N1, N2, and / or N3 interfaces for communicating with the core network 7 and an inter-base station (e.g., Xn) interface for communicating with other RANs. The transceiver circuit 51c of the central unit 5c is also operable to transmit and receive signals between one or more distributed units 5b, for example, the central unit side of the provided F1 interface.

[0148] Each unit 5c, 5b includes its respective controller 57c, 57b, which controls the operation of the corresponding transceiver circuits 51c, 51b according to the software stored in the respective memories 59c, 59b of the distributed unit 5b and the central unit 5c. The software for each unit may be pre-installed in the memories 59c, 59b and / or downloaded, for example, via the communication system 1 or from a removable data storage device (RMD). The software for each unit also includes its respective operating system 61c, 61b, its respective communication control module 63c, 63b, and its respective AI / ML module 65c, 65b.

[0149] Each communication control module 63c, 63b is operable to control the communication of the corresponding units 5c, 5b, including communication from one unit to the other. The communication control module 63b of the distributed unit 5b controls communication between the distributed unit 5b and the UE3, and the communication control module 63c of the central unit 5c controls communication between the central unit 5c and other network entities connected to the distributed RAN.

[0150] Communication control modules 63c and 63b also control, respectively, the parts of the flow of uplink and downlink user traffic and control data to be transmitted to communication devices serviced by the RAN, including, for example, control data for managing the operation of the UE3, that are performed by the distributed unit 5b and the central unit 5c. Each communication control module 63b and 63c is responsible for controlling the parts of the reception and decoding of uplink communications via associated uplink channels (e.g., via the Physical Uplink Control Channel (PUCCH), Random Access Channel (RACH), and / or Physical Uplink Shared Channel (PUSCH)), including both dynamic and quasi-static signaling (such as SRS), that are performed by the distributed unit 5b and the central unit 5c. Each communication control module 63c, 63b plays a role in controlling the portion of downlink communication transmission handled by the distributed unit 5b and the central unit 5c, respectively, via the associated downlink channel (e.g., via the physical downlink control channel (PDCCH) and / or the physical downlink shared channel (PDSCH)), which includes both dynamic and quasi-static signaling (e.g., CSI-RS, SSB, etc.).

[0151] It will be understood that the communication control modules 63c, 63b may also include several submodules (or "layers") to support specific functions of the corresponding units 5c, 5b. The included modules depend on how the corresponding units 5c, 5b are configured (e.g., the exact CU-DU partitioning). For example, the communication control module 63c of the distributed unit 5b may include a PHY submodule, a MAC submodule, and an RLC submodule, while the communication control module 63c of the central unit 5c may include a PDCP submodule, an SDAP submodule, an IP submodule, an RRC submodule, and so on.

[0152] The AI / ML modules 65c and 65b are configured to perform one of the AI / ML-related functions described above.

[0153] <Core network node / function> Figure 10 is a block diagram showing the main components of a core network 7 or function, such as AMF, CPF, UPF, SMF, or OAM. As shown in the figure, the core network function includes a transceiver circuit 710 that is capable of transmitting signals to and receiving signals from other nodes (including UE3, base station 5, and other core network nodes) via a network interface 720. The controller 730 controls the operation of the core network function according to software stored in memory 740. The software may be pre-installed in memory 740 and / or downloaded, for example, via communication system 1 or from a removable data storage device (RMD). The software also includes an operating system 750 and a communication control module 760.

[0154] The communication control module 760 is responsible for handling (generating / transmitting / receiving) signaling between the core network functions and other nodes such as UE3, base station 5, and other core network nodes.

[0155] As shown in Figure 10, the core network node / function may also include an AI / ML module 770. If present, the AI / ML module 770 is operable to perform any of the AI / ML-related functions of the core network node / function according to one of the methods described above. The core network node / function may be configured to train or retrain AI / ML models as described above (in response to AI / ML data fed back to the core network node / function from another node in the network, such as base station 5).

[0156] <Modified forms and alternative forms> As those skilled in the art will understand, several modifications and substitutions can be made to the above examples while still benefiting from the present invention.

[0157] While the above examples illustrate the concepts using AI / ML models, it will be understood that the methods described above are also advantageous when the model is not an AI / ML model. Any other suitable type of model or function can be used to generate inference (e.g., decision or prediction).

[0158] For example, while specific terms for cellular communication generations (such as 2G, 3G, 4G, 5G, and 6G) ​​may be used to refer to specific communication entities for clarity, it will be understood that the technical features described for a given entity are not limited to devices of that particular communication generation. Technical features can be implemented in any functionally equivalent communication entity, regardless of the differences in the terminology used to refer to them.

[0159] In the above description, the UE and base station are described as having several separate functional components or modules for ease of understanding. These modules may be provided in this way for a specific application, for example, when an existing system is modified to implement the disclosure, but for other applications, for example, a system designed from the outset with the features of the present invention in mind, these modules may be incorporated into the operating system or the entire code, and therefore these modules may not be recognized as separate entities.

[0160] The above examples described several software modules. As those skilled in the art will understand, software modules may be provided in compiled or uncompiled form and may be supplied as signals via a computer network or on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred because it facilitates updating the base station or UE to update its functions.

[0161] Each controller may include, but is not limited to, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuits, internal memory / cache (programs and / or data), processing registers, communication buses (such as control buses, data buses and / or address buses), direct memory access (DMA) functions, hardware or software-implemented counters, pointers and / or timers, and any other suitable form of processing circuitry. Various other modifications are obvious to those skilled in the art and will not be described in further detail here.

[0162] In this disclosure, User Equipment (or "UE," "Mobile Station," "Mobile Device," or "Radio Device") is an entity connected to a network via a radio interface.

[0163] Please note that this disclosure is not limited to dedicated communication devices, but can be applied to any device having communication functions as described in the following paragraphs.

[0164] The terms “User Equipment” or “UE” (as used by 3GPP), “Mobile Station,” “Mobile Device,” and “Radio Device” are generally intended to be synonymous with each other and include standalone mobile stations such as terminals, cell phones, smartphones, tablets, cellular IoT devices, IoT devices, and machines. The terms “Mobile Station” and “Mobile Device” will be understood to also include devices that remain stationary for extended periods.

[0165] UE may be items of equipment for production or manufacture and / or items of energy-related machinery, such as equipment or machinery (including boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal generators, nuclear generators, batteries, nuclear systems and / or related equipment, heavy electrical machinery, pumps including vacuum pumps, compressors, fans, blowers, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots and / or their application systems, tools, molds or dies, rolls, conveying equipment, elevators, material handling equipment, textile machinery, sewing machinery, printing and / or related machinery, paper conversion machinery, chemical machinery, mining machinery and / or construction machinery and / or related equipment, machinery and / or equipment for agriculture, forestry and / or fisheries, safety and / or environmental protection equipment, tractors, precision bearings, chains, gears, power transmission equipment, lubrication equipment, valves, pipe fittings and / or application systems for any of the aforementioned equipment or machinery, etc.).

[0166] UE may be an item of transport equipment (such as railcars, automobiles, motorcycles, bicycles, trains, buses, carts, rickshaws, ships and other vessels, aircraft, rockets, satellites, drones, balloons, etc.). UE may also be an item of information and communication equipment (such as electronic computers and related equipment, communication and related equipment, electronic components, etc.).

[0167] UE may include, for example, refrigerators, refrigerator applications, commercial and / or service industry equipment items, vending machines, automated service machines, office machinery or equipment, consumer electronics and electronic devices (e.g., consumer electrical appliances such as audio equipment; video equipment; speakers; radios; televisions; microwave ovens; rice cookers; coffee machines; dishwashers; washing machines; dryers; electronic fans or related appliances; vacuum cleaners, etc.).

[0168] UE may be an electrical application system or device, for example, (such as an electrical application system or device, like an X-ray system, particle accelerator, radioisotope device, sound wave device, electromagnetic application device, or power application device).

[0169] UE may include, for example, electronic lamps, lighting fixtures, measuring instruments, analyzers, testers, or detection or sensing devices (e.g., smoke detectors, human alarm sensors, motion sensors, wireless tags, etc.), watches or clocks, laboratory equipment, optical devices, medical devices and / or systems, weapons, bladed tools, or hand tools.

[0170] The UE may be, for example, a wireless-equipped portable information terminal or related device (such as a wireless card or module designed for attachment to or insertion into another electronic device, such as a personal computer or electrical measuring instrument).

[0171] UE may be part of a device or system that uses various wired and / or wireless communication technologies to provide the applications, services, and solutions described below in relation to the Internet of Things (IoT).

[0172] Internet of Things (IoT) devices (or "Things") may comprise appropriate electronics, software, sensors, network connectivity, etc., that enable them to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated devices that follow software instructions stored in internal memory. IoT devices may operate without requiring human monitoring or interaction with humans. IoT devices may also remain stationary and / or inactive for extended periods. IoT devices may be implemented as part of (generally) stationary equipment. IoT devices may also be embedded in non-stationary equipment (e.g., such as a vehicle) or attached to animals or people being monitored / tracked.

[0173] It will be understood that IoT technology can be implemented on any communication device that can connect to a communication network to send / receive data, regardless of whether such communication device is controlled by human input or software instructions stored in memory.

[0174] It should be understood that IoT devices are sometimes referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It should be understood that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in Table 1 below. This list is not exhaustive and is intended to illustrate some examples of machine-type communication applications.

[0175] Table 1 [Table 2]

[0176] Applications, services, and solutions may include MVNO (Mobile Virtual Network Operator) services, emergency radio communication systems, PBX (Private Branch eXchange) systems, PHS / digital cordless telecommunications systems, POS (Point of Sale) systems, incoming advertising systems, MBMS (Multimedia Broadcast and Multicast Service), V2X (Vehicle to Everything) systems, train radio systems, location-related services, disaster / emergency radio communication services, community services, video streaming services, femtocell application services, VoLTE (Voice over LTE) services, billing services, wireless on-demand services, roaming services, activity monitoring services, telecommunications carrier / communication network selection services, function restriction services, PoC (Proof of Concept) services, personal information management services, ad hoc network / DTN (Delay Tolerant Networking) services, and others.

[0177] Furthermore, the aforementioned UE categories are merely examples of applications of the technical concepts and exemplary embodiments described in this document. Of course, such technical concepts and examples are not limited to the UEs described above and can be modified in various ways.

[0178] Various other variations are obvious to those skilled in the art and will not be described in further detail here.

[0179] While the present disclosure has been described above with reference to embodiments, the present disclosure is not limited thereto. Various modifications to the structure and details of the present disclosure can be understood by those skilled in the art within the scope of the present disclosure.

[0180] This application claims priority based on UK Patent Application No. 2311261.8, filed on 21 July 2023, and incorporates all of its disclosures herein.

[0181] A program can be stored and provided to a computer device using any type of non-temporary computer-readable medium. Non-temporary computer-readable medium includes any type of tangible storage medium. Examples of non-temporary computer-readable medium include magnetic storage media (such as floppy disks, magnetic tapes, and hard disk drives), magneto-optical storage media (such as magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs, CD-R / Ws, and semiconductor memory (such as mask ROMs, PROMs (Programmable ROMs), EPROMs (Erasable PROMs), flash ROMs, and RAMs (Random Access Memory)). A program may also be provided to a computer device using any type of temporary computer-readable medium. Examples of temporary computer-readable medium include electrical signals, optical signals, and electromagnetic waves. Temporary computer-readable medium can be provided to a computer device via wired communication lines such as electric wires and optical fibers, or via wireless communication lines.

[0182] For example, all or part of the embodiments disclosed above may be described as follows, but are not limited to these. (Note 1) A method performed by a first unit of a distributed base station, the method is Sending a request to monitor an Artificial Intelligence (AI) / Machine Learning (ML) model, AI / ML function, or AI / ML feature to the second unit of a distributed base station, Receiving reporting information from the second unit, including at least one of the inference results of the AI / ML model in the second unit and measurements in the second unit that may be used for monitoring, The performance results based on the reported information will be sent to the second unit, Methods that include... (Note 2) The requirement includes first information that shows at least one AI / ML feature, each of which corresponds to at least one AI / ML model. The method described in Appendix 1. (Note 3) Receiving from the second unit a first message to acknowledge the request, or a second message to reject the request. It further includes, The second message includes a causal value indicating the reason for the failure. The method described in Appendix 1 or 2. (Note 4) The first message includes first information that indicates at least one AI / ML feature, each of which corresponds to at least one AI / ML model. The method described in Appendix 3. (Note 5) The first piece of information is, Second information showing at least one AI / ML function corresponding to at least one of the AI / ML features, Third piece of information indicating at least one AI / ML model corresponding to at least one AI / ML feature or at least one AI / ML function, Cell information indicating at least one cell corresponding to at least one AI / ML feature, at least one AI / ML function, or at least one AI / ML model, The periodicity used to transmit reporting information, or Information showing the content of the report. including at least one of the following: The method described in Appendix 2 or 4. (Note 6) The performance results include a performance score that shows the performance metric value of the AI / ML model, AI / ML function, or AI / ML feature. The method described in any one of the appendices 1 to 5. (Note 7) The performance results include recommended actions for monitoring the management of AI / ML models, AI / ML functions, or AI / ML features. The method described in Appendix 6. (Note 8) Performance results are provided for each cell to which the performance results are applicable. The method described in Appendix 7. (Note 9) The recommended action is, Activate at least one AI / ML model, AI / ML function, or AI / ML feature. Deactivate at least one AI / ML model, AI / ML function, or AI / ML feature. Switching between at least one AI / ML model, AI / ML function, or AI / ML feature, or At least one AI / ML model, AI / ML function, or AI / ML feature must be fallbacked. including at least one of the following: The method described in Appendix 7 or 8. (Note 10) To receive further reporting information, including inference results for AI / ML models in user equipment (UE), and at least one of the measurements in the UE unit that can be used for monitoring. It further includes, Performance results are based on further reported information. The method described in any one of the appendices 1 to 9. (Note 11) To receive further reports, From UE, or From the second unit, Including receiving from at least one of the following, The method described in Appendix 10. (Note 12) The first unit includes a distributed unit of a distributed base station, The second unit includes the central unit of the distributed base stations, The method described in any one of the appendices 1 to 11. (Note 13) The first unit includes the central unit of the distributed base station, The second unit includes a distributed unit of a distributed base station. The method described in any one of the appendices 1 to 11. (Note 14) The first unit of a distributed base station, A means for transmitting a request to monitor an Artificial Intelligence (AI) / Machine Learning (ML) model, AI / ML function, or AI / ML feature to a second unit of a distributed base station, Means for receiving reporting information from a second unit, including at least one of the inference results of an AI / ML model in the second unit and measurements in the second unit that can be used for monitoring, The second unit includes means for transmitting performance results based on the reported information, The first unit, equipped with [the specified feature]. [Explanation of symbols]

[0183] 1. Communication System 3 UE 5 Radio Access Network (RAN) nodes, base stations 5b Distributed Unit (DU) 5c central unit (CU) 7 Core Network 9 cells 10 control plane function (CPF) 10-1 Access and Mobility Management Function (AMF) 10-2 Session Management Function (SMF) 11. User-Plane Function (UPF) 41 Data Collection Function 43 Model Training Functions 45 Model Inference Functions 47 Actors 49 Management functions 51 Model Storage Entities 310, 51b, 51c, 710 Transceiver Circuit 330 Antenna 53b Air Interface 350 User Interfaces 55c,720 network interfaces 370, 57b, 57c, 730 Controller 390, 59b, 59c, 740 memory 410, 61b, 61c, 750 Operating Systems 430, 63b, 63c, 760 Communication Control Module 450, 65b, 65c, 770 AI / ML modules

Claims

1. A method performed by a first unit of a distributed base station, the method is The second unit of the distributed base station transmits a request to monitor an Artificial Intelligence (AI) / Machine Learning (ML) model, AI / ML function, or AI / ML feature. Receiving reporting information from the second unit, which includes at least one of the inference results of the AI / ML model in the second unit and measurements in the second unit that can be used for monitoring; The performance results based on the aforementioned report information are transmitted to the second unit, Methods that include...

2. The requirement includes first information indicating at least one AI / ML feature, each of which corresponds to at least one AI / ML model. The method according to claim 1.

3. Receiving from the second unit a first message to acknowledge the request, or a second message to reject the request. It further includes, The second message includes a cause value indicating the reason for the failure. The method according to claim 1 or 2.

4. The first message includes first information indicating at least one AI / ML feature, each of which corresponds to at least one AI / ML model. The method according to claim 3.

5. The first information described above is Second information indicating at least one AI / ML function corresponding to one of the at least one AI / ML feature, Third information indicating at least one AI / ML model corresponding to one of the at least one AI / ML features or at least one AI / ML function, Cell information indicating at least one cell corresponding to one of the at least one AI / ML features, at least one AI / ML function, or at least one AI / ML model, The periodicity used to transmit reporting information, or Information showing the contents of the aforementioned report information Including at least one of the following: The method according to claim 2 or 4.

6. The performance results include a performance score indicating the performance metric value of the AI / ML model, AI / ML function, or AI / ML feature. The method according to any one of claims 1 to 5.

7. The performance results include recommended actions for monitoring the management of the AI / ML model, AI / ML function, or AI / ML feature. The method according to claim 6.

8. The performance results are provided for each cell to which the performance results are applicable. The method according to claim 7.

9. The aforementioned recommended action is, Activate at least one AI / ML model, AI / ML function, or AI / ML feature. Deactivate at least one AI / ML model, AI / ML function, or AI / ML feature. Switching between at least one AI / ML model, AI / ML function, or AI / ML feature, or To fall back at least one AI / ML model, AI / ML function, or AI / ML feature. Including at least one of the following: The method according to claim 7 or 8.

10. To receive further reporting information including inference results for an AI / ML model in user equipment (UE) and at least one of the measurements in the UE unit that may be used for monitoring. It further includes, The performance results are based on the further reported information. The method according to any one of claims 1 to 9.

11. Receiving the aforementioned further reporting information means From the aforementioned UE, or From the aforementioned second unit, Including receiving from at least one of the following, The method according to claim 10.

12. The first unit includes the central unit of the distributed base station, The second unit includes the distributed units of the distributed base station, The method according to any one of claims 1 to 11.

13. The first unit includes the distributed units of the distributed base station, The second unit includes the central unit of the distributed base station, The method according to any one of claims 1 to 11.

14. The first unit of a distributed base station, The second unit of the distributed base station is provided with means for transmitting a request to monitor an Artificial Intelligence (AI) / Machine Learning (ML) model, an AI / ML function, or an AI / ML feature, Means for receiving reporting information from the second unit, including at least one of the inference results of the AI / ML model in the second unit and measurements in the second unit that can be used for monitoring, The second unit includes means for transmitting performance results based on the reported information, The first unit, which is equipped with [the following].