Multi-model signaling method for ran
By splitting the ML model into common blocks and private blocks, and sending common block indication information based on pre-configuration criteria, the problem of high signaling overhead for multi-model models is solved, and the efficiency of model migration and lifecycle management is improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- OMOWE GMBH
- Filing Date
- 2024-11-29
- Publication Date
- 2026-07-21
AI Technical Summary
In wireless communication systems, multi-model signaling overhead is high, especially when multiple models are activated between a base station and multiple user equipment. Existing technologies lack effective signaling methods to manage model migration and lifecycle management operations.
The ML model is split into a common model block and a specific model block. The specific model block is determined only for the associated ML model. The applicability of the common model block is evaluated through pre-configured criteria and thresholds. The indication information of the common model block is sent to reduce signaling overhead.
By splitting the model block structure, the signaling overhead of multiple models is reduced, the efficiency of model migration and lifecycle management is improved, and the signaling burden between the network and user equipment is reduced.
Smart Images
Figure CN122439338A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to AI / ML-based model information sharing, in which techniques are proposed for pre-configuring and signaling specific information about model structure / properties. Background Technology
[0002] Within 3GPP (3rd Generation Partnership Project), one of the selected research projects as part of the approved Release 18 package is AI / ML (Artificial Intelligence / Machine Learning), as described in the relevant document (RP-213599) submitted at 3GPP TSG (Technical Specification Group) RAN (Radio Access Networks) meeting #94e. The formal title of the AI / ML research project is "Studyon AI / ML for NR Air Interface," and currently, RAN WG1 (Working Group 1) and WG2 are actively developing specifications. The goal of this research project is to establish a common AI / ML framework and areas where AI / ML-based technologies and use cases can yield benefits. According to 3GPP, the primary objective of this research project is to study an AI / ML framework for the air interface by considering performance, complexity, and potential specification impacts from target use cases. In particular, AI / ML models, terminology, and descriptions used to establish common and specific characteristics of the framework will be one of the key areas of work. Regarding the AI / ML framework, investigations are being considered from various aspects, and one of the key projects is the lifecycle management of AI / ML models, which mandates multiple phases including model training, deployment, inference, monitoring, and updates. Earlier, in 3GPP TR 37.817 (Release 17), titled "Study on enhancement for Data Collection for NR and EN-DC," UE (User Equipment) mobility was also considered as an AI / ML use case, and one scenario for model training / inference was that both functions resided within the RAN node. Subsequently, a new work project, "Artificial Intelligence (AI) / Machine Learning (ML) for NG-RAN," was launched in Release 18 to specify data collection enhancements and signaling support within the existing NG-RAN interface and architecture. Regarding the aforementioned positive standardization efforts, model identifiers (e.g., model IDs) used to support RAN-based AI / ML models are considered crucial for both the network and the UE to meet any desired model operations (e.g., model training, inference, selection, switching, updating, monitoring, etc.). Model ID information can be signaled to pair the network-side model and the UE-side model for various lifecycle management (LCM) operations.
[0003] US2020374711A1 describes a representation of a local model of a first data endpoint of a radio access network having multiple common models for endpoints of the radio access network, selecting one of the multiple common models for the first data endpoint, and sending the selected common model to the first data endpoint, any other data endpoint utilizing the selected common model, or any other external system.
[0004] US2021097428A1 describes a method for adapting a deep learning model to a local environment, wherein training data is collected and a public deep learning model is trained, and the deep learning model is customized based on a feature specific to one of a plurality of local devices that utilize transfer learning.
[0005] WO2022003949A1 describes a machine learning model trained using training data, where a classifier is configured to classify input data and output output data.
[0006] WO2022073167A1 describes a wireless communication method that receives a configuration message via Radio Resource Control (RRC) signaling, because the configuration message includes parameters of an artificial neural network and also includes a common configuration of basic set signaling.
[0007] However, multi-model signaling overhead can be very high when multiple models need to be activated in parallel at the UE, especially when multiple UEs have multiple models on their own devices for activation between the base station (BS / gNB) and multiple UEs. Currently, there are no specifications for signaling methods and network-UE behavior known to manage multi-model-based model migration and / or other related model signaling overhead for LCM operations.
[0008] According to a first aspect, this disclosure relates to a multi-model signaling method for a RAN, wherein a model block structure having a model common block and a model private block for ML models is configured within a wireless communication system, the method comprising: configuring an ML model to split into two blocks as a model common block and a model private block; determining, for multiple models, model common blocks to be shared and / or paired across different models; determining, only for associated ML models, model private blocks to be uniquely configured; and setting pre-configured criteria, wherein specific thresholds can be used to evaluate the applicability of the model common blocks across multiple ML models.
[0009] In some embodiments, the method according to the first aspect may further include one or more of the following optional features, either individually or in any technically possible combination.
[0010] In some embodiments of the method according to the first aspect, the method is characterized in that the model block is further divided into smaller blocks, such as sub-blocks under the model common block and the model private block.
[0011] In some embodiments of the method according to the first aspect, the method is characterized in that, depending on the different properties used as criteria for block-based ML model splitting, a limited number of sub-blocks are configured to be contained in the model common block and / or model private block.
[0012] In some embodiments of the method according to the first aspect, the method is characterized in that, when sending ML configuration to the UE, indication information about the model common block is sent together with the associated model ID, such that the model common block is applied to the indicated multiple models.
[0013] In some embodiments of the method according to the first aspect, the method is characterized in that index-based indication information can be sent to apply model common blocks to multiple ML models.
[0014] In some embodiments of the method according to the first aspect, the method is characterized in that, depending on different implementation use cases, the model common block and the model private block can be part of the model structure, architecture, layout, functionality, etc. For example, a model common block can be predefined to indicate specific portions of the generally applicable model structure / parameter set information for models across different UEs, while a model private block can be predefined to indicate specific portions of the model structure / parameter set information for associated models applicable only to a UE. In other words, the information contained in the model common block and the model private block can be predefined on the network side for deployment based on different combinations of model-related configuration information associated with the model application.
[0015] In some embodiments of the method according to the first aspect, the method is characterized in that, depending on the application, such as a functional group, a sub-model group, or a parameter group / layer group, the model common block can be many different forms of applicable models based on the model structure and / or model characteristics.
[0016] In some embodiments of the method according to the first aspect, the method is characterized in that a specific configuration for selecting the nature of the model common block can be pre-set by the network side for different model applications or deployment scenarios.
[0017] In some embodiments of the method according to the first aspect, the method is characterized in that the model common block can be configured independently and applied to all applicable ML models, wherein the pre-configured model common block can be sent to the UE or known in advance by the UE.
[0018] In some embodiments of the method according to the first aspect, the method is characterized in that a limited number of candidate model common blocks applicable to any ML model can be set and pre-configured, and indication information about specific candidate model common blocks available for use can be sent.
[0019] In some embodiments of the method according to the first aspect, the method is characterized in that a particular model can be determined as a reference model having a common block of models, including: migrating multiple other models together with the determined reference model; and applying the indicated reference model to the multiple migrated models for activation.
[0020] According to a second aspect, this disclosure relates to a wireless device including at least one memory and at least one processor configured to perform a method according to any one of the embodiments of the first aspect.
[0021] According to a third aspect, this disclosure relates to a user equipment (UE) that includes a wireless means according to any of the embodiments of this disclosure.
[0022] According to a fourth aspect, this disclosure relates to a base station (BS) including at least one memory and at least one processor configured to perform a method according to any one of the embodiments of the first aspect.
[0023] According to a fifth aspect, this disclosure relates to a wireless communication system including at least one base station according to any one of the embodiments of this disclosure and at least one user equipment according to any one of the embodiments of this disclosure.
[0024] According to a sixth aspect, this disclosure relates to a computer program product comprising instructions that, when executed by at least one processor, configure the at least one processor to perform a method according to a first aspect, the at least one processor being configured to perform a method for exchanging data according to any one of the embodiments of this disclosure. The computer program product may use any programming language and may be in the form of source code, object code, or any intermediate form between source code and object code, such as a partially compiled form, or any other desired form.
[0025] According to a sixth aspect, this disclosure relates to a computer-readable storage medium including instructions that, when executed by at least one processor, configure the at least one processor to perform a method according to any one of the embodiments of this disclosure. Attached Figure Description
[0026] Figure 1 This is an exemplary block diagram of the ML model block structure.
[0027] Figure 2 This is an exemplary block diagram of an ML model block type.
[0028] Figure 3 This is an exemplary block diagram of multiple ML models with a model block structure.
[0029] Figure 4 This is an exemplary block diagram of assigning common blocks of models to multiple ML models.
[0030] Figure 5 This is an exemplary block diagram for migrating multiple ML models with a model block structure.
[0031] Figure 6 This is an exemplary flowchart for applying network-side behavior of ML model blocks.
[0032] Figure 7 This is an exemplary flowchart for applying ML model blocks to the UE-side behavior.
[0033] Figure 8 This is an exemplary signaling flow that applies the ML model block when the activation decision is made on the UE side.
[0034] Figure 9 This is an exemplary signaling flow that applies ML model blocks when activation decisions are made on the network side. Detailed Implementation
[0035] The specific embodiments described below with reference to the accompanying drawings are intended as a description of various configurations and are not intended to represent only configurations in which the concepts described herein can be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. Specifically, although the embodiments described herein may be exemplified using terminology from 3GPP 5G NR in this disclosure, this should not be construed as limiting the scope of the invention.
[0036] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are also included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.
[0037] Generally, all terms used herein should be interpreted according to their ordinary meaning in the relevant art, unless a different meaning is expressly given and / or implied in the context of their use. Unless otherwise expressly stated, all references to elements, apparatus, components, means, steps, etc., should be openly interpreted as referring to at least one instance of that element, apparatus, component, means, step, etc. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step, and / or it implies that a step must follow or precede another step. Where appropriate, any feature of any embodiment in the embodiments disclosed herein may be applied to any other embodiment. Similarly, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the appended embodiments will become apparent from the following description.
[0038] In some embodiments, the more general term "network node" may be used, and this term may correspond to any type of radio network node or any network node that communicates with the UE (directly or via another node) and / or with another network node. Examples of network nodes are NodeB, MeNB, ENB, network nodes belonging to MCG or SCG, base station (BS), multi-standard radio (MSR) radio nodes (such as MSR BS), eNodeB, gNodeB, network controller, radio network controller (RNC), base station controller (BSC), repeater, donor node controlling repeater, base transceiver station (BTS), access point (AP), transport point, transport node, RRU, RRH, nodes in distributed antenna system (DAS), core network nodes (e.g., mobile switching center (MSC), mobility management entity (MME), etc.), operations and maintenance (O&M), operations support system (OSS), self-optimizing network (SON), location node (e.g., evolved servicing mobile location center (E-SMLC)), minimized drive test (MDT), test equipment (physical node or software), etc.
[0039] In some embodiments, the non-limiting terms User Equipment (UE) or Wireless Device may be used, and the term may refer to any type of wireless device that communicates with a network node and / or with another UE in a cellular or mobile communication system. Examples of UEs are target devices, device-to-device (D2D) UEs, machine-type UEs or UEs capable of machine-to-machine (M2M) communication, PDAs, PADs, tablet computers, mobile terminals, smartphones, laptop embedded devices (LEE), laptop mounted devices (LME), USB dongles, UE class M1, UE class M2, ProSe UE, V2V UE, V2X UE, etc.
[0040] Additionally, terms such as base station / gNodeB and UE should be considered non-restrictive and, in particular, do not imply any hierarchical relationship between the two; generally, "gNodeB" can be considered device 1 and "UE" can be considered device 2, and the two devices communicate with each other via a radio channel. Furthermore, in the following text, a transmitter or receiver can be either a gNodeB (gNB) or a UE.
[0041] As those skilled in the art will understand, aspects of the embodiments can be embodied as systems, apparatus, methods, or program products. Therefore, embodiments can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects.
[0042] For example, the disclosed embodiments can be implemented as hardware circuitry, including custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors (such as logic chips, transistors, or other discrete components). The disclosed embodiments can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, procedures, or functions.
[0043] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices, which store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In one embodiment, the storage device uses only signals to access the code.
[0044] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor systems, apparatuses, or any suitable combination thereof.
[0045] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires; portable computer floppy disks; hard disks; random access memory (“RAM”); read-only memory (“ROM”); erasable programmable read-only memory (“EPROM” or flash memory); portable optical disc read-only memory (“CD-ROM”); optical storage devices; magnetic storage devices; or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store programs for use by or in conjunction with an instruction execution system, apparatus, or device.
[0046] The code used to perform the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages (such as Python, Ruby, Java, Smalltalk, C++, etc.), as well as conventional procedural programming languages (such as the "C" programming language, etc.) and / or machine languages (such as assembly language). The code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network (including a local area network ("LAN"), a wireless LAN ("WLAN"), or a wide area network ("WAN"), or can be connected to an external computer (e.g., via the Internet through an Internet service provider ("ISP").
[0047] Furthermore, the features, structures, or characteristics described in the embodiments can be combined in any suitable manner. Numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided in the following description to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that those embodiments can be practiced without one or more specific details or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments. References to “an embodiment,” “embodiment,” or similar language throughout the specification mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Therefore, unless expressly stated otherwise, the phrases “in one embodiment,” “in an embodiment,” and similar language appearing throughout the specification may, but not necessarily all, refer to the same embodiment, but rather mean “one or more, but not all, embodiments.” Unless expressly stated otherwise, the terms “comprising,” “including,” “having,” and variations thereof mean “including, but not limited to,” “including.” Unless expressly stated otherwise, the enumeration of items does not imply that any or all of the items are mutually exclusive. Unless otherwise expressly specified, the terms “a,” “an,” and “the” also refer to “one or more.”
[0048] The following description of aspects of embodiments is based on schematic flowcharts and / or block diagrams of methods, apparatus, systems, and program products according to embodiments. It should be understood that each block of the schematic flowcharts and / or block diagrams, and combinations of blocks in the schematic flowcharts and / or block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment to produce machinery, such that instructions executable via the processor of the computer or other programmable data processing equipment create means for implementing the functions / actions specified in the flowcharts and / or block diagrams.
[0049] The code may also be stored in a storage device that can instruct a computer, other programmable data processing equipment or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of writing including instructions that implement the functions / actions specified in the flowchart and / or block diagram.
[0050] The code can also be loaded onto a computer, other programmable data processing equipment or other device, such that a series of operational steps to be performed on the computer, other programmable equipment or other device produce a computer-implemented process, and that the code executing on the computer or other programmable equipment provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.
[0051] The flowcharts and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function.
[0052] It should also be noted that in some alternative implementations, the functions indicated in the boxes may not occur in the order shown in the diagram. For example, depending on the functionality involved, two boxes shown consecutively may actually be executed substantially concurrently, or the boxes may sometimes be executed in reverse order. Other steps and methods that are functionally, logically, or effectically equivalent to one or more boxes or portions thereof shown in the diagram can be envisioned.
[0053] While various arrow and line types may be used in flowcharts and / or block diagrams, they are not intended to limit the scope of the corresponding embodiments. In practice, some arrows or other connecting symbols may be used to indicate only the logical flow of the depicted embodiment. For example, arrows may indicate waiting or monitoring periods of unspecified duration between enumerated steps of the depicted embodiment. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, may be implemented by a system based on dedicated hardware or a combination of dedicated hardware and code that performs the specified function or action.
[0054] The description of the elements in each figure can be referenced to the elements in the preceding figures. The same numbers in all figures refer to the same elements, including alternative embodiments of the same elements.
[0055] The detailed description set forth below with reference to the accompanying drawings is intended as a description of various configurations and is not intended to represent the only configuration in which the concepts described herein can be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. For example, although 3GPP terms from, for example, 5G NR may be used in this disclosure to exemplify embodiments herein, this should not be considered as limiting the scope of this disclosure.
[0056] Generally, all terms used herein should be interpreted according to their ordinary meaning in the relevant art, unless a different meaning is expressly given and / or implied in the context of their use. Unless otherwise expressly stated, all references to elements, apparatus, components, means, steps, etc., should be openly interpreted as referring to at least one instance of that element, apparatus, component, means, step, etc. Furthermore, the order of steps in any method disclosed herein, particularly in the figures, is provided for illustrative purposes only and is not intended to limit the disclosure. The disclosure may apply where the same steps are performed in a different order and / or where steps are performed in parallel or in combination, unless a step is explicitly described as occurring after or before another step and / or where it is implied that a step must occur after or before another step. Moreover, in a figure, steps enclosed by dashed lines should be considered optional for the embodiment represented in that figure. Where appropriate, any feature of any embodiment disclosed herein may be applied to any other embodiment. Similarly, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the appended embodiments will become apparent from the following description.
[0057] This disclosure relates to a wireless communication system, which may be, for example, a 5G NR wireless communication system. More specifically, it refers to a RAN (Radio Access Network) within the wireless communication system for exchanging data with a UE via radio signals. For example, the RAN may transmit data (downlink DL) to the UE, such as data received from the core network (CN). The RAN may also receive data from the UE (uplink UL), which may be forwarded to the CN.
[0058] In the example shown, the RAN includes a base station (BS). Of course, the RAN can include more than one BS to increase the coverage of the wireless communication system. Depending on the implemented wireless communication standard, each of these BSs can be called an NB, eNodeB (or eNB), gNodeB (or gNB, in the case of a 5G NR wireless communication system), access point, etc.
[0059] The UE is located within the coverage area of the BS. The coverage area of the BS corresponds, for example, to the region where the UE can decode the PDCCH sent by the BS.
[0060] Examples of wireless devices suitable for implementing any of the methods discussed in this disclosure at the UE correspond to equipment that provides wireless connectivity to a RAN of a wireless communication system and can be used to exchange data with that RAN. Such wireless devices can be included in the UE. The UE can be, for example, a cellular phone, a wireless modem, a wireless communication device, a handheld device, a laptop computer, etc. The UE can also be an Internet of Things (IoT) device, such as a wireless camera, a smart sensor, a smart meter, smart glasses, a (manned or unmanned) vehicle, a GPS device, etc., or any other device capable of running applications that require exchanging data with a remote receiver via a wireless device.
[0061] The wireless device includes one or more processors and one or more memories. The one or more processors may include, for example, a central processing unit (CPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc. The one or more memories may include any type of computer-readable volatile and non-volatile memory (magnetic hard disk, solid-state drive, optical disk, electronic storage, etc.). The one or more memories may store a computer program product in the form of a set of program code instructions to be executed by the one or more processors to implement the steps of a method for exchanging data at the UE side according to any of the embodiments disclosed herein.
[0062] The wireless device may also include a main radio (MR) unit. The MR unit corresponds to the main wireless communication unit of the wireless device, which is used to exchange data with the BS of the RAN using radio signals. The MR unit can implement one or more wireless communication protocols and can be, for example, a 3G, 4G, 5G, NR, WiFi, WiMax, or other transceivers. In a preferred embodiment, the MR unit corresponds to a 5G NR wireless communication unit.
[0063] The following explanation will provide a detailed description of the mechanism for pre-configuring AI / ML-based models prior to the handover in a wireless mobile communication system that includes base stations (e.g., gNBs) and mobile stations (e.g., UEs).
[0064] The AI / ML lifecycle can be broken down into several phases, such as data collection / preprocessing, model training, model testing / validation, model deployment / update, model monitoring, and model switching / selection, each of which is equally important for achieving the target performance of any particular model. One of the challenging issues when applying AI / ML models to any use case or application is managing the AI / ML model lifecycle. This is primarily because data / model drift occurs during model deployment / inference, leading to performance degradation. Fundamentally, dataset statistics change after model deployment, and the model's inference capabilities are also affected by the unseen data as input. Similarly, the statistical properties of the dataset and the relationship between the input and output of the trained model can change with drift. Model adaptation is then needed to support operations such as model switching, retraining, and rollback. When deploying wireless communication networks that enable AI / ML models, it is important to consider how to handle AI / ML model adaptation during operations such as model training, inference, monitoring, and updates.
[0065] The applicability of ML for LCM (Lifecycle Management) operations can vary significantly depending on the use case and the nature of the environment, depending on the specific network-UE ML collaboration in the deployment scenario (e.g., UE mobility scenarios). AI / ML-based technologies are currently being applied to many different applications, and based on observed potential benefits, 3GPP has also begun its technology research for application in multiple applications.
[0066] Similarly, the statistical properties of a dataset and the relationship between the input and output of a trained model can change as drift occurs. In this context, model performance, such as inference and / or training, depends on different model execution environments with different configuration parameters.
[0067] To address this issue, collaboration between the UE and gNBs is crucial for tracking model performance and reconfiguring models to suit different environments across the UE and different gNBs. When deploying wireless communication networks that support AI / ML models, it is then important to consider how to handle AI / ML models during activation and reconfiguration for wireless devices under operations such as model training, inference, and updates. In other words, by pre-configuring any model during operations with different gNBs such as master nodes (MNs) and slave nodes (SNs), the performance impact can be minimized compared to using any single connection link for model operations.
[0068] In this method, UE connections to multiple gNBs (such as MNs and SNs based on Primary Cell Groups (MCGs) and Secondary Cell Groups (SCGs)) are enabled to support distributed multi-model operations activated across MNs and / or SNs, allowing ML model signaling exchange resulting from LCM-based model operations to be distributed across one or more SNs. First, the MN informs candidate SNs of the ML configuration and LCM-based model information. To trigger distributed multi-model operations, multiple conditions (e.g., pre-configured metrics or thresholds) can exist, such as when actual traffic load increases under current cell conditions, and / or when additional model operations are required via a separate link (e.g., SN-UE) running in parallel with the activated link (e.g., MN-UE). After SN connection setup, the configured model requested by the MN (e.g., LCM operations in the MN-UE link) can be replicated in the SN-UE link for activation. Alternatively, individually configured model operations can be activated in the SN-UE link upon request from the MN.
[0069] The following explanation will provide a detailed description of the mechanism for using the association between models and index values to pre-configure and signal specific information about model selection.
[0070] AI / ML technologies are currently being applied to many different applications, and based on observed potential benefits, 3GPP has also begun its technology research for application in multiple applications. The AI / ML lifecycle can be broken down into several stages, such as data collection / preprocessing, model training, model testing / validation, model deployment / update, and model monitoring, each of which is equally important for achieving the target performance of any particular model.
[0071] One of the challenging issues when applying AI / ML models to any use case or application is managing the lifecycle of the AI / ML model. This is primarily because data / model drift occurs during model deployment / inference, leading to performance degradation of the AI / ML model. Fundamentally, dataset statistics change after model deployment, and the model's inference capabilities are also affected by the unseen data as input. Similarly, the statistical properties of the dataset and the relationship between the inputs and outputs of the trained model can change with drift. In this context, model selection is one of the key issues in maintaining model performance, as model performance, such as inference and / or training, depends on different model execution environments with varying configuration parameters. To address this issue, collaboration between the UE and gNB is crucial for tracking model performance and reconfiguring models for different environments. Since model performance cannot be sustained continuously due to drift, AI / ML models require model monitoring after deployment, followed by providing update feedback for retraining / updating the model or selecting an alternative model. When deploying a wireless communication network supporting AI / ML models, it is then important to consider how to handle AI / ML models during activation and reconfiguration for wireless devices under operations such as model training, inference, and updates. In the case of multiple AI / ML models used in parallel for different LCM operations on a UE device or across multiple UEs, the signaling overhead and increased computational power for model migration / delivery and / or model retraining / update can both be quite significant. In this approach, each ML model is identified as being split into two blocks, such as a common model block and a dedicated model block, where the common model block can be shared and / or paired with other ML models, and the dedicated model block is uniquely configured only for its associated ML model. As an example, for the common model block, it is a portion of the ML model that can be used for other ML models based on pre-configured criteria, where specific thresholds can be used to evaluate the applicability of the common model block across multiple ML models, as the thresholds are configured based on a similarity metric. Alternatively, the common model block can be configured independently and applied to all applicable ML models, where the pre-configured common model block can be sent to the UE or known in advance by the UE. In this case, when sending indication information about specific candidate common model blocks available for use, a limited number of candidate common model blocks applicable to any ML model may exist to be set and pre-configured, if necessary. In terms of implementation, depending on the different implementation use cases, model common blocks and model-specific blocks can be part of the model structure, architecture, layout, functionality, etc. When different ML models used across multiple applications on multiple UEs and / or devices use model common blocks, index-based indication information can be sent to apply the model common blocks to multiple ML models, where the index can be pre-configured by the network side.For example, if a model common block is valid for an application with any particular ML model, an index value is configured for the model common block indicating the ML model, causing other ML models to reference the configured index indicating the specific model common block, and then the indexed model common block is applied to multiple ML models. The main benefit of doing this is that the model common block is sent once and applied to multiple ML models across multiple applications and / or multiple UEs. Otherwise, each ML model would need to be sent separately, including the common parts that can be used for multiple models. In other respects, when the common parts of an ML model for multiple models can be pre-configured for a UE using an index-based indication, the common parts can be saved for signaling overhead. When sending the indication information for the model common block of an ML model, a list of all associated model IDs needs to be sent together so that the identified models can be indicated to apply the indexed model common block across different models where applicable. Alternatively, the network side performs model migration for multiple models, such as three models M1, M2, and M3. If these models share a common part of each model (e.g., a sub-model), then when an instruction for indexing information is received, the UE will apply the indexed sub-model (configured by the network side) to those three models.
[0072] Figure 1 An exemplary block diagram of an ML model block structure is shown. In this example, the ML model can be structured to be split into common model blocks and model-specific blocks, where block-level partitioning can be based on different properties, such as layer groups, sub-model groups, model functionality / parameter groups, etc. Depending on the characteristics of the ML model, either common model blocks or model-specific blocks may be unavailable. For example, a model may only have model-specific blocks.
[0073] Figure 2 An exemplary block diagram of ML model block types is shown. In this example, the model block can be further subdivided into smaller blocks, such as sub-blocks under the model common block and model private block. Depending on the different properties used as criteria for block-based ML model splitting, a limited number of sub-blocks can be configured to be included in the model common block / model private block.
[0074] Figure 3An exemplary block diagram of multiple ML models with a model block structure is shown. In this example, with a finite number of ML models, a common model block is configured for all models. Different models may have different model sizes and / or complexities, and the common model block is typically included in K different models. Therefore, for model migration / delivery of those K different models, it is not necessary to send the common model block separately for each model, as it can be reused across all models by sharing. As an example, a specific model can be identified as a reference model with a common model block, such that it is sent along with other multi-model migration information, and the indicated reference model is applied to the other migrated models for activation.
[0075] Figure 4 An exemplary block diagram is shown, illustrating the assignment of model common blocks to multiple ML models. In this example, depending on the application, such as functional groups, sub-model groups, parameter groups / layer groups, etc., the model common blocks can be many different forms of applicable models based on model structure and / or model characteristics. Specific configurations for selecting the nature of the model common blocks can be pre-set by the network side for different model applications or deployment scenarios.
[0076] Figure 5 An exemplary block diagram is shown for migrating multiple ML models with a model block structure. In this example, there are two independent ML models, and a common model block applicable to both models is identified. When migrating these two models over the air, the identified common model block is sent along with the model-specific block for each model. It is not necessary to send the common model block separately for each model migration, as it can be copied after reception. The benefit of reduced signaling overhead can be quite significant as the number of ML models with common model blocks increases.
[0077] Figure 6 An exemplary flowchart for the network-side behavior of applying ML model blocks is shown. On the network side, an ML configuration with a model block structure is set up for all applicable models to determine the model common blocks and model-specific blocks for each model. Specific thresholds can be used to identify model common blocks across different models based on pre-configured criteria such as similarity metrics. When the ML configuration is sent to the UE, indication information about the model common blocks is sent along with the associated model ID, allowing the model common blocks to be applied to the indicated multiple models.
[0078] Figure 7 An exemplary flowchart of UE-side behavior for applying ML model blocks is shown. On the UE side, multiple ML models can exist for parallel activation, and identified common model blocks, indicated by the network side, can be applied to the models for activation if valid.
[0079] Figure 8An exemplary signaling flow for applying an ML model block when activation decisions are made on the UE side is illustrated. In this example, a model common block is determined to be applicable to multiple models based on auxiliary information received from the network side regarding ML configuration. Criteria for determining the model common block (such as thresholds) can be provided in advance by the network side. After applying the model common block, an instruction message regarding activating the applied model common block is sent to the network side, allowing both sides to align for ML reconfiguration. General ML configuration information can be sent via system information or RRC signaling. Model block-related information can be sent via L1 / L2 or L3 signaling.
[0080] Figure 9 An exemplary signaling flow for applying ML model blocks when activation decisions are made on the network side is illustrated. In this example, on the network side, a model common block is determined to be applicable to multiple models based on auxiliary information received from the UE side regarding the ML configuration. When the ML configuration is sent to the UE, indication information regarding the model common block is sent along with the associated model ID, allowing the model common block to be applied to the indicated multiple models.
Claims
1. A method for multi-model signaling in a RAN, wherein a model block structure having model common blocks and model private blocks for ML models is configured within a wireless communication system, the method comprising: • Configure the ML model to split it into two blocks: a common block for the model and a private block for the model. • Identify common blocks of models that should be shared and / or paired across different models for multiple models; • Determine the model-specific block to be uniquely configured only for the associated ML model; • Set up pre-configured criteria, where specific thresholds can be used to evaluate the applicability of model common blocks across multiple ML models.
2. The method of claim 1, wherein the model block is further divided into smaller blocks, such as sub-blocks under the model common block and the model private block.
3. The method according to any one of the preceding claims, wherein a limited number of sub-blocks are configured to be contained in the model common block and / or model special block, depending on the different properties used as criteria for block-based ML model splitting.
4. The method according to any one of the preceding claims, wherein when ML configuration is sent to the UE, indication information about the model common block is sent together with the associated model ID, such that the model common block is applied to the indicated multiple models.
5. The method according to claim 4, wherein index-based indication information can be sent to apply model common blocks to multiple ML models.
6. The method according to any one of the preceding claims, wherein, depending on the different implementation use cases, the model common block and the model private block can be part of the model structure and / or architecture and / or layout, functionality.
7. The method according to any one of the preceding claims, wherein, depending on the application, such as functional groups and / or sub-model groups and / or parameter groups / layer groups, the model common blocks have different forms of applicable models based on model structure and / or model characteristics.
8. The method according to any one of the preceding claims, wherein the network side pre-configures specific settings for selecting the properties of common blocks of the model for different model applications or deployment scenarios.
9. The method according to any one of the preceding claims, wherein the model common block can be independently configured and applied to all applicable ML models, wherein the pre-configured model common block can be sent to the UE or known in advance by the UE.
10. The method according to any one of the preceding claims, wherein a finite number of candidate model common blocks applicable to any ML model can be set and pre-configured, and instruction information regarding a specific candidate model common block available for use is sent.
11. The method according to any one of the preceding claims, wherein a particular model can be determined as a reference model having common blocks of models, comprising: • Migrate multiple other models together with the determined reference model; • Apply the indicated reference model to several other migrated models for activation.
12. A wireless device comprising at least one memory and at least one processor, said at least one processor being configured to perform the method according to any one of the preceding claims.
13. A user equipment (UE) comprising the wireless means according to claim 12.
14. A base station (BS) comprising at least one memory and at least one processor, said at least one processor being configured to perform the method according to any one of claims 1 to 11.
15. A wireless communication system comprising at least one base station as claimed in claim 14 and at least one user equipment as claimed in claim 12.
16. A computer program product comprising instructions that, when executed by at least one processor, configure the at least one processor to perform the method according to any one of claims 1 to 11.
17. A computer-readable storage medium comprising instructions that, when executed by at least one processor, configure the at least one processor to perform the method (40) according to any one of claims 1 to 11.