Reference model based model lifecycle management and performance testing for artificial intelligence and machine learning models

A reference model-based approach for AI/ML model lifecycle management and performance testing addresses the complexities of AI/ML model management in wireless communication networks, enhancing efficiency and consistency across different vendors.

WO2025071468A1PCT designated stage expired Publication Date: 2025-04-03TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
PCT/SE2024/050831
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-09-29
Filing Date
2024-09-30
Publication Date
2025-04-03

AI Technical Summary

Technical Problem

Current systems face challenges in efficiently managing the lifecycle of Artificial Intelligence (AI) and Machine Learning (ML) models, particularly in wireless communication networks, due to complexities in model training, deployment, and performance testing, especially in multi-vendor scenarios.

Method used

The proposed solution involves a reference model-based approach for model lifecycle management (LCM) and performance testing. This includes splitting AI/ML models into two parts, Part A and Part B, where Part A contains the model structure and Part B contains the parameters. Standardized reference models are used to reduce inter-vendor offline engineering efforts and facilitate consistent performance testing.

Benefits of technology

This approach reduces the complexity of AI/ML model management and testing, enabling more efficient model training and deployment across different vendors, while ensuring consistent performance and minimizing bilateral offline co-engineering efforts.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure SE2024050831_03042025_PF_FP_ABST
    Figure SE2024050831_03042025_PF_FP_ABST
Patent Text Reader

Abstract

A method (1400) performed by a first radio node (402, 502) for using a first part AI model includes receiving (1402) an indication from a second radio node. The indication indicates one or more selected reference model identifier(s), where the one or more selected reference model identifier(s) identify one or more first part AI model(s) that is / are associated with a feature. Alternatively, the indication indicates that no first part AI model is selected. The first radio node uses (1404) a first part AI model identified by the one of the one or more selected reference model identifier(s) indicated by the second radio node. Alternatively, the first radio node falls back to a non-AI algorithm if the indication from the second node indicates that no first part AI model is selected.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] REFERENCE MODEL BASED MODEL LIFECYCLE MANAGEMENT AND

[0002] PERFORMANCE TESTING FOR ARTIFICIAL INTELLIGENCE AND MACHINE

[0003] LEARNING MODELS

[0004] TECHNICAL FIELD

[0005] The present disclosure relates, in general, to wireless communications and, more particularly, systems and methods for reference model-based model Lifecycle Management and performance testing for Artificial Intelligence and Machine Learning Models.

[0006] BACKGROUND

[0007] Artificial Intelligence (Al) and Machine Learning (ML) have been investigated, both in academia and industry, as promising tools to optimize the design of the air-interface in wireless communication networks. Example use cases include using autoencoders for Channel State Information (CSI) compression to reduce the feedback overhead and improve channel prediction accuracy; using deep neural networks for classifying Line-of-Sight (LOS) and Non-LOS (NLOS) conditions to enhance the positioning accuracy; and using reinforcement learning (RL) for beam selection at the network side and / or the User Equipment (UE) side to reduce the signaling overhead and beam alignment latency; using deep reinforcement learning to learn an optimal precoding policy for complex Multiple Input Multiple Output (MIMO) precoding problems.

[0008] In 3rd Generation Partnership Project (3 GPP) New Radio (NR) standardization work, a new Release 18 study item on AI / ML for the NR air interface started in May 2022. This study item explores the benefits of augmenting the air-interface with features enabling improved support of AI / ML based algorithms for enhanced performance and / or reduced complexity / overhead. Through studying a few selected use cases (CSI feedback, beam management, and positioning), the study item aims at laying the foundation for future air-interface use cases leveraging AI / ML techniques.

[0009] Functional Framework for AI / ML Model LCM

[0010] Building the Al model, or any machine learning model, includes several development steps where the actual training of the Al model is just one step in a training pipeline. An important part in Al development is the ML model lifecycle management (LCM). This is illustrated in FIGURE 1, which is an illustration of training and inference pipelines, and their interactions within a model lifecycle management procedure. The model lifecycle management typically consists of: • A training (re-training) pipeline that may include: o Data Ingestion: Data ingestion refers to gathering raw (training) data from a data storage. After data ingestion, there may also be a step that controls the validity of the gathered data. o Data Pre-Processing: Data pre-processing refers to some feature engineering applied to the gathered data. For example, it may include data normalization and possibly a data transformation required for the input data to the Al model. o Model Training: Model training refers to the actual model training steps as previously outlined. o Model Evaluation: Model evaluation refers to benchmarking the performance to some model baseline. The iterative steps of model training and model evaluation continues until the acceptable level of performance is achieved. o Model Registration: Model registration refers to registering the Al model, including any corresponding Al-metadata that provides information on how the Al model was developed, and possibly Al model evaluations performance outcomes.

[0011] • A deployment stage to make the trained (or re-trained) Al model part of the inference pipeline.

[0012] • An inference pipeline that may include: o Data Ingestion: Data ingestion refers to gathering raw (inference) data from a data storage. o Data Pre-Processing: Data pre-processing stage is typically identical to corresponding processing that occurs in the training pipeline. o Model Operational: Model operational refers to using the trained and deployed model in an operational mode. o Data and Model Monitoring: Data & model monitoring refers to validating that the inference data are from a distribution that aligns well with the training data, as well as monitoring model outputs for detecting any performance, or operational, drifts.

[0013] • A drift detection stage that informs about any drifts in the model operations.

[0014] FIGURE 2 illustrates a functional framework that can be used for studying different network-UE collaboration levels for the AI / ML model LCM aspects for Physical Layer use cases. UE-Network Collaboration Levels for One- and Two-Sided AI / ML Models

[0015] The AI / ML models being discussed in the Release 18 study item on AI / ML for the NR air interface can be categorized into the following two types:

[0016] • One-sided AI / ML model, which can be a UE-sided AI / ML model whose inference is performed entirely at the UE, or a network-sided (NW-sided) AI / ML model whose inference is performed entirely at the network.

[0017] • Two-sided AI / ML model, which refers to a paired AI / ML Model(s) over which joint inference is performed across the UE and the network. For example, the first part of the inference is firstly performed by UE and then the remaining part is performed by gNodeB (gNB), or vice versa. As an example of a two-sided AI / ML model, FIGURE 3 illustrates an use case of autoencoder (AE)-based CSI feedback / report, where an encoder (UE-part of the two-sided AE model) is operated at a UE to compress the estimated wireless channel, and the output of the encoder (the compressed wireless channel information estimates) is reported from the UE to a gNB. The gNB uses a decoder (network-part (NW-part) of the two-sided AE model) to reconstruct the estimated wireless channel information. Here the two- sided AI / ML model is composed of the encoder at the UE side and the decoder at the base station (i.e., a gNB) side. Note that in the case of a two-sided model, the code is generated by the encoder and only interpretable by a jointly trained decoder. The situation is different from running an AI / ML model in the UE, reporting the output over the air in a fully standardized format, and running a separate AI / ML model at the base station.

[0018] When applying AI / ML on air interface use cases, different levels of collaboration between network nodes and UEs can be considered:

[0019] • No collaboration between network nodes and UEs. In this case, a proprietary ML model operating with the existing standard air-interface is applied at one end of the communication chain (e.g., at the UE side), and the model life cycle management (e.g., model selection / training, model monitoring, model retraining, model update) is done at this node without inter-node assistance (e.g., assistance information provided by the network node).

[0020] • Limited collaboration between network nodes and UEs for one-sided models. In this case, an ML model is operating at one end of the communication chain (e.g., at the UE side), but this node gets assistance from the node(s) at the other end of the communication chain (e.g., a next generation Node B (gNB)) for its Al model life cycle management to some extent (e.g., for training / retraining the Al model, model update, model monitoring, model selection / fallback / switching).

[0021] • Joint ML operation between network nodes and UEs for two-sided models. In this case, it is assumed that the Al model is split with one part located at the network and the other part located at the UE side. Hence, the Al model requires joint inference between the network and UE, and the Al model life cycle management involves both ends of a communication chain.

[0022] Model Training for One- and Two-Sided Models

[0023] For one-sided models, the model training process for one side can be transparent to the other side (e.g., the network needs no information on how the UE-side trains a UE model), and the responsibility for model LCM is clearly on the side that implements the functionality for making model inference. Network-UE collaborations then basically refers to configuring transmissions and reports to assist in data collection for model training, inference, and monitoring.

[0024] For two-sided models, the model training process may require sharing of data from one side to the other side since the input and output of a two-sided model reside within different vendor’s domain. Different model training types can be considered for two-sided model training between M network vendors and N UE / chip-set vendors, where M>=1 and 7V>=1 :

[0025] • Type 1 : Joint training of the two-sided model at a single side / entity, e.g., the UE- side or the NW-side. For instance, a two-sided model (UE-part model and NW-part model) is trained at the NW side (e.g., by a network vendor), then, the UE-part of the trained model (e.g., encoder for the AE-based CSI compression use case) is transferred / delivered from the NW-side to the UE-side, and vice versa.

[0026] • Type 2: Joint training of the two-sided model at NW-side and UE-side, respectively. Joint training can be done simultaneously at the network and UE sides or be performed in a sequential way. In case of Type 2 simultaneous joint training, the UE-part model (trained at the UE side) and the NW-part model (trained at the network side) are jointly trained in the same loop through exchanging forward propagation values and backward propagation values between network and UE. In case of Type 2 sequential joint training, one side (UE-side or NW-side) starts its model training first, it then opens an Application Programming Interface (API) to facilitate the other side to do the model training. For instance, the network side trains its model first (thus also obtaining what is sometimes known as a nominal encoder, but that is not used at the UE), and then the UE side can train its encoder by using an API. The API would accept, for example, a CSI report and a target CSI, both of which are derived by the UE side based on the data (note that the CSI report is generated, at least partially, by the UE encoder under training and may, thus, not be an efficient CSI report at each step in the training). The API would return gradients of the decoder and a loss function, with respect to the variables in the CSI report. Thus, allowing the UE to train an encoder that is matched to the decoder.

[0027] • Type 3: Sequential training starting with UE side training or sequential training starting with network side training, where the UE-part model and the NW-part model are trained by UE side and network side, respectively. Take sequential training with network-first training approach for AE-based CSI compression as an example, the network can firstly train the UE-part and network-part models jointly using training data (e.g., target CSI samples), and then share a dataset consisting of UE-part model output (e.g., latent space variables) associated to the ground- truth / labels (e.g., target CSI) for the UE-side to train its UE-part model (e.g., an encoder). Alternatively, the network can share a dataset consisting of gradients of the network-part model (e.g., the gradients of the decoder) together with loss function value indicating the discrepancy of the NW-part model output (e.g., the decoder output) and the ground-truth / labels (e.g., target CSI) with respect to the UE-part model output (e.g., latent space variables), based on which the UE-side trains its UE-part model (e.g., an encoder).

[0028] Two-Sided Models in a Multi-Vendor Eco-System

[0029] For a two-sided AEML model-based feature / functionality (e.g., AE-based CSI compression and reporting), the neural network is split into two parts, one at the network side and the other at the UE side. These parts may reflect, for example, CSI compression and decompression (encoding and decoding, respectively). The parts need to be trained together for the decoder to understand the variables passed from the encoder to the decoder.

[0030] In a multi-vendor eco-system, the encoder and decoder typically come from different vendors and, thus, there are many different pairings possible of one network vendor and one UE vendor. In addition, as the feature evolves, there may be multiple network-UE model pairs that are supported. For example, a UE may need to support multiple UE-part models to pair with different NW-side models that are jointly trained with different network-vendors. In addition, between a single network vendor and a single UE / chip-set vendor, multiple pairs of UE-part and NW-part models can be trained for different network / UE configurations, and / or scenarios, and / or releases. Conformance testing and two sided models

[0031] Typically, 3GPP functionality is subject to so-called performance requirements, which are designed to ensure satisfactory and predictable performance of implemented features. Performance requirements are tested prior to placing a device on the market, and the device must be shown to comply with the requirements in order to be placed on the market. The testing is performed by means of test equipment, which emulates some of the functionality of a gNB in a lab environment and measures the performance of the UE.

[0032] In the case of two-sided CSI compression, conformance testing for the UE necessitates that the test equipment incorporates a decoder model. If the UE is to pass the test, then the UE encoder needs to be matched to the decoder in the test equipment. The need for testing brings a further dimension of complexity to the two sided CSI paradigm because it needs co-ordination between the UE implementation and the testing. Furthermore, gNB need to have some knowledge of the model with which UEs were tested.

[0033] At least four approaches have been suggested for how the decoder in the test equipment should be obtained:

[0034] • Network equipment vendors supply the test decoder

[0035] • UE vendors supply the test decoder

[0036] • The test decoder is fully standardized

[0037] • The test decoder is partially standardized

[0038] There currently exist certain challenge(s), however. For example, in the two-sided model case, it is a problem how to support efficient model training in a multi-vender scenario which allows the flexibility of two-sided model design at both the UE and network sides, and at the same time, minimizes the bilateral offline co-engineering effort and the amount of decoder-encoder pairs that need to be subject to compliance testing.

[0039] In addition, it is a problem how to define performance testing in RAN4 and RAN5 of a UE-part of a two-sided model deployed at a UE or / and a NW-part of a two-sided model deployed at a network node, considering the multi-vender scenario, and ensuring the testing feasibility at the same time minimizes the bilateral offline co-engineering effort for testing the model performance.

[0040] In addition, for the two-sided model case, at least one of network side and UE side need to store multiple models (due to the multi-vendor eco-system), it is a problem how to identify and configure the correct model to use on either side before the inference can begin (e.g., before CSI reporting using the models can begin). This identification is needed to be performed such as, for example, when a UE connects to a cell. This identification will be used for different model LCM stages such as, for example, to pair the UE side and NW-side models for a two-sided AI / ML model based feature / functionality during model inference, to identify a potential two-sided model malfunction during performance monitoring, and / or to configure model activation / deactivation / switching / fallback on either side when detecting a potential model malfunction or performance degradation.

[0041] Similar issues (except for model pairing) can be valid for one-sided model case in certain scenarios, such as, for example, when one-sided UE-side model(s) for an AI / ML based feature / functionality are firstly trained at an entity (e.g., NW-side or operator-side) that is different from the UE-side, and after that, the models are transferred / delivered to the UEs. For instance, if the NW-side is responsible to train one-sided UE-sided models, it is a problem how to enable flexible model design for different UE vendors / hardware requirements, and at the same time, minimize the offline co-engineering effort.

[0042] SUMMARY

[0043] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. For example, methods and systems are provided for reference model-based model LCM and performance testing for AI / ML models.

[0044] According to certain embodiments, a method performed by a first radio node for using a first part Al model includes receiving, from a second radio node an indication. The indication may include one or more selected reference model identified s), where each selected reference model identifier identifies one or more first part Al model(s) associated with a feature. Alternatively, the indication may be that no first part Al model is selected. The first radio node uses a first part Al model identified by the one or more selected reference model identified s) indicated by the second radio node, or the first radio node falls back to a non- Al algorithm if the indication from the second node indicates that no first part Al model is selected.

[0045] According to certain embodiments, a first radio node for using a first part Al model is configured to receive, from a second radio node an indication. The indication may include one or more selected reference model identifier(s), where each selected reference model identifier identifies one or more first part Al model(s) associated with a feature. Alternatively, the indication may be that no first part Al model is selected. The first radio node is configured to use a first part Al model identified by the one or more selected reference model identified s) indicated by the second radio node. The first radio node is configured to fall back to a non-AI algorithm if the indication from the second node indicates that no first part Al model is selected. According to certain embodiments, a method performed by a second radio node for using a first part Al-model includes transmitting an indication to a first radio node. The indication indicates one or more selected reference model identified s), and each selected reference model identifier identifies one or more first part model(s) that is / are associated with a feature. Alternatively, the indication indicates that no first part Al model is selected.

[0046] According to certain embodiments, a second radio node for using a first part Al-model is configured to transmit an indication to a first radio node. The indication indicates one or more selected reference model identifier(s), and each selected reference model identifier identifies one or more first part model(s) that is / are associated with a feature. Alternatively, the indication indicates that no first part Al model is selected.

[0047] Certain embodiments may provide one or more of the following technical advantage(s). For example, certain embodiments may provide a technical advantage of providing a standardized reference model based solution that reduces the inter-vendor offline engineering effort needed for training / managing / testing a AI / ML model based feature / functionality.

[0048] As another example, certain embodiments may provide a technical advantage of providing and / or requiring less overhead in transferring / delivering models, since there is a mix of proprietary and standardized part of an AI / ML model, where only the non-standardized part of the model needs to be transferred / delivered.

[0049] As another example, certain embodiments may provide a technical advantage of enabling a more consistent performance of the test model on test gear, since at least a part of the model is standardized.

[0050] As another example, certain embodiments may provide a technical advantage of providing a mix of proprietary and standardized part of an AI / ML model, which may also allow for market competition while at the same time allow for reasonable standardization and testing efforts.

[0051] Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

[0052] BRIEF DESCRIPTION OF THE DRAWINGS

[0053] For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

[0054] FIGURE 1 illustrates training and inference pipelines and their interactions within a model lifecycle management procedure; FIGURE 2 illustrates a functional framework that can be used for studying different network-UE collaboration levels for the AI / ML model LCM aspects for Physical Layer use cases;

[0055] FIGURE 3 illustrates a use case of AE-based CSI feedback / report;

[0056] FIGURE 4 illustrates an example of users retrieving the reference models from a central server, according to certain embodiments;

[0057] FIGURE 5 illustrates an example where users send information to a central server for building the reference models, according to certain embodiments;

[0058] FIGURE 6 illustrates an example that includes training of a standardized reference model, with sequential training of a matching part of a two-sided AI / ML model, according to certain embodiments;

[0059] FIGURE 7 illustrates an example model pairing procedure initiated by the first radio node (e.g., UE) reporting one or more supported reference model identifier(s), according to certain embodiments;

[0060] FIGURE 8 illustrates an example model pairing procedure initiated by the network transmitting reference model identified s), according to certain embodiments;

[0061] FIGURE 9 illustrates an example communication system, according to certain embodiments;

[0062] FIGURE 10 illustrates an example UE, according to certain embodiments;

[0063] FIGURE 11 illustrates an example network node, according to certain embodiments;

[0064] FIGURE 12 illustrates a virtualization environment in which functions implemented by some embodiments may be virtualized, according to certain embodiments;

[0065] FIGURE 13 illustrates an example method by a first radio node, according to certain embodiments;

[0066] FIGURE 14 illustrates an example method by a second radio node, according to certain embodiments;

[0067] FIGURE 15 illustrates another example method by a first radio node, according to certain embodiments;

[0068] FIGURE 16 illustrates another example method by a second radio node, according to certain embodiments;

[0069] FIGURE 17 illustrates an example method by a first radio node for using a first part Al model, according to certain embodiments; and

[0070] FIGURE 18 illustrates a method by a second radio node for using a first part Al-model, according to certain embodiments. DETAILED DESCRIPTION

[0071] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0072] As used herein, ‘node’ can be a network node or a UE. Examples of network nodes are NodeB, base station (BS), multi -standard radio (MSR) radio node such as MSR BS, eNodeB (eNB), gNodeB (gNB), Master eNB (MeNB), Secondary eNB (SeNB), integrated access backhaul (TAB) node, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), Central Unit (e.g. in a gNB), Distributed Unit (e.g. in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), core network node (e.g. Mobile Switching Center (MSC), Mobility Management Entity (MME), etc.), Operations & Maintenance (O&M), Operations Support System (OSS), Self Organizing Network (SON), positioning node (e.g. E- SMLC), etc.

[0073] Another example of a node is user equipment (UE), which is a non-limiting term and refers to any type of wireless device communicating with a network node and / or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, vehicular to vehicular (V2V), machine type UE, MTC UE or UE capable of machine to machine (M2M) communication, Personal Digital Assistant (PDA), Tablet, mobile terminals, smart phone, laptop embedded equipment (LEE), laptop mounted equipment (LME), Unified Serial Bus (USB) dongles, etc.

[0074] In some embodiments, generic terminology, “radio network node” or simply “network node”, is used. It can be any kind of network node which may comprise base station, radio base station, base transceiver station, base station controller, network controller, evolved Node B (eNB), Node B, gNodeB (gNB), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH), Central Unit (e.g. in a gNB), Distributed Unit (e.g. in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP), etc.

[0075] The term radio access technology (RAT), may refer to any RAT such as, for example, Universal Terrestrial Radio Access Network (UTRA), Evolved Universal Terrestrial Radio Access Network (E-UTRA), narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT, NR, 4G, 5G, etc. Any of the equipment denoted by the terms node, network node or radio network node may be capable of supporting a single or multiple RATs. The term signal or radio signal used herein can be any physical signal or physical channel. Examples of downlink (DL) physical signals are reference signal (RS) such as Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), Channel State Information-Reference Signal (CSI-RS), Demodulation Reference Signal (DMRS) signals in SS / PBCH block (SSB), discovery reference signal (DRS), Cell Specific Reference Signal (CRS), Positioning Reference Signal (PRS), etc. RS may be periodic. For example, RS occasions carrying one or more RSs may occur with certain periodicity (e.g., 20 ms, 40 ms, etc.). The RS may also be aperiodic. Each SSB carries New Radio-Primary Synchronization Signal (NR-PSS), New RadioSecondary Synchronization Signal (NR-SSS) and New Radio-Physical Broadcast Channel (NR- PBCH) in four successive symbols. One or multiple Synchronization Signal Blocks (SSBs) are transmitted in one SSB burst which is repeated with certain periodicity such as, for example, 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, and 160 ms. The UE is configured with information about SSB on cells of certain carrier frequency by one or more SS / PBCH block measurement timing configuration (SMTC) configurations. The SMTC configuration comprising parameters such as SMTC periodicity, SMTC occasion length in time or duration, SMTC time offset with regard to reference time (e.g., serving cell’s SFN) etc. Therefore, SMTC occasion may also occur with certain periodicity (e.g., 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, and 160 ms). Examples of uplink (UL) physical signals are reference signals such as Sounding Reference Signals (SRS), Demodulation Reference Signals (DMRS), etc. The term physical channel refers to any channel carrying higher layer information e.g. data, control etc. Examples of physical channels are Physical Broadcast Channel (PBCH), Physical Downlink Control Channel (PDCCH), Physical Downlink Shared Channel (PDSCH), Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel (PUCCH), Physical Uplink Shared Channel (PUSCH), Short PUSCH (sPUCCH), Short PDSCH (sPDSCH), Short PUCCH (sPUCCH), Short PUSCH (sPUSCH), MTC PDCCH (MPDCCH), Narrowband PBCH (NPBCH), Narrowband PDCCH (NPDCCH), Narrowband PDSCH (NPDSCH), Narrowband PUSCH (NPUSCH), Enhanced PDCCH (E-PDCCH), etc.

[0076] The term time resource used herein may correspond to any type of physical resource or radio resource expressed in terms of length of time. Examples of time resources are: symbol, time slot, subframe, radio frame, TTI, interleaving time, slot, sub-slot, mini-slot, system frame number (SFN) cycle, hyper-SFN (H-SFN) cycle etc.

[0077] According to certain embodiments disclosed herein, methods and systems are provided for reference model-based model LCM and performance testing for AI / ML models. For a single sided model, for example, the model is logically split into two parts, a Part A and a Part B. For a two- sided model, the UE-part (e.g., encoder for the CSI-compression use case) and the NW-part (e.g., decoder for the CSI-compression use case) models are each logically split into two parts, a Part A and a Part B. (more precisely: encoder-Part A, encoder-Part B, decoder-Part A, decoder-Part B for the CSI-compression use case).

[0078] In particular embodiments, Part A contains entirely or mostly an architecture / structure while Part B contains entirely or mostly parameters. This allows parameters from Part B to be loaded / updated / adapted / configured into an existing / known model architecture described in Part A (e.g., CNN or Transformer), according to certain embodiments. Thus, there is no need to transfer the whole architecture of Part A from network to UE or vice versa when performing model transfer, only part B need to be transferred, in certain embodiment.

[0079] In particular embodiments, either of Part A or Part B can be proprietary or can be shared / standardized. If a shared / standardized model part is used, then the part is denoted a reference model (or more precisely a reference model part).

[0080] Thus, according to certain embodiments, for a two-sided model, at least one of the UE-part model (e.g., encoder) or the NW-part model (e.g., decoder) has at least one part (Part A or Part B) which is a reference model part, i.e. non-proprietary / semi-public / standardized.

[0081] An example is that the encoder architecture / structure is standardized in 3GPP specifications. Thus, encoder part A can be denoted as a “standardized encoder architecture reference model” and all other parts such as, for example, the encoder parameters (Part B), the decoder architecture (Part A), and decoder parameters (Part B) are all proprietary.

[0082] According to certain embodiments, performance testing as defined by 3 GPP RAN4 and RAN5 of a UE-part of a two-sided model deployed at a UE or / and a NW-part of a two-sided model deployed at a network node is performed based on one or more of the standardized reference models. For example, decoder Part A+B (the decoder structure and parameters) which are proprietary during normal operation may during testing be using a standardized model, also known as the test model.

[0083] According to certain embodiments, multiple such reference models are defined. In a particular embodiment, each reference model is associated with an identifier such as, for example, a “reference model ID”. Different standardized reference models are, thus, assigned with unique model identifiers. During operation of a two-sided AI / ML model-based feature / functionality, the reference model identifiers are used to enable a UE to select a UE-part model that is compatible with the NW-part model used at the network node, according to certain embodiments.

[0084] Thus, certain embodiments may include one or more of: 1. For an AI / ML model in either a UE or the network, in operation for either one sided or two sided models, the model is logically split into two parts, a Part A and a Part B, wherein

[0085] • Part A contains comprises a description of AI / ML model structure (e.g., convolutional neural network (CNN) or Transformer).

[0086] • Part B contains comprises parameters for Part A.

[0087] 2. A model as in 1, where at least Part A is a reference model part (e.g., described in standard / obtained from server), while Part B of the model may be proprietary and can be loaded / updated / adapted / configured / transferred into the existing / known model architecture as described in Part A

[0088] 3. For testing, both part A and B may be configured as reference model parts (e.g., described in standard) . Alternatively, one of the two parts may be configured as a reference model part, whilst another part may be supplied by the UE vendor or the test gear vendor.

[0089] 4. A unique identifier “reference model ID” is assigned to each of the reference models (e.g., UE-part model Part A) of a two-sided model, and it is used to enable a UE to select a UE-part model (e.g., an encoder) that is compatible with the NW- part model (e.g., a decoder) used at the network node during operation of the two- sided model based feature / functionality.

[0090] According to certain embodiments, a list of multiple reference models is defined and used for identifying and / or testing a pair of two-sided models that are intended to operate together / jointly, wherein each reference model is associated with a standardized reference UE-part model, or a standardized reference NW-part model, or a standardized reference pair of two-sided models consisting of a UE-part model and a NW-part model.

[0091] As used herein, a reference model may refer to a part of a reference model of one side of the two-sided models or of one side of a one sided model (e.g., the part A containing the model structure of a encoder) or it may also refer to a complete reference model (thus, part A+ part B).

[0092] A standardized reference model can have a standardized model structure (Part A), or / and a standardized set of model parameters (Part B), or / and associated to a standardized training dataset, or / and associated to a standardized testing dataset.

[0093] Different standardized reference models are differentiated by

[0094] • having different model structures (e.g., convolutional neural network (CNN)-based or transformer-based model architectures, number of layers, number of neurons per layer, number of neurons for one or more specific layers, connection between layers, etc.), and / or

[0095] • having different model parameters (e.g., different model weights and biases), and / or

[0096] • associated with different training datasets, and / or

[0097] • associated with different testing datasets (e.g., datasets used in model performance testing in RAN4).

[0098] The standardized reference models may be provided to UE vendors and / or network vendors in various approaches. In a particular embodiment, for example, a reference model is obtained by a user and used as is. A set of standardized reference models are generated and stored in a central server. An authorized user can retrieve the models by visiting and accessing the server. In another particular embodiment, a reference model is obtained by a user, and the user can amend the reference model for itself using a local dataset. Furthermore, the user can share the local dataset with the server. By aggregating local datasets shared by multiple users, the server may amend the reference model.

[0099] The reference models can be described in an open format (e.g., PyTorch, TensorFlow, ONNX, JAX) for easy understanding by many users and for sharing, i.e., not a proprietary format limited to private parties, or a compiled format customized for a particular hardware.

[0100] For a given functionality (e.g., autoencoder-based CSI compression), multiple standardized reference models (including the case where a reference model refers to only a reference model part, i.e. the structure) are provided for different usages, and / or configurations, and / or scenarios, and / or UE capabilities. In a particular embodiment, for example, a larger model (e.g., part A with more layers or more neurons per layer) is provided for UEs with advanced chip set, and a smaller model (e.g., part A with fewer layers or fewer neurons per layer) for low-cost, low-complexity UEs.

[0101] In another example embodiment, one model (part A only) is provided for UEs that is expected to learn and update the model during deployment, and another model (Part A + Part B) is provided for UEs that are not expected to update the model during deployment.

[0102] In another example embodiment, one (at least Part A) model is provided for UEs having a first input and / or output type (e.g., eigenvector) and another (at least Part A) model is provided for UEs having a second input and / or output type (e.g., W2, or raw channel matrix, etc.). Note that this example may be further extended to the input and / or output sizes. Further, in a similar manner, different models may be provided for the UEs for different pre-processing and / or post-processing types. In another example embodiment, one model is provided for a first set of configurations that represents a first payload size, and another model is provided for a second set of configurations that represent a second payload size. The set configuration can be, for example, be at least one of quantization type, quantization (codebook) size / granularity, latent space size, puncturing rate, etc. Note that the first and / or the second model may also be provided for a set of payload sizes. For example, a model can be provided for latent space sizes of layer 1 (LI), layer 2 (L2), and layer 3 (L3), and another model is provided for latent space sizes of layer 4 (L4), layer 5 (L5), and layer 6 (L6).

[0103] In still another particular example embodiment, and where the case of layer-specific model is supported, one model (e.g., Part A-l) is provided for the first layer (e.g., LI) and another model (e.g., Part A-2) is provided for the second layer (e.g., L2). Alternatively, for a layer specific model Part A may be the same, but Part B may be different for each layer. Similarly, if rank specific model is supported, different models may be provided for different ranks.

[0104] In another example embodiment, Part A can an architecture / structure as well as some parameters for the described architecture / structure. In this case, Part B contains mostly parameters only for the part of the architecture / structure that is not described in Part A. One example from CSI compression may be when the initial layers of a neural network is associated with feature extraction, this may be common for many scenarios (in the case of scenario specific models) and / or Multiple Input Multiple Output (MIMO) layers (in the case of layer specific models). The final layers of a neural network may be associated with compression and may be different for different scenarios and / or MIMO layers. For example, feature extraction for precoders may be similar for MIMO LI and L4, but the variation and correlation over the subbands may be different and, therefore, used differently in compression for MIMO LI and L4.

[0105] Examples of Defining Multiple Standardized Reference Models for a Two-sided AI / ML Model Based Feature / Functionality

[0106] In this section, some examples are given for defining multiple standardized reference models (e.g., a list of standardized network-part models, and / or a list of standardized UE-part models, and / or a list of standardized two-sided models) for a two-sided model based feature / functionality.

[0107] It shall be noted that the same methodology can be used for defining multiple standardized reference models for one-sided model based features / functionalities (e.g., defining a list of standardized NW-sided models for a one-sided NW-sided feature, or defining a list of standardized UE-sided models for a one-sided UE-sided feature). Standardized Network-Part / Network-Side Models

[0108] TABLE 1 gives an example of a list of standardized reference NW-part models for a two- sided AI / ML based C Si-compression use case.

[0109] • Reference NW-part models X-l, X-2, and Y-l are associated to the same training / testing data set (e.g., training / testing dataset #1), but they have different model structures / parameters. Similarly, Reference NW-part models X-3 and Y-2 are associated to the same training / testing data set (e.g., training / testing dataset #2), but they have different model structures / parameters. This can be applicable to the cases where different two-sided models (e.g., small model versus large model, high complexity model versus low complexity model) are designed considering different UE capabilities and / or performance requirements.

[0110] • Reference NW-part models in the last two rows of TABLE 1 are associated to the same training / testing data set (e.g., training / testing dataset #1) and the same model structure, but with different model parameters.

[0111] In a particular embodiment, a reference NW-part / NW-side model has a standardized NW- part / NW-side model structure (Part A), and different model identifiers are defined for different NW-part / NW-side model structures. This model identifier can be used for pairing a two-sided model (see details below), and / or for model LCM procedure like model activation / deactivation / switching / fallback (see details below), and / or for model transfer / delivery of a NW-side / NW-part model (see details below).

[0112] In a particular embodiment, a reference NW-part / NW-side model has a standardized NW- part / NW-side model structure (Part A) and a standardized model parameter set (Part B) associated to the NW-part / NW-side model, and a model identifier is defined based on the standardized NW- part / NW-side model structure and the standardized model parameter set. In this case, the model identifier can be used for pairing a two-sided model (see details in section below), and / or for model LCM procedure like model activation / deactivation / switching / fallback (see details below), and / or for model transfer / delivery of a NW-side / NW-part model (see details below) or / and for testing a LTE-part / LTE-side / NW-part / NW-side model of this AI / ML feature / functionality (see details below).

[0113] In a particular embodiment, a reference NW-part / NW-side model has a standardized NW- part / NW-side model structure (Part A) and a standardized training data set (Part B) associated to the NW-part / NW -side model, and a model identifier is defined based on the standardized NW-part model structure and the standardized training set. In this case, the model identifier can be used for pairing a two-sided model (see details in section below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details in section below), or / and for model transfer / delivery of a NW-side / NW-part model (see details in section below) or / and for testing a UE-part / UE-side / NW-part / NW-side model of this AI / ML feature / functionality (see details in section below).

[0114] In a particular embodiment, a reference NW-part / NW-side model has a standardized NW- part / NW-side model structure (Part A) and a standardized testing data set (Part B) associated to the NW-part / NW-side model, and a model identifier is defined based on the standardized NW- part / NW-side model structure and the standardized testing set. In this case, the model identifier can be used for pairing a two-sided model (see details in section below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details in section below), or / and for model transfer / delivery of a NW-side / NW-part model (see details in section below) or / and for testing a UE-part / UE-side / NW -part / NW -side model of this AI / ML feature / functionality (see details in section below).

[0115] In a particular embodiment, different model identifiers are assigned to a reference NW- part / NW-side model, depending on the usage of the model identifier. For instance, the model identifier for the reference NW-part / NW-side model in the last row of TABLE 1 is defined based on its model structure (called as Y-2 in TABLE 1) for model LCM purposes, while as the model identifier for the same reference NW-part / NW-side model is defined based on its model structure and model parameters (called as Y-3) for model performance testing purposes.

[0116] TABLE 1 : An example of standardized reference NW-part models (e.g., reference decoders) for a two-sided AI / ML based CSI-compression feature / functionality

[0117]

[0118] Part A describes the structure of the AI / ML model. Regardless of the type / backbone is used, e.g., Feed-forward / Fully connected / multi-layer Perceptron (MLP), or convolutional neural network (CNN), or Transformer, a description of the overall model / network architecture involves can involve, for example:

[0119] • The number of layers, and the connection between these. An example of the latter are skip-connections, where the data does not only “go through” a layer, but, for example, is combined with the output of that layer as well, and / or combined with the output of later layers.

[0120] • The activation functions used, e.g., rectified linear unit (ReLU), tanh or other sigmoid functions, and / or softmax, and / or that no activation function is used after a particular layer.

[0121] • The normalizations used, if any, e.g., Batch Norm (and what parameters are learnable, e.g., with or without a bias), and / or Layer Norm, and / or some vector- / matrix- / tensor norm is applied to the output of a layer.

[0122] • If it is a complex- valued or real-valued neural network, and in the latter case how complex numbers are represented, e.g., real-part and imaginary part, or phase and magnitude.

[0123] For a CNN, e.g., CNN X-l, X-2, and X-3, in TABLE 1 above, the following are further examples of things that can be described in Part A: o For each layer, the architecture describes what type of layer it is, meaning what type of operations are done and how the parameters are organized. Examples of layers that can be present in a CNN and their corresponding hyper- / meta- parameters are:

[0124] ■ Linear layer. Hyper- / meta-parameters include, e.g., output size (which together with the input size determines the size of the layer), and / or if there is a bias term to be added or not.

[0125] ■ Pooling layer. Hyper- / meta-parameters include, e.g., what type of pooling it is, e.g., average pooling, max-pooling, complex- valued version of pooling (e.g., choice based on absolute value, but full complex number being propagated forward, and / or max or argmax independent pooling of real- and imaginary-part, respectively). Further hyper parameters include, e.g., filter size, padding, and stride. Note, pooling layers can be part of the architecture, but contains no trainable parameters.

[0126] ■ Convolutional layer. Hyper- / meta-parameters include, e.g., what type of convolutions it is, e.g., 1D / 2D / 3D / . . ., “depthwise separable”, "transpose convolution”, and / or if there is a bias term to be added or not. Further hyper parameters include, e.g., the number of filters used in a layer, kernel sizes for the corresponding filters, what strides and padding used for the corresponding filters.

[0127] • Over which dimensions the convolutions are taken, e.g., for reporting of frequency selective precoders in CSI feedback for a single MIMO layer, the dimensions may be CSI-RS transmission port on the BS times the subband in frequency. A ID convolution can then convolve over / traverse the frequency domain while fully connecting the CSI-RS-Tx-Port dimension, or vice versa.

[0128] For a Transformer, e.g., Transformer Y-l and Y-2, in TABLE 1 above, the following are further examples of things that can be described in Part A: o Which dimension is considered the “ sequence dimension" and which is considered the “feature dimension". The former, sequence dimension, is the dimension over which attention is computed; in other words, progression in this dimension represents progression between different feature vectors. The latter, feature dimension, is the dimension that gets transformed by the embedding and represents the vectors that are used to compute attention; in other words, progression in this dimension represents progression over a feature vector.

[0129] ■ For example, when reporting frequency selective precoders in CSI feedback for a single MIMO layer, the dimensions may be CSI-RS transmission port on the BS times the subband in frequency. Thus the sequence dimension may be the subband in frequency and the feature dimension may be the CSI- RS transmission ports, or vice versa. In the former case, the embedding would, for example, increase the dimension from 32 CSI-RS ports to 128 scalar values, for each subband, and the attention would be computed based on an inner product of these 128-long vectors. o For each layer, the architecture describes what type of layer it is, meaning what type of operations are done and how the parameters are organized. Examples of layers that can be present in a Transformer and their corresponding hyper- / meta- parameters are:

[0130] ■ Linear layer. Hyper- / meta-parameters include, e.g., output size (which together with the input size determines the size of the layer), and / or if there is a bias term to be added or not.

[0131] ■ Multi-head attention layer. Hyper- / meta-parameters include, e.g., key-size (determines the size of the linear layers that produce the key- and queryvectors in the attention head), value-size (determines the size linear layer that produces the value vectors in the attention head), model -output-size (determines the size of the linear layer that produces the final output of multi-head attention module), and number of heads.

[0132] ■ Embedding layer. The embedding can be done, e.g., using a linear layer (with / without an activation function and with / without adding a bias). Other options are not precluded.

[0133] ■ Positional encoding. Can be done either in a fixed and specified way, in which case Part A may define the exact positional encoding and Part B does not contain any information about it. It can also be done in a configurable way, in which case Part A specifies the ways in which it can be done, and Part B includes a parameter to select one of the specified ways. It can also be done in a learnable way, in which case Part A describes the general framework, e.g., the addition of a matrix of a certain size to the data, and Part B includes trained parameters, e.g., the entries of the aforementioned matrix. o The architecture also needs to describe if it is a multi-head attention layer is a selfattention or a cross-attention layer. The former employs the same input to generate keys, query, and value; the latter uses one input to generate the query and another input to generate the key and value.

[0134] For a Feed-forward Neural Network (NN) / Fully connected NN / MLP, the following are further examples of things that can be described in Part A: o For each layer, the architecture describes what type of layer it is, meaning what type of operations are done and how the parameters are organized. Examples of layers that can be present in a fully connected NN and their corresponding hyper- / meta-parameters include: Linear layer. Hyper- / meta-parameters include, e.g., output size (which together with the input size determines the size of the layer), and / or if there is a bias term to be added or not.

[0135] Standardized UE-part / UE-side Models

[0136] TABLE 2 gives an example of standardized reference UE-part models for a two-sided AI / ML based C Si-compression feature / functionality.

[0137] In a particular embodiment, a reference UE-part / UE-side model has a standardized UE- part / UE-side model structure (Part A), and different model identifiers are defined for different UE- part / UE-side model structures. This model identifier can be used for pairing a two-sided model(see details below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details below), or / and for model transfer / delivery of a UE-part / UE-side model (see details below).

[0138] In a particular embodiment, a reference UE-part / UE-side model has a standardized UE- part / UE-side model structure (Part A) and a standardized model parameter set (Part B) associated to the UE-part / UE-side model, and a model identifier is defined based on the standardized UE- part / UE-side model structure and the standardized model parameter set. In this case, the model identifier can be used for pairing a two-sided model (see details below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details below), or / and for model transfer / delivery of a UE-part / UE-side model (see details below) or / and for testing a UE- part / UE-side / NW-part / NW-side model of this AI / ML feature / functionality (see details below).

[0139] In a particular embodiment, a reference UE-part / UE-side model has a standardized UE- part / UE-side model structure (Part A) and a standardized training data set (Part B) associated to the UE-part / UE-side model, and a model identifier is defined based on the standardized UE- part / UE-side model structure and the standardized training set. In this case, the model identifier can be used for pairing a two-sided model (see details below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details below), or / and for model transfer / delivery of a UE-part / UE-side model (see details below) or / and for testing a UE-part / UE- side / NW-part / NW-side model of this AI / ML feature / functionality (see details below).

[0140] In a particular embodiment, a reference UE-part / UE-side model has a standardized UE- part / UE-side model structure (Part A) and a standardized testing data set (Part B) associated to the UE-part / UE-side model, and a model identifier is defined based on the standardized UE-part / UE- side model structure and the standardized testing set. In this case, the model identifier can be used for pairing a two-sided model (see details below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details below), or / and for model transfer / delivery of a UE-part / UE-side model (see details below) or / and for testing a UE-part / UE-side / NW- part / NW-side model of this AI / ML feature / functionality (see details below).

[0141] In a particular embodiment, different model identifiers are assigned to a reference UE- part / UE-side model, depending on the usage of the model identifier. For instance, the model identifier for the reference UE-part / UE-side model in the last row of TABLE 2 is defined based on its model structure (called as Y-2 in TABLE 2) for model LCM purposes, while as the model identifier for the same reference UE-part / UE-side model is defined based on its model structure and model parameters (called as Y-3) for model performance testing purposes.

[0142] TABLE 2: An example of standardized reference UE-part models (e.g. reference encoders) for a two-sided AI / ML based CSI-compression feature / functionality

[0143] Standardized Reference Two-sided Models

[0144] TABLE 3 shows an example of standardized reference two-sided models (e.g., reference encoders and decoders) for a two-sided AI / ML based CSI-compression feature / functionality. In a particular embodiment, a reference two-sided model is defined based on a pair of a reference UE-part model and a reference NW-part model.

[0145] In a further particular embodiment, different reference model identifiers are assigned to different reference two-sided models. In a particular embodiment, different reference two-sided models are associated to the same reference UE-part model, but different reference NW -part models. In another particular embodiment, different reference two-sided models are associated to the same reference NW-part model, but different reference UE-part models.

[0146] In a particular embodiment, a reference two-sided model has a standardized UE-part model structure (Part A) and a standardized NW-part model structure (Part A). Different model identifiers are defined for different two-sided model structures. This model identifier can be used for pairing a two-sided model (see details below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details below), or / and for model transfer / delivery of a UE-part / NW-part model (see details below).

[0147] In a particular embodiment, a reference two-sided model has a standardized UE-part model structure (Part A), a standardized NW-part model structure (Part A), and a standardized model parameter set (Part B) associated to the two-sided model. A model identifier is defined based on the standardized two-sided model structure and the standardized model parameter set. In this case, the model identifier can be used for pairing a two-sided model (see details below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details below), or / and for model transfer / delivery of a UE-part / NW-part model (see details below) or / and for testing a UE-part / NW-part model of this two-sided AI / ML feature / functionality (see details below).

[0148] In a particular embodiment, a reference two-sided model has a standardized UE-part model structure (Part A), a standardized NW-part model structure (Part A), and a standardized training data set (Part B) associated to the two-sided model. And a model identifier is defined based on the standardized two-sided model structure and the standardized training set. In this case, the model identifier can be used for pairing a two-sided model (see details below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details below), or / and for model transfer / delivery of a UE-part / NW-part model (see details below) or / and for testing a UE- part / NW-part model of this two-sided AI / ML feature / functionality (see details below).

[0149] In a particular embodiment, a reference two-sided model has a standardized UE-part model structure (Part A), a standardized NW-part model structure (Part A), and a standardized testing data set (Part B) associated to the two-sided model. And a model identifier is defined based on the standardized two-sided model structure and the standardized testing set. In this case, the model identifier can be used for pairing a two-sided model (see details below), or / and for model LCM procedure like model activation / deactivation / switching / fallback (see details below), or / and for model transfer / delivery of a UE-part / NW-part model (see details below) or / and for testing a UE- part / NW-part model of this two-sided AI / ML feature / functionality (see details below). In a particular embodiment, different model identifiers are assigned to a reference two- sided model, depending on the usage of the model identifier. For instance, the model identifier for the reference two-sided model in the last row of TABLE 3 is defined based on its model structure (called as Y-2 in TABLE 3) for model LCM purposes, while as the model identifier for the same reference two-sided model is defined based on its model structure and model parameters (called as Y-3) for model performance testing purposes.

[0150] TABLE 3: An example of standardized reference two-sided models (e.g. reference encoders and decoders) for a two-sided AI / ML based C Si-compression feature / functionality

[0151] Generation and Maintenance of the Standardized Reference Models

[0152] The standardized reference models may be generated and provided to UE vendors and / or network vendors in various approaches.

[0153] In a first particular embodiment, the standardized reference model is obtained by a user without the user sending any information to influence the generation of the reference model. For the two-sided model, the user (e.g., UE vendor) may obtain the UE-side model of the paired model, or the user (e.g., NW vendor) may obtain the NW-side model of the paired model, or the user may obtain both sides of the paired model. In general, for a given functionality, a set of one or more standardized reference models are generated and stored in the central server. An authorized user can retrieve the reference models by visiting the server. FIGURE 4 illustrates an example 100 of users 102a, 102b, 102c retrieving the reference models from a central server 104, according to certain embodiments.

[0154] In a further particular embodiment, the reference model (Modelrej is obtained by a user 102a-c and used as is. The standardized reference model is trained using a pre-defined training dataset, and the obtained reference model is stored in the central server 104. In this case, different users share the same model (Modelrej . Typically, the reference model Modelref s not yet compiled and optimized for any specific software or hardware solutions. Different users 102a-c may further optimize and compile Modelref differently for their own implementation (e.g., hardware platform), i.e., each user 102a-c may run a different executable version oiModelref. For model testing, each user's executable version of Modelref s under test to check the model performance.

[0155] In another particular embodiment, a reference model Modelref is obtained by a user 102a- c, and the user 102a-c can update the reference model for itself using a local dataset. For example, each user j can update the retrieved reference model (Modelrej using its local dataset j and obtain an updated model Modelj). In this case, different users 102a-c can have a different Modelj). Furthermore, each user j may optimize and compile Modelj for their own implementation (e.g., hardware platform). For model testing, each user's executable version of Modelj is under test to check the model performance.

[0156] In another particular embodiment, the reference model (Modelrej is a decoder model, and it is obtained by a UE vendor. The UE vendor may then use the reference model to train its own encoder model. The latter being a proprietary implementation, from training to optimization and generation of executable.

[0157] In another particular embodiment, the reference model (Modelrej is an encoder model, and it is obtained by a network vendor. The network vendor may then use the reference model to train its own decoder model. The latter being a proprietary implementation, from training to optimization and generation of executable.

[0158] In a second particular embodiment, user(s) 102a-c can contribute to the generation of the standardized reference model. For the two-sided model, the user 102a-c (e.g., UE vendor) may contribute to the UE-side model of the paired model, or the user (e.g., NW vendor) 102a-c may contribute to the NW-side model of the paired model, or the user 102a-c may contribute to both sides of the paired model.

[0159] The user 102a-c may contribute in several ways.

[0160] (a) User j sends a local model (Modelj) trained by user j. After receiving multiple models (e.g., Modeh, Model 2, Models) from multiple users (e.g., user 1, user 2, user 3), then the central server can obtain the reference model Modelref) by aggregating the multiple models (e.g., Model 7, Model 2., Models).

[0161] (b) User j sends a local training dataset j for the purpose of training the reference model. After receiving multiple datasets (e.g., Dataseti, Datasets, Datasets from multiple users (e.g., user 1, user 2, user 3), then the central server can obtain the reference model (Modelrej) by training it using the aggregated dataset {Dataseti, Datasets, Datasets}.

[0162] (c) Use a combination of (a) and (b). That is, some users j contribute by sending a local model Model / ) to the central server 104, and other users k contribute by sending a local training dataset Datasetk.

[0163] Furthermore, the users 102a-c can contribute to the generation of the reference model periodically or iteratively, if there is a need to generate several versions or releases of the standardized reference model.

[0164] After the reference model (Modelrej) is generated by the central server 104, then the reference model can be retrieved by individual users 102a-c as in the first method.

[0165] FIGURE 5 illustrates an example 200 where users 202a, 202b, 202c send information to a central server 204 for building the reference models, according to certain embodiments.

[0166] In a third method, user(s) 202a-c can contribute to the generation of standardized reference models, e.g., reference decoders with sequential training of a matching AI / ML model, e.g., an encoder. FIGURE 6 illustrates an example 300 that includes training of a standardized reference model, with sequential training of a matching part of a two-sided AI / ML model, according to certain embodiments.

[0167] As shown in step 1 of FIGURE 6, Part A of a standardized reference model (e.g., a decoder) may be obtained by a user 302a (e.g., a NW vendor). The user 302a trains a two-sided model at step 2 of FIGURE 6, where Part A of the second half of the two-sided model, e.g., an encoder, may be obtained from the same server 304 or implemented proprietarily. At step 3, the user 302a may submit the learned parameters are Part B, associated with the obtained Part A, to jointly be accepted as a reference model (Modelrej).

[0168] In a further particular embodiment, the generated reference model Modelref being a common Part A and specific Part B), e.g., a decoder model, can then be obtained from the server 304 by a second user 302b, e.g., a UE vendor, as shown in step 4 of FIGURE 6. The second user 302b may then use the reference model to train its own model at step 5 of FIGURE 6, e.g., an encoder. The latter being a proprietary implementation, from training to optimization and generation of executable.

[0169] Reference Model Based Model Performance Testing in RAN4 / 5

[0170] For performance testing, the UE is connected to a test equipment.

[0171] In a particular embodiment, the test equipment may have a standardized reference model Part A and Part B. The UE may apply its own model during the test in order to achieve the performance requirement. The UE vendor will have knowledge of the reference model because it is standardized.

[0172] In another particular embodiment, the test equipment may have a standardized reference model Part A. The test equipment may indicate to the UE a Part B parameterization that is used in the test equipment, or the UE may send Part B parameters to the test equipment for operating the test.

[0173] In another particular embodiment, the UE may indicate a Part A model to be used by the test equipment to the test equipment. In addition, the UE may send Part B parameters to the test equipment or, alternatively, the test equipment may select Part B parameters to operate with the indicated Part A.

[0174] In another particular embodiment, the UE may indicate a Part A for its own model to the test equipment, and the test equipment may send Part B parameters to the UE for use during the test.

[0175] In another particular embodiment, the test equipment may indicate a Part A to the UE to be used by the UE, and the UE may indicate Part B parameters that it uses for the model to the test equipment.

[0176] In another particular embodiment, the test equipment may indicate a Part A to the UE as well as Part B parameters in order that the UE uses the combination for its test.

[0177] In another particular embodiment, the UE may indicate a plurality of Part A models that it supports to the test equipment, and the test equipment may indicate which Part A model to use.

[0178] For each of the above embodiments, the test is performed by the test equipment operating its Part A and Part B model, and the user equipment operating its Part A and Part B model. The test will verify that specified performance metrics are met or exceeded. In the case of multiple possibilities for Part A and / or Part B models on either side, the test may be repeated multiple times such that each variation of Part A and Part B is tested.

[0179] Reference Model Based Model Pairing Procedure for Two-sided Model Cases According to certain embodiments, and in cases where multiple such reference models are designed for an AI / ML based feature / functionality, each reference model is associated with an identifier (“reference model ID”). Different standardized reference models are thus assigned with unique model identifiers. During operation of a two-sided AI / ML model-based feature / functionality, the reference model identifiers are used to enable a UE to select a UE-part model that is compatible with the NW-part model used at the NW node. Below we provide two examples of model pairing procedures based on the reference model IDs.

[0180] FIGURE 7 shows an example model pairing procedure 400 initiated by the first radio node 402 (e.g., UE) reporting one or more supported reference model identifier(s), according to certain embodiments. As illustrated, the model pairing procedure begins a step 410 when the first radio node 402 (e.g., a UE) indicates / reports its capability for a two-sided AI / ML based feature / functionality to the second radio node 404 (e.g., the serving gNB of the UE).

[0181] At step 420, the second radio node 404 configures the first radio node 402 with the two- sided AI / ML feature and requires the first radio node 402 to report the reference model identified s) for the first-part model(s) stored at the first node 402 for this feature. The second radio node 404 may also indicate the first radio node 402 certain configurations or / and applicable conditions for this feature.

[0182] Optionally, at step 430, the first radio node 402 checks the performance and / or application conditions of all its stored first-part models for this feature and selects a subset of first-part models that are appropriate for the current scenario and configuration.

[0183] At step 440, the first radio node 402 reports the reference model identifier(s) for the appropriate first-part model(s) for this feature to the second radio node 404.

[0184] At step 450, the second radio node 404 determines the first-part model selection results based on the reference model identifier(s) received from the first radio node 402 such as, for example, by comparing the received identifier(s) with the key(s) for its second-part model(s). In case none of the received key(s) matches to its stored second-part model(s) for this feature, the second radio node 404 does not select a first-part model for this feature.

[0185] At step 460, the second radio node 404 indicates the model selection result to the first radio node 402. The selection result indicates the selected one or more first part model(s) or no first-part model is selected. For the former case, the second radio node 404 can indicate the selected one or more first-part model(s) by signaling the index of the selected reference model identifiers among all received identifier(s) from the first radio node 402 for this feature (e.g., select the first-part model corresponding to the third reference model identifier reported from the first node). For the latter case, the second radio node 404 can indicate no first-part model is selected by setting the indication value to 0 or NULL.

[0186] At step 470, the first radio node 402 uses one selected first-part model for this feature, or falls back to a non-ML algorithm if no-first part model is selected by the second radio node 404.

[0187] It is noted that a UE can report the reference model identifiers for all its stored UE-part models for the two-sided AI / ML based feature / functionality when reporting its capability for this feature. In this case, step 430 can be skipped, and step 440 can be merged into step 410.

[0188] FIGURE 8 shows an example model pairing procedure 500 initiated by the network transmitting reference model identifier(s), according to certain embodiments. As depicted, the procedure begins when the first radio node 502 (e.g., a UE) reports its capability for a two-sided AI / ML based feature / functionality to the second radio node 504 (e.g., the serving gNB of the UE).

[0189] At step 520, the second radio node 504 configures the first radio node 502 with the two- sided AI / ML feature.

[0190] At an optional step 530, the second radio node 504 checks the performance and / or application conditions of all its stored second-part models for this feature and selects a subset of second-part models that are appropriate for the current scenario and configuration.

[0191] At step 540, the second node 504 transmits the reference model identifiers associate to the appropriate second-part models for this feature to the first radio node 502 in a uni cast / group cast / multi cast / b roadcast fashi on .

[0192] At step 550, the first radio node 502 determines the first-part model selection results based on the reference model identifier(s) received from the second radio node 504, e.g., by comparing the received identifiers(s) with the identifiers(s) for its first-part model(s). In case none of the received identifiers(s) matches to its stored first-part model(s) for this feature, the first radio node 502 does not select a first-part model for this feature.

[0193] At an optional step 560, the first radio node 502 indicates the model selection result to the second radio node 504. The selection result indicates the selected one or more first-part model(s), or no first-part model is selected. For the former case, the first radio node 502 can indicate the selected one or more first-part model(s) by signaling the index of the selected reference model identifiers(s) among all received reference model identifiers(s) from the second radio node 504 for this feature (e.g., select the first-part model corresponding to the third reference model identifier transmitted from the second radio node 504). For the latter case, the first radio node 502 can indicate no first-part model is selected by setting the indication value to 0, or NULL. If only a single reference model identifier is received at the first radio node 502, then, the first radio node502 can indicate to the second radio node 504 whether it can pair with the second-part model by signaling ACK / NACK, 0 or 1, true / false, etc.

[0194] At an optional step 570, the second radio node 504 indicates that it acknowledges of the first-part model selection result. If the selection results reported from the first radio node 502 indicates that no first-part model is selected, then, the second radio node 504 configures the first radio node 502 to use a fallback algorithm.

[0195] At step 580, the first radio node 502 uses one selected first-part model for this feature or fallback to a non-ML algorithm based on instructions received from the second radio node 504.

[0196] Moreover, in some cases, there is no need for either the UE or the NW to initiate a dedicated model pairing procedure as described above, if the model pairing can be achieved implicitly via a separate procedure. As an example, for UE testing, model pairing is implicitly defined in the test case description. For the special case of UE testing, the test equipment acts as the NW node towards the device under test (DUT). For a given functionality, one or more test cases can be defined (e.g., one test case for AWGN, another test case for fading channel). For a given test case, a reference model identifier may be pre-defined as a part of the test parameters. Thus, when running the given test case, both the UE (i.e., the DUT) and the NW node (i.e., the test equipment) are both aware of the reference model to use.

[0197] Reference Model Based Model Transfer / Delivery Or / And Dataset Delivery

[0198] One-Sided Model Use Cases:

[0199] For a one-sided model based Al feature / functionality, in some cases, the one or more model structures (i.e., Part A of a one-sided model) are standardized and denoted as the reference model(s) for the one-sided model based Al feature / functionality. The reference model is associated with an identifier (“reference model ID”). During model transfer / delivery, e.g., when a network node (e.g., gNB, core network node, or 0AM) transfers / delivers a model parameter set (Part B) and / or a training dataset to the UE, the identifier is used to align between network and UE on which UE-side reference model the transferred / delivered model parameter set and / or training dataset is associated with. The same methodology can be used for model transfer / delivery or dataset delivery from a UE to a network node for a NW-side model, and for model transfer / delivery or dataset delivery from a server to a network node for a NW-side model, and for model transfer / delivery or dataset delivery from a server to a UE for a UE-side model, etc.

[0200] Two-Sided Model Use Cases: For a two-sided model based Al feature / functionality, in some cases, the one or more model structures are standardized and denoted as the reference model(s) for the two-sided model based Al feature / functionality. An example is that the encoder architecture(s) / structure(s) is / are standardized in 3GPP specifications. Thus, an encoder Part A can be denoted as a “reference model” and all other parts, i.e. the encoder parameters (Part B), the decoder architecture (Part A) and decoder parameters (Part B) are all proprietary. Separate procedures can be designed for model pairing and model transfer / delivery for a two-sided AI / ML model based feature / functionality. For instance, each reference model (e.g., encoder Part A) is associated with an identifier (“reference model ID”) and model pairing for a two-sided model based Al feature / functionality is performed based on the reference model ID based pairing procedure as described in the above section. During model transfer / delivery procedure, e.g., when a network node transfers / delivers a model parameter set (e.g., encoder Part B) and / or a training dataset to the UE, the identifier is used to align between network and UE on which reference model the transferred / delivered model parameter set and / or training dataset is associated with.

[0201] The same methodology, i.e., reference model identifier based method, can also be used for a UE to transfer / delivery a model parameter set (e.g., decoder Part B) and / or a training dataset to a network node for a NW-part model, for a server to transfer / delivery a model parameter set (decoder Part B) and / or a training dataset to a network node for a NW-part model, and / or for a server to transfer / delivery a model parameter set (e.g., encoder Part B) and / or a training dataset to a UE for a UE-part model.

[0202] FIGURE 9 shows an example of a communication system 600 in accordance with some embodiments. In the example, the communication system 600 includes a telecommunication network 602 that includes an access network 604, such as a radio access network (RAN), and a core network 606, which includes one or more core network nodes 608. The access network 604 includes one or more access network nodes, such as network nodes 610a and 610b (one or more of which may be generally referred to as network nodes 610), or any other similar 3rdGeneration Partnership Project (3 GPP) access node or non-3GPP access point. The network nodes 610 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 612a, 612b, 612c, and 612d (one or more of which may be generally referred to as UEs 612) to the core network 606 over one or more wireless connections.

[0203] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 600 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 600 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0204] The UEs 612 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 610 and other communication devices. Similarly, the network nodes 610 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 612 and / or with other network nodes or equipment in the telecommunication network 602 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 602.

[0205] In the depicted example, the core network 606 connects the network nodes 610 to one or more hosts, such as host 616. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 606 includes one more core network nodes (e.g., core network node 608) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 608. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0206] The host 616 may be under the ownership or control of a service provider other than an operator or provider of the access network 604 and / or the telecommunication network 602, and may be operated by the service provider or on behalf of the service provider. The host 616 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. As a whole, the communication system 600 of FIGURE 9 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0207] In some examples, the telecommunication network 602 is a cellular network that implements 3 GPP standardized features. Accordingly, the telecommunications network 602 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 602. For example, the telecommunications network 602 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0208] In some examples, the UEs 612 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 604 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 604. Additionally, a UE may be configured for operating in single- or multi -RAT or multi -standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0209] In the example, the hub 614 communicates with the access network 604 to facilitate indirect communication between one or more UEs (e.g., UE 612c and / or 612d) and network nodes (e.g., network node 610b). In some examples, the hub 614 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 614 may be a broadband router enabling access to the core network 606 for the UEs. As another example, the hub 614 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 610, or by executable code, script, process, or other instructions in the hub 614. As another example, the hub 614 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 614 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 614 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 614 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 614 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.

[0210] The hub 614 may have a constant / persistent or intermittent connection to the network node 610b. The hub 614 may also allow for a different communication scheme and / or schedule between the hub 614 and UEs (e.g., UE 612c and / or 612d), and between the hub 614 and the core network 606. In other examples, the hub 614 is connected to the core network 606 and / or one or more UEs via a wired connection. Moreover, the hub 614 may be configured to connect to an M2M service provider over the access network 604 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 610 while still connected via the hub 614 via a wired or wireless connection. In some embodiments, the hub 614 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 610b. In other embodiments, the hub 614 may be a nondedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 610b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0211] FIGURE 10 shows a UE 700 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0212] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehi cl e-to- vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0213] The UE 700 includes processing circuitry 702 that is operatively coupled via a bus 704 to an input / output interface 706, a power source 708, a memory 710, a communication interface 712, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIGURE 10. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0214] The processing circuitry 702 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 710. The processing circuitry 702 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general -purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 702 may include multiple central processing units (CPUs).

[0215] In the example, the input / output interface 706 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 700. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0216] In some embodiments, the power source 708 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 708 may further include power circuitry for delivering power from the power source 708 itself, and / or an external power source, to the various parts of the UE 700 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 708. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 708 to make the power suitable for the respective components of the UE 700 to which power is supplied.

[0217] The memory 710 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 710 includes one or more application programs 714, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 716. The memory 710 may store, for use by the UE 700, any of a variety of various operating systems or combinations of operating systems.

[0218] The memory 710 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 710 may allow the UE 700 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 710, which may be or comprise a device-readable storage medium. The processing circuitry 702 may be configured to communicate with an access network or other network using the communication interface 712. The communication interface 712 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 722. The communication interface 712 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 718 and / or a receiver 720 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 718 and receiver 720 may be coupled to one or more antennas (e.g., antenna 722) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0219] In the illustrated embodiment, communication functions of the communication interface 712 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0220] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 712, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0221] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0222] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or itemtracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 700 shown in FIGURE 10.

[0223] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0224] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators. FIGURE 11 shows a network node 800 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)).

[0225] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0226] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi -standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0227] The network node 800 includes a processing circuitry 802, a memory 804, a communication interface 806, and a power source 808. The network node 800 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 800 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 800 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 804 for different RATs) and some components may be reused (e.g., a same antenna 810 may be shared by different RATs). The network node 800 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 800, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 800.

[0228] The processing circuitry 802 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 800 components, such as the memory 804, to provide network node 800 functionality.

[0229] In some embodiments, the processing circuitry 802 includes a system on a chip (SOC). In some embodiments, the processing circuitry 802 includes one or more of radio frequency (RF) transceiver circuitry 812 and baseband processing circuitry 814. In some embodiments, the radio frequency (RF) transceiver circuitry 812 and the baseband processing circuitry 814 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 812 and baseband processing circuitry 814 may be on the same chip or set of chips, boards, or units.

[0230] The memory 804 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 802. The memory 804 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 802 and utilized by the network node 800. The memory 804 may be used to store any calculations made by the processing circuitry 802 and / or any data received via the communication interface 806. In some embodiments, the processing circuitry 802 and memory 804 is integrated.

[0231] The communication interface 806 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 806 comprises port(s) / terminal(s) 816 to send and receive data, for example to and from a network over a wired connection. The communication interface 806 also includes radio frontend circuitry 818 that may be coupled to, or in certain embodiments a part of, the antenna 810. Radio front-end circuitry 818 comprises filters 820 and amplifiers 822. The radio front-end circuitry 818 may be connected to an antenna 810 and processing circuitry 802. The radio frontend circuitry may be configured to condition signals communicated between antenna 810 and processing circuitry 802. The radio front-end circuitry 818 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 818 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 820 and / or amplifiers 822. The radio signal may then be transmitted via the antenna 810. Similarly, when receiving data, the antenna 810 may collect radio signals which are then converted into digital data by the radio front-end circuitry 818. The digital data may be passed to the processing circuitry 802. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0232] In certain alternative embodiments, the network node 800 does not include separate radio front-end circuitry 818, instead, the processing circuitry 802 includes radio front-end circuitry and is connected to the antenna 810. Similarly, in some embodiments, all or some of the RF transceiver circuitry 812 is part of the communication interface 806. In still other embodiments, the communication interface 806 includes one or more ports or terminals 816, the radio front-end circuitry 818, and the RF transceiver circuitry 812, as part of a radio unit (not shown), and the communication interface 806 communicates with the baseband processing circuitry 814, which is part of a digital unit (not shown).

[0233] The antenna 810 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 810 may be coupled to the radio front-end circuitry 818 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 810 is separate from the network node 800 and connectable to the network node 800 through an interface or port.

[0234] The antenna 810, communication interface 806, and / or the processing circuitry 802 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 810, the communication interface 806, and / or the processing circuitry 802 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment. The power source 808 provides power to the various components of network node 800 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 808 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 800 with power for performing the functionality described herein. For example, the network node 800 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 808. As a further example, the power source 808 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0235] Embodiments of the network node 800 may include additional components beyond those shown in FIGURE 11 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 800 may include user interface equipment to allow input of information into the network node 800 and to allow output of information from the network node 800. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 800.

[0236] FIGURE 12 is a block diagram illustrating a virtualization environment 900 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 900 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

[0237] Applications 902 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 900 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. Hardware 904 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 908a and 908b (one or more of which may be generally referred to as VMs 908), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 906 may present a virtual operating platform that appears like networking hardware to the VMs 908.

[0238] The VMs 908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 906. Different embodiments of the instance of a virtual appliance 902 may be implemented on one or more of VMs 908, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0239] In the context of NFV, a VM 908 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 908, and that part of hardware 904 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 908 on top of the hardware 904 and corresponds to the application 902.

[0240] Hardware 904 may be implemented in a standalone network node with generic or specific components. Hardware 904 may implement some functions via virtualization. Alternatively, hardware 904 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 910, which, among others, oversees lifecycle management of applications 902. In some embodiments, hardware 904 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 912 which may alternatively be used for communication between hardware nodes and radio units.

[0241] FIGURE 13 illustrates an example method 1000 by a first radio node 402, 502, according to certain embodiments. In the illustrated embodiment, the method includes a transmitting step at 1002, a receiving step at 1004, and a using step at 1006. For example, at step 1002, the first radio node 402, 502 may transmit, to a second radio node 404, 504, a list of at least one reference model identified s) associated with a first part model that is associated with a feature. At step 1004, the first radio node 402, 502may receive, from the second radio node 404, 504, an indication of a selected reference model identifier from the list of the at least one reference model identified s). At step 1006, the first radio node 402, 502may use, at the first radio node402, 502, an associated first part model that is associated with the selected reference model identifier indicated by the second radio node 404, 504.

[0242] FIGURE 14 illustrates an example method 1100 by a second radio node 404, 504, according to certain embodiments. In the illustrated embodiment, the method includes a receiving step at 1102 and a transmitting step at 1104. For example, at step 1102, the second radio node 404, 504 may receive, from a first radio node 402, 502, a list of at least one reference model identified s) associated with a first part model that is associated with a feature. At step 1104, the second radio node 404, 504 may transmit, to the first radio node 402, 502, an indication of a selected reference model identifier from the list of the at least one reference model identifier(s), the selected reference model identifier associated with a first part model to be used at the first radio node 402, 502.

[0243] FIGURE 15 illustrates another example method 1200 by a first radio node 402, 502, according to certain embodiments. In the illustrated embodiment, the method includes a receiving step at 1202 and a using step at 1204. For example, at step 1202, the first radio node 402, 502 may receive, from the second radio node 404, 504, an indication of a selected reference model identifier associated with a first part model that is associated with a feature. At step 1204, the first radio node 402, 502 may use, at the first radio node 402, 502, an associated first part model that is associated with the selected reference model identifier indicated by the second radio node 404, 504.

[0244] FIGURE 16 illustrates another example method 1300 by a second radio node 404, 504, according to certain embodiments. In the illustrated embodiment, the method includes a transmitting step at 1302. For example, at step 1302, the second radio node 404, 504 may transmit, to the first radio node 402, 502, an indication of a selected reference model identifier associated with a first part model that is associated with a feature.

[0245] FIGURE 17 illustrates an example method 1400 by a first radio node 402, 502 for using a first part Al model, according to certain embodiments. The method begins when, at step 1402, the first radio node 402, 502 receives, from a second radio node 404, 504 an indication of one or more selected reference model identifier(s), and each selected reference model identifier identifies one or more first part Al model(s) associated with a feature. Alternatively, the first radio node 402, 502 receives an indication of no first part Al model is selected. At step 1404, the first radio node 402, 502 uses a first part Al model identified by the one or more selected reference model identified s) indicated by the second radio node, or falling back to a non-AI algorithm if the indication from the second node indicates that no first part Al model is selected.

[0246] In a particular embodiment, the first radio node is a UE and the second radio node is a network node. Alternatively, the first radio node is a network node and the second radio node is a UE.

[0247] In a particular embodiment, a Part A of the first part Al model is stored at the first radio node, and a Part B of the first part Al model is received by the first radio node from the second radio node.

[0248] In a particular embodiment, the first part Al model is a one-side model and inference is performed entirely at the first radio node using a Part A and a Part B of the first part Al model. Alternatively, the first part Al model is part of a two-sided model, and a first part of inference is performed by the first radio node using a Part A and a Part B of the first part Al model of the two- sided model, and a second part of inference is performed by the second radio node using a Part A and a Part B of a second part Al model of the two-sided model.

[0249] In a particular embodiment, the Part A of the first part Al model and / or the second part Al model is an architecture and / or structure of the first part Al model and / or the second part Al model, and the Part B of the first part Al model and / or the second part Al model is a set of parameters for the first part Al model and / or the second part Al model.

[0250] In a particular embodiment, at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model is a reference model part.

[0251] In a particular embodiment, the reference model part is specified in a standard, and / or the reference model part contains a standardized training dataset and / or a standardized testing dataset.

[0252] In a particular embodiment, at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model is configurable.

[0253] In a particular embodiment, each of the reference model part is assigned a unique reference model identifier. In a particular embodiment, the first radio node sends at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model to the second radio node. Alternatively, the first radio node receives at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second Al part model, and the Part B of the second part Al model from the second radio node.

[0254] In a particular embodiment, at least one of the Part A and the Part B of the first part Al model and / or the second part Al model are at least a portion of an encoder, and the other of the Part A and the Part B of the first part Al model and / or the second part Al model are at least a portion of a decoder.

[0255] In a particular embodiment, the first radio node 402, 502 transmits, to the second radio node, capability information indicating a capability of the first radio node 402, 502 for the first part Al model.

[0256] In a particular embodiment, the first radio node 402, 502 transmits, to the second radio node 404, 504, a list of reference model identifiers identifying the first part Al model stored at the first radio node.

[0257] In a particular embodiment, the first radio node 402, 502 receives, from the second radio node 404, 504, a request for reference model identifiers stored at the first radio node, and the list of reference model identifiers is transmitted to the second radio node 404, 504 based on the request.

[0258] In a particular embodiment, the first radio node 402, 502 receives, from the second radio node 404, 504, an indication of at least one configuration and / or condition for the first part Al model, and wherein the list of reference model identifiers is transmitted to the second radio node 402, 502 based on the indication.

[0259] In a particular embodiment, the first radio node 402, 502 compares the one or more selected reference model identifier(s), which identifies the one or more first part Al model(s), to a list of a plurality of reference model identifiers identifying a plurality of first part Al models stored at the first radio node 402, 502. The first radio node 402, 502 determines that at least one of the selected one or more reference model identified s) matches at least one reference model identifier in the list of the reference model identifiers for the plurality of first part Al models stored at the first radio node 402, 502.

[0260] In a particular embodiment, the first radio node 402, 502 transmits, to the second radio node 404, 504, information indicating that at least one of the selected one or more reference model identified s) matches the at least one reference model identifier in the list of the reference model identifiers for the plurality of first part Al models stored at the first radio node 402, 502. FIGURE 18 illustrates a method 1500 by a second radio node 404, 504 for using a first part Al-model, according to certain embodiments. As depicted the method begins at step 1502 when the second radio node 404, 504 transmits, to a first radio node 402, 502, an indication of one or more selected reference model identifier(s), and each selected reference model identifier identifying one or more first part model(s) that is / are associated with a feature. Alternatively, the second radio node 404, 504 transmits an indication of no first part Al model is selected.

[0261] In a particular embodiment, the first radio node 404, 504 is a UE and the second radio node 406, 506 is a network node. Alternatively, the first radio node 404, 504 is a network node and the second radio node 406, 506 is a UE.

[0262] In a particular embodiment, a Part A of the first part Al model is stored at the first radio node 404, 504, and a Part B of the first part Al model is transmitted to the first radio node 404, 504 by the second radio node 406, 506.

[0263] In a particular embodiment, the first part Al model is a one-sided model and inference is performed entirely at the first radio node 404, 504 using a Part A and a Part B of the first part Al model. Alternatively, the first part Al model is part of a two-sided model, and a first part of inference is performed by the first radio node 404, 504 using a Part A and a Part B of the first part Al model of the two-sided model, and a second part of inference is performed by the second radio node 406, 506 using a Part A and a Part B of a second part Al model of the two-sided model.

[0264] In a particular embodiment, the Part A of the first Al model and / or the second part Al model is an architecture and / or structure of the first part Al model and / or the second part Al model, and the Part B of the first part Al model and / or the second part Al model is a set of parameters for the first part Al model and / or the second part Al model.

[0265] In a particular embodiment, at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model is a reference model part.

[0266] In a particular embodiment, the reference model part is specified in a standard, and / or the reference model part contains a standardized training dataset and / or a standardized testing dataset.

[0267] In a particular embodiment, at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model is configurable.

[0268] In a particular embodiment, each of the reference model part is assigned a unique reference model identifier.

[0269] In a particular embodiment, the first radio node 404, 504 sends at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model to the second radio node 406, 506. Alternatively, the first radio node receives at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second Al part model, and the Part B of the second part Al model from the second radio node.

[0270] In a particular embodiment, one of the Part A and the Part B of the first part Al model and / or the second part Al model are at least a portion of an encoder, and the other one of the Part A and the Part B of the first part Al model and / or the second part Al model are at least a portion of a decoder.

[0271] In a particular embodiment, the second radio node 406, 506 receives, from the first radio node 404, 504, capability information indicating a capability of the first radio node 404, 504 for the first part Al model.

[0272] In a particular embodiment, the second radio node 406, 506 receives, from the first radio node 404, 504, a list of reference model identifiers identifying the first part Al model stored at the first radio node.

[0273] In a particular embodiment, the second radio node 406, 506 transmits, to the first radio node 404, 504, a request for reference model identifiers stored at the first radio node 404, 504, and the list of reference model identifiers is transmitted to the second radio node 406, 506 based on the request.

[0274] In a particular embodiment, the second radio node 406, 506 transmits, to the first radio node 404, 504, an indication of at least one configuration and / or condition for the first part Al model, and the list of reference model identifiers is transmitted to the second radio node 406, 506 based on the indication.

[0275] In a particular embodiment, the second radio node 406, 506 determines and / or obtains at least one condition for a plurality of first part Al models stored at the first radio node 404, 504 for the feature. The second radio node 406, 506 selects a subset of the plurality of stored first part Al models based on the at least one condition. The indication of one or more selected reference model identifier(s) transmitted to the first radio node 404, 504 comprises only the reference model identifiers for the subset of the plurality of stored first part Al models.

[0276] In a particular embodiment, the second radio node 406, 506 receives, from the first radio node 404, 504, information indicating that the selected reference model identifier matches at least one reference model identifier for the one or more first part Al models stored at the first radio node. Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0277] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0278] EXAMPLE EMBODIMENTS

[0279] Group A Example Embodiments Example Embodiment Al. A method by a user equipment comprising: any of the user equipment steps, features, or functions described above, either alone or in combination with other steps, features, or functions described above.

[0280] Example Embodiment A2. The method of the previous embodiment, further comprising one or more additional user equipment steps, features or functions described above.

[0281] Example Embodiment A3. The method of any of the previous embodiments, further comprising: providing user data; and forwarding the user data to a host computer via the transmission to the network node.

[0282] Group B Example Embodiments

[0283] Example Embodiment B 1. A method performed by a network node comprising: any of the network node steps, features, or functions described above, either alone or in combination with other steps, features, or functions described above.

[0284] Example Embodiment B2. The method of the previous embodiment, further comprising one or more additional network node steps, features or functions described above.

[0285] Example Embodiment B3. The method of any of the previous embodiments, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

[0286] Group C Example Embodiments

[0287] Example Embodiment Cl. A method by a first radio node for obtaining, training, and / or using a paired Al-model, the method comprising: transmitting, to a second radio node, a list of at least one reference model identifier(s) associated with a first part model that is associated with a feature; receiving, from the second radio node, an indication of a selected reference model identifier from the list of the at least one reference model identified s); and using, at the first radio node, an associated first part model that is associated with the selected reference model identifier indicated by the second radio node.

[0288] Example Embodiment C2. The method of Example Embodiment Cl, wherein the first radio node is a UE and the second radio node is a network node.

[0289] Example Embodiment C3. The method of Example Embodiment Cl, wherein the first radio node is a network node and the second radio node is a UE.

[0290] Example Embodiment C4. The method of any one of Example Embodiments Cl to C3, comprising transmitting, to the second radio node, capability information indicating a capability of the first radio node for the paired Al model.

[0291] Example Embodiment C5. The method of any one of Example Embodiments Cl to C4, comprising receiving, from the second radio node, a configuration associated with the paired Al model.

[0292] Example Embodiment C6. The method of any one of Example Embodiments Cl to C5, comprising receiving, from the second radio node, a request for reference model identifiers stored at the first radio node.

[0293] Example Embodiment C7. The method of any one of Example Embodiments Cl to C6, comprising: determining and / or obtaining at least one performance condition and / or application condition for a plurality of stored first-part models for the feature; and selecting a subset of the plurality of stored first part models based on at least one performance and / or application condition; and wherein the list of at least one reference model identified s) transmitted to the second radio node comprises only the reference model identifier(s) that are associated with the subset of the plurality of stored first part models.

[0294] Example Embodiment C8. The method of any one of Example Embodiments Cl to C7, wherein receiving, from the second radio node, the indication of the selected reference model identifier from the list of the at least one reference model identifier(s) comprises: receiving an index of the selected reference model identifier(s).

[0295] Example Embodiment C9. The method of any one of Example Embodiment Cl to C8, wherein a Part A of the paired Al model is stored at the first radio node and a Part B of the paired Al model is stored at the second radio node.

[0296] Example Embodiment CIO. The method of any one of Example Embodiments Cl to C8, wherein the paired Al model comprises a two-sided model, wherein the first radio node stores Part A and Part B of the paired Al model, and wherein the second radio node stores Part A and Part B of the paired Al model.

[0297] Example Embodiment Cl 1. The method of any one of Example Embodiments C9 to CIO, wherein the first radio node sends at least one of the Part A and the Part B of the paired Al model to the second radio node.

[0298] Example Embodiment C12.The method of any one of Example Embodiments C9 to CIO, wherein the first radio node receives at least one of the Part A and the Part B of the paired Al model from the second radio node.

[0299] Example Embodiment Cl 3. The method of any one of Example Embodiments C9 to Cl 2, wherein at least one of the Part A and the Part B are at least a portion of an encoder.

[0300] Example Embodiment C14.The method of any one of Example Embodiments C9 to C13, wherein at least one of the Part A and the Part B are at least a portion of a decoder.

[0301] Example Embodiment Cl 5. The method of any one of Example Embodiments C9 to Cl 4, wherein at least one of the Part A and the Part B are a architecture and / or structure of the paired Al model.

[0302] Example Embodiment Cl 6. The method of any one of Example Embodiments C9 to Cl 5, wherein at least one of the Part A and the Part B are a set of parameters for the paired Al model.

[0303] Example Embodiment Cl 7. The method of any one of Example Embodiments Cl to Cl 6, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node.

[0304] Example Embodiment Cl 8. The method of any one of Example Embodiments Cl to Cl 6, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

[0305] Example Embodiment Cl 9. A first radio node comprising processing circuitry configured to perform any of the methods of Example Embodiments Cl to Cl 8.

[0306] Example Embodiment C20. A first radio node configured to and / or adapted to perform any of the methods of Example Embodiments Cl to Cl 8.

[0307] Example Embodiment C21. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Cl to Cl 8.

[0308] Example Embodiment C22. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Cl to Cl 8.

[0309] Example Embodiment C23. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments Cl to Cl 8.

[0310] Group D Example Embodiments

[0311] Example Embodiment DI. A method by a second radio node for obtaining, training, and / or using a paired Al-model, the method comprising: receiving, from a first radio node, a list of at least one reference model identified s) associated with a first part model that is associated with a feature; transmitting, to the first radio node, an indication of a selected reference model identifier from the list of the at least one reference model identified s), the selected reference model identifier associated with a first part model to be used at the first radio node.

[0312] Example Embodiment D2. The method of Example Embodiment DI, wherein the first radio node is a UE and the second radio node is a network node.

[0313] Example Embodiment D3. The method of Example Embodiment DI, wherein the first radio node is a network node and the second radio node is a UE.

[0314] Example Embodiment D4. The method of any one of Example Embodiments DI to D3, comprising receiving, from the first radio node, capability information indicating a capability of the first radio node for the paired Al model.

[0315] Example Embodiment D5. The method of any one of Example Embodiments DI to D4, comprising transmitting, to the first radio node, a configuration associated with the paired Al model.

[0316] Example Embodiment D6. The method of any one of Example Embodiments DI to D5, comprising transmitting, to the first radio node, a request for reference model identifiers stored at the first radio node.

[0317] Example Embodiment D7. The method of any one of Example Embodiments DI to D6, wherein transmitting, to the first radio node, the indication of the selected reference model identifier from the list of the at least one reference model identifier(s) comprises: transmitting an index of the selected reference model identifier(s).

[0318] Example Embodiment D8. The method of any one of Example Embodiment DI to D7, wherein a Part A of the paired Al model is stored at the first radio node and a Part B of the paired Al model is stored at the second radio node.

[0319] Example Embodiment D9. The method of any one of Example Embodiments DI to D7, wherein the paired Al model comprises a two-sided model, wherein the first radio node stores Part A and Part B of the paired Al model, and wherein the second radio node stores Part A and Part B of the paired Al model.

[0320] Example Embodiment DIO. The method of any one of Example Embodiments D8 to D9, wherein the first radio node sends at least one of the Part A and the Part B of the paired Al model to the second radio node.

[0321] Example Embodiment Dl l. The method of any one of Example Embodiments D8 to D9, wherein the first radio node receives at least one of the Part A and the Part B of the paired Al model from the second radio node.

[0322] Example Embodiment D12. The method of any one of Example Embodiments D8 to Dl l, wherein at least one of the Part A and the Part B are at least a portion of an encoder.

[0323] Example Embodiment D13. The method of any one of Example Embodiments D8 to DI 2, wherein at least one of the Part A and the Part B are at least a portion of a decoder.

[0324] Example Embodiment D14. The method of any one of Example Embodiments D8 to D13, wherein at least one of the Part A and the Part B are a architecture and / or structure of the paired Al model.

[0325] Example Embodiment DI 5. The method of any one of Example Embodiments D8 to DI 4, wherein at least one of the Part A and the Part B are a set of parameters for the paired Al model. Example Embodiment DI 6. The method of any one of Example Embodiments DI to DI 5, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node.

[0326] Example Embodiment DI 7. The method of any one of Example Embodiments DI to DI 5, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

[0327] Example Embodiment D18. A second radio node comprising processing circuitry configured to perform any of the methods of Example Embodiments DI to DI 7.

[0328] Example Embodiment DI 9. A second radio node configured to and / or adapted to perform any of the methods of Example Embodiments DI to DI 7.

[0329] Example Embodiment D20. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments DI to DI 7.

[0330] Example Embodiment D21. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments DI to DI 7.

[0331] Example Embodiment D22. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments DI to DI 7.

[0332] Group E Example Embodiments

[0333] Example Embodiment El. A method by a first radio node for obtaining, training, and / or using a paired Al-model, the method comprising: receiving, from the second radio node, an indication of a selected reference model identifier associated with a first part model that is associated with a feature; and using, at the first radio node, an associated first part model that is associated with the selected reference model identifier indicated by the second radio node.

[0334] Example Embodiment E2. The method of Example Embodiment El, wherein the first radio node is a UE and the second radio node is a network node.

[0335] Example Embodiment E3. The method of Example Embodiment El, wherein the first radio node is a network node and the second radio node is a UE.

[0336] Example Embodiment E4. The method of any one of Example Embodiments El to E3, comprising transmitting, to the second radio node, capability information indicating a capability of the first radio node for the paired Al model.

[0337] Example Embodiment E5. The method of any one of Example Embodiments El to E4, comprising receiving, from the second radio node, a configuration associated with the paired Al model. Example Embodiment E6. The method of any one of Example Embodiments El to E5, comprising: receiving, from the second radio node, a request for reference model identifiers stored at the first radio node; and transmitting to the second radio node, a list of reference model identifiers associated with model parts stored at the first radio node.

[0338] Example Embodiment E7. The method of any one of Example Embodiments El to E6, comprising: comparing the selected reference model identifier associated with the first part model to a list of a plurality of reference model identifiers associated with a plurality of first part models stored at the first radio node; and determining that the selected reference model identifier matches at least one reference model identifier in the list of the reference model identifiers for model parts stored at the first radio node.

[0339] Example Embodiment E8. The method of Example Embodiment E7, comprising transmitting, to the second radio node, information indicating that the selected reference model identifier matches the at least one reference model identifier in the list of the reference model identifiers for model parts stored at the first radio node.

[0340] Example Embodiment E9. The method of any one of Example Embodiment El to E8, wherein a Part A of the paired Al model is stored at the first radio node and a Part B of the paired Al model is stored at the second radio node.

[0341] Example Embodiment E10. The method of any one of Example Embodiments El to E8, wherein the paired Al model comprises a two-sided model, wherein the first radio node stores Part A and Part B of the paired Al model, and wherein the second radio node stores Part A and Part B of the paired Al model.

[0342] Example Embodiment El 1. The method of any one of Example Embodiments E9 to E10, wherein the first radio node sends at least one of the Part A and the Part B of the paired Al model to the second radio node.

[0343] Example Embodiment E12. The method of any one of Example Embodiments E9 to E10, wherein the first radio node receives at least one of the Part A and the Part B of the paired Al model from the second radio node.

[0344] Example Embodiment E13. The method of any one of Example Embodiments E9 to E12, wherein at least one of the Part A and the Part B are at least a portion of an encoder.

[0345] Example Embodiment E14. The method of any one of Example Embodiments E9 to E13, wherein at least one of the Part A and the Part B are at least a portion of a decoder.

[0346] Example Embodiment E15. The method of any one of Example Embodiments E9 to E14, wherein at least one of the Part A and the Part B are a architecture and / or structure of the paired Al model. Example Embodiment E16. The method of any one of Example Embodiments E9 to E15, wherein at least one of the Part A and the Part B are a set of parameters for the paired Al model.

[0347] Example Embodiment E17. The method of any one of Example Embodiments El to E16, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node.

[0348] Example Embodiment E18. The method of any one of Example Embodiments El to E16, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

[0349] Example Embodiment E19. A first radio node comprising processing circuitry configured to perform any of the methods of Example Embodiments El to E18.

[0350] Example Embodiment E20. A first radio node configured to and / or adapted to perform any of the methods of Example Embodiments El to E18.

[0351] Example Embodiment E21. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments El to E18.

[0352] Example Embodiment E22. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments El to E18.

[0353] Example Embodiment E23. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments El to El 8.

[0354] Group F Example Embodiments

[0355] Example Embodiment Fl. A method by a second radio node for obtaining, training, and / or using a paired Al-model, the method comprising: transmitting, to the first radio node, an indication of a selected reference model identifier associated with a first part model that is associated with a feature.

[0356] Example Embodiment F2. The method of Example Embodiment Fl, wherein the first radio node is a UE and the second radio node is a network node.

[0357] Example Embodiment F3. The method of Example Embodiment Fl, wherein the first radio node is a network node and the second radio node is a UE.

[0358] Example Embodiment F4. The method of any one of Example Embodiments Fl to F3, comprising receiving, from the first radio node, capability information indicating a capability of the first radio node for the paired Al model.

[0359] Example Embodiment F5. The method of any one of Example Embodiments Fl to F4, comprising transmitting, to the first radio node, a configuration associated with the paired Al model.

[0360] Example Embodiment F6. The method of any one of Example Embodiments Fl to F5, comprising: transmitting, to the first radio node, a request for reference model identifiers stored at the first radio node; and receiving, from the first radio node, a list of reference model identifiers associated with model parts stored at the first radio node.

[0361] Example Embodiment F7. The method of any one of Example Embodiments Fl to F6, comprising: determining and / or obtaining at least one performance condition and / or application condition for a plurality of first-part models stored at the first radio node for the feature; and selecting a subset of the plurality of stored first part models based on at least one performance and / or application condition; and wherein the list of at least one reference model identifier(s) transmitted to the first radio node comprises only the reference model identifier(s) that are associated with the subset of the plurality of stored first part models.

[0362] Example Embodiment F8. The method of any one of Example Embodiments Fl to F7, comprising receiving, from the first radio node, information indicating that the selected reference model identifier matches at least one reference model identifier associated with a model part stored at the first radio node.

[0363] Example Embodiment F9. The method of any one of Example Embodiment Fl to F8, wherein a Part A of the paired Al model is stored at the first radio node and a Part B of the paired Al model is stored at the second radio node.

[0364] Example Embodiment Fl 0. The method of any one of Example Embodiments Fl to F8, wherein the paired Al model comprises a two-sided model, wherein the first radio node stores Part A and Part B of the paired Al model, and wherein the second radio node stores Part A and Part B of the paired Al model.

[0365] Example Embodiment Fl 1. The method of any one of Example Embodiments F9 to F10, wherein the first radio node sends at least one of the Part A and the Part B of the paired Al model to the second radio node.

[0366] Example Embodiment F 12. The method of any one of Example Embodiments F9 to F10, wherein the first radio node receives at least one of the Part A and the Part B of the paired Al model from the second radio node.

[0367] Example Embodiment F 13. The method of any one of Example Embodiments F9 to Fl 2, wherein at least one of the Part A and the Part B are at least a portion of an encoder.

[0368] Example Embodiment F 14. The method of any one of Example Embodiments F9 to F13, wherein at least one of the Part A and the Part B are at least a portion of a decoder.

[0369] Example Embodiment Fl 5. The method of any one of Example Embodiments F9 to Fl 4, wherein at least one of the Part A and the Part B are a architecture and / or structure of the paired Al model.

[0370] Example Embodiment Fl 6. The method of any one of Example Embodiments F9 to Fl 5, wherein at least one of the Part A and the Part B are a set of parameters for the paired Al model.

[0371] Example Embodiment Fl 7. The method of any one of Example Embodiments Fl to Fl 6, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node.

[0372] Example Embodiment Fl 8. The method of any one of Example Embodiments Fl to F16, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment.

[0373] Example Embodiment Fl 9. A second radio node comprising processing circuitry configured to perform any of the methods of Example Embodiments Fl to Fl 8.

[0374] Example Embodiment F20. A second radio node configured to and / or adapted to perform any of the methods of Example Embodiments Fl to Fl 8.

[0375] Example Embodiment F21. A computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Fl to Fl 8.

[0376] Example Embodiment F22. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the methods of Example Embodiments Fl to Fl 8.

[0377] Example Embodiment F23. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the methods of Example Embodiments Fl to Fl 8.

[0378] Group G Example Embodiments

[0379] Example Embodiment Gl. A user equipment comprising: processing circuitry configured to perform any of the steps of any of the Group A, C, D, E, and F Example Embodiments; and power supply circuitry configured to supply power to the processing circuitry.

[0380] Example Embodiment G2. A network node comprising: processing circuitry configured to perform any of the steps of any of the Group B, C, D, E, and F Example Embodiments; power supply circuitry configured to supply power to the processing circuitry.

[0381] Example Embodiment G3. A user equipment (UE): an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A, C, D, E, and F Example Embodiments; an input interface connected to the

Claims

processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE.CLAIMS1. A method (1400) by a first radio node (402, 502) for using a first part Al model, the method comprising: receiving (1402), from a second radio node (404, 504): an indication of one or more selected reference model identified s), wherein each selected reference model identifier identifies one or more first part Al model(s) associated with a feature, or an indication of no first part Al model is selected; and using (1404), at the first radio node, a first part Al model identified by the one or more selected reference model identifier(s) indicated by the second radio node, or falling back to a non- AI algorithm if the indication from the second node indicates that no first part Al model is selected.

2. The method of Claim 1, wherein: the first radio node is a UE and the second radio node is a network node, or the first radio node is a network node and the second radio node is a UE.

3. The method of any one of Claims 1 to 2, wherein: a Part A of the first part Al model is stored at the first radio node, and a Part B of the first part Al model is received by the first radio node from the second radio node.

4. The method of any one of Claims 1 to 2, wherein: the first part Al model is a one-side model and inference is performed entirely at the first radio node using a Part A and a Part B of the first part Al model; or the first part Al model is part of a two-sided model and a first part of inference is performed by the first radio node using a Part A and a Part B of the first part Al model of the two-sided model, and a second part of inference is performed by the second radio node using a Part A and a Part B of a second part Al model of the two-sided model.

5. The method of any one of Claims 3 to 4, wherein: the Part A of the first part Al model and / or the second part Al model is an architecture and / or structure of the first part Al model and / or the second part Al model, and the Part B of the first part Al model and / or the second part Al model is a set of parameters for the first part Al model and / or the second part Al model.

6. The method of any one of Claims 3 to 5, wherein at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model is a reference model part.

7. The method of Claim 6, wherein at least one of: the reference model part is specified in a standard, and the reference model part contains a standardized training dataset and / or a standardized testing dataset.

8. The method of any one of Claims 3 to 7, wherein at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model is configurable.

9. The method of any one of Claims 3 to 8, wherein each of the reference model part is assigned a unique reference model identifier.

10. The method of any one of Claims 3 to 9, wherein: the first radio node sends at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model to the second radio node, or the first radio node receives at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second Al part model, and the Part B of the second part Al model from the second radio node.

11. The method of any one of Claims 3 to 10, wherein: at least one of the Part A and the Part B of the first part Al model and / or the second part Al model are at least a portion of an encoder, and the other of the Part A and the Part B of the first part Al model and / or the second part Al model are at least a portion of a decoder.

12. The method of any one of Claims 1 to 11, comprising transmitting, to the second radio node, capability information indicating a capability of the first radio node for the first part Al model.

13. The method of any one of Claims 1 to 12, comprising transmitting, to the second radio node, a list of reference model identifiers identifying the first part Al model stored at the first radio node.

14. The method of Claim 13, comprising receiving, from the second radio node, a request for reference model identifiers stored at the first radio node, and wherein the list of reference model identifiers is transmitted to the second radio node based on the request.

15. The method of any one of Claims 13 to 14, comprising receiving, from the second radio node, an indication of at least one configuration and / or condition for the first part Al model, and wherein the list of reference model identifiers is transmitted to the second radio node based on the indication.

16. The method of any one of Claims 1 to 15, comprising: comparing the one or more selected reference model identifier(s) identifying the one or more first part Al model(s) to a list of a plurality of reference model identifiers identifying a plurality of first part Al models stored at the first radio node; and determining that at least one of the selected one or more reference model identified s) matches at least one reference model identifier in the list of the reference model identifiers for the plurality of first part Al models stored at the first radio node.

17. The method of Claim 16, comprising transmitting, to the second radio node, information indicating that at least one of the selected one or more reference model identifier(s) matches the at least one reference model identifier in the list of the reference model identifiers for the plurality of first part Al models stored at the first radio node.

18. A method (1500) by a second radio node (404, 504) for using a first part Al-model, the method comprising: transmitting (1502), to a first radio node (402, 502): an indication of one or more selected reference model identified s), wherein each selected reference model identifier identifying one or more first part model(s) that is / are associated with a feature, or an indication of no first part Al model is selected.

19. The method of Claim 18, wherein: the first radio node is a UE and the second radio node is a network node, or the first radio node is a network node and the second radio node is a UE.

20. The method of any one of Claims 18 to 19, wherein: a Part A of the first part Al model is stored at the first radio node, and a Part B of the first part Al model is transmitted to the first radio node by the second radio node.

21. The method of any one of Claims 18 to 20, wherein: the first part Al model is a one-sided model and inference is performed entirely at the first radio node using a Part A and a Part B of the first part Al model, or the first part Al model is part of a two-sided model and a first part of inference is performed by the first radio node using a Part A and a Part B of the first part Al model of the two-sided model and a second part of inference is performed by the second radio node using a Part A and a Part B of a second part Al model of the two-sided model.

22. The method of any one of Claims 20 to 21, wherein: the Part A of the first Al model and / or the second part Al model is an architecture and / or structure of the first part Al model and / or the second part Al model, and the Part B of the first part Al model and / or the second part Al model is a set of parameters for the first part Al model and / or the second part Al model.

23. The method of any one of Claims 20 to 22, wherein at least one of the Part A of the first part Al model , the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model is a reference model part.

24. The method of Claim 23, wherein at least one of: the reference model part is specified in a standard, and the reference model part contains a standardized training dataset and / or a standardized testing dataset.

25. The method of any one of Claims 20 to 24, wherein at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model is configurable.

26. The method of any one of Claims 20 to 25, wherein each of the reference model part is assigned a unique reference model identifier.

27. The method of any one of Claims 20 to 26, wherein: the first radio node sends at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second part Al model, and the Part B of the second part Al model to the second radio node, or the first radio node receives at least one of the Part A of the first part Al model, the Part B of the first part Al model, the Part A of the second Al part model, and the Part B of the second part Al model from the second radio node.

28. The method of any one of Claims 20 to 27, wherein:one of the Part A and the Part B of the first part Al model and / or the second part Al model are at least a portion of an encoder, and the other one of the Part A and the Part B of the first part Al model and / or the second part Al model are at least a portion of a decoder.

29. The method of any one of Claims 18 to 28, comprising receiving, from the first radio node, capability information indicating a capability of the first radio node for the first part Al model.

30. The method of any one of Claims 18 to 29, comprising receiving, from the first radio node, a list of reference model identifiers identifying the first part Al model stored at the first radio node.

31. The method of Claim 30, comprising transmitting, to the first radio node, a request for reference model identifiers stored at the first radio node, and wherein the list of reference model identifiers is transmitted to the second radio node based on the request.

32. The method of any one of Claims 30 to 31, comprising transmitting, to the first radio node, an indication of at least one configuration and / or condition for the first part Al model, and wherein the list of reference model identifiers is transmitted to the second radio node based on the indication.

33. The method of any one of Claims 28 to 29, comprising: determining and / or obtaining at least one condition for a plurality of first part Al models stored at the first radio node for the feature; and selecting a subset of the plurality of stored first part Al models based on the at least one condition; and wherein the indication of one or more selected reference model identifier(s) transmitted to the first radio node comprises only the reference model identifiers for the subset of the plurality of stored first part Al models.

34. The method of any one of Claims 18 to 33, comprising receiving, from the first radio node, information indicating that the selected reference model identifier matches at least one reference model identifier for the one or more first part Al models stored at the first radio node.

35. A first radio node (402, 502) for using a first part Al model, the first radio node configured to: receive (1402), from a second radio node (404, 504): an indication of one or more selected reference model identifier(s), wherein each selected reference model identifier identifies one or more first part Al model(s) that is / are associated with a feature, or an indication of no first part Al model is selected; and