Method for gnb-UE behavior for model-based mobility

Abstract

The present disclosure describes a method of pre-configuring an AI / ML-based model prior to a handover occurring in a wireless mobile communication system including a base station (e.g., a gNB) and a mobile station (e.g., a UE). Model performance, such as reasoning and / or training, depends on different model execution environments with different configuration parameters when applying the AI / ML model in a radio access network. Thus, by pre-reconfiguring any model in operation for the source gNB, the performance impact caused by UE mobility can be minimized when making the target gNB connection.

Description

Technical Field

[0001] The present disclosure relates to AI / ML based model pre-configuration, wherein techniques are proposed for reconfiguring and signaling specific information to avoid model performance degradation due to UE mobility. Background Art

[0002] In December 2021, the 3GPP (Third Generation Partnership Project) approved its Release-18 technology package, and one of the selected research items was AI / ML (artificial intelligence / machine learning), as described in the relevant document (RP-213599) discussed at 3GPP TSG (Technical Specification Group) RAN (Radio Access Network) meeting #94e. The AI / ML research item is officially titled "Study on AI / ML for NR Air Interface," and RAN Working Group 1 (WG1) and WG2 are currently actively developing specifications. The goal of this research item is to define a common AI / ML framework and identify areas where AI / ML-based technologies can benefit from using use cases. From a radio access network perspective, one of the key areas of scope is to identify various levels of collaboration between base stations (BS / gNB) and user equipment (UE).

[0003] According to 3GPP, the primary objective of this study project is to investigate an AI / ML framework for the air interface, targeting targeted use cases, by considering performance, complexity, and potential regulatory impact. Specifically, key areas of work include AI / ML models, terminology, and descriptions to determine common and specific characteristics of the framework. Various aspects of the AI / ML framework are being considered, and one key area of ​​research is the lifecycle management of AI / ML models, encompassing 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 mobility was also considered as an AI / ML use case, with one scenario involving model training and inference where both functions reside within the RAN node. Subsequently, in Release 18, a new work item “Artificial Intelligence (AI) / Machine Learning (ML) for NG-RAN” was initiated to specify enhancements to data collection and signaling support within the existing NG-RAN interfaces and architecture, with mobility optimization listed as one of the target tasks.

[0004] For the aforementioned ongoing standardization work, support for RAN-based AI / ML models with UE mobility can be considered critical, ensuring that both the gNB and UE meet any desired model operations (e.g., model training / inference / selection / handover / update / monitoring, etc.) when the UE is mobile. Currently, there are no defined signaling methods or gNB-UE behavior specifications for UE mobility when operating RAN-based AI / ML models. Therefore, it is necessary to investigate any regulatory impacts by considering model operations during UE mobility. Any mechanisms for additional signaling methods and / or gNB-UE behavior to support mobility-based model operations between the gNB and UE will also need to be addressed, thereby minimizing any potential impact of UE mobility on model operations in the RAN and ensuring service continuity.

[0005] On the other hand, in 3GPP, the terminology of the work list includes a set of high-level descriptions regarding AI / ML model training, inference, verification, testing, UE-side model, network-side model, single-sided model, and dual-sided model. UE-side model and network-side model indicate that the AI / ML model operates on the UE side and the network side, respectively. In a similar context, single-sided model and dual-sided model indicate that the AI / ML model is located on one side and on both sides, respectively.

[0006] As the terminology is still under discussion and subject to further revision, not all aspects of signaling to support the above items have been specified at this time. Any potential impact on the standard of new or enhanced mechanisms to support AI / ML models using the above work list items is one of the key areas of investigation within the AI / ML research project.

[0007] WO 2022034259 describes a network device that enables reception as part of a handover procedure for handing over a terminal to the network device.

[0008] WO 2022058020 describes measures for evaluating and controlling predictive machine learning models in mobile networks.

[0009] WO 2022199824 describes a method of establishing a first wireless access radio link between a first access node and a wireless device.

[0010] WO 2022258196 describes an apparatus for receiving a machine learning model for predicting handover parameters.

[0011] WO 2021123285 includes a description of determining, based on an output of a model, that a communication device should perform a handover to establish a connection in a second cell.

[0012] WO 2021259492 describes a method for training a machine learning model in a first node of a communication network, the method comprising receiving a first message comprising instructions for training the machine learning model using a distributed learning process. Summary of the Invention

[0013] The features of claims 1 to 28 solve the problem at hand.

[0014] The pre-configured model operation for connecting to the target gNB is determined for the UE in advance, before UE mobility is performed, minimizing the impact of UE mobility on any model performance. This means that the impact of UE mobility on model performance degradation is reduced, and the signaling overhead associated with model operation is reduced.

[0015] According to a first aspect, the present disclosure relates to a method for gNB-UE behavior for model-based mobility using a pre-configured AI / ML model based on either full pre-configuration or partial pre-configuration, wherein for the full pre-configured AI / ML model, the reconfiguration model is fully loaded to the UE before handover is performed, and for the partial pre-configuration of the AI / ML model, the reconfiguration model is partially loaded to the UE before handover is performed.

[0016] In some embodiments of the method according to the first aspect, the method is characterized in that the determination to transmit the complete or partial model pre-configuration information is based on a network / UE specific criterion.

[0017] In some embodiments of the method according to the first aspect, the method is characterized in that the network / UE specific criteria are UE ML capability status and / or model type and / or function, and / or network data traffic status and / or model-based service application.

[0018] In some embodiments of the method according to the first aspect, the method is characterized in that the source gNB obtains model operation status updates from the UE by means of device model state information signaling, thereby obtaining the latest information about the UE model operation and thus performing any required model reconfiguration between the gNB and the UE.

[0019] In some embodiments of the method according to the first aspect, the method is characterized in that the device model state information includes classified data types, such as model operation mode state and / or model training state and / or model inference state and / or model update state and / or model monitoring state and / or model ID and / or ML capability state, and the structure of the device model state information is flexibly configured or sub-classified through RRC signaling, and the device model state information is sent from the UE to the gNB through PUCCH / PUSCH or MAC CE.

[0020] In some embodiments of the method according to the first aspect, the method is characterized in that the UE preloads the reconfiguration model in advance based on signaling of model preconfiguration information received from the source gNB for the new connection with the target gNB.

[0021] In some embodiments of the method according to the first aspect, the method is characterized in that the model pre-configuration information includes, for example, model configuration parameters, model ID, model transfer type, and model lifecycle type, wherein the model pre-configuration information is sent from the gNB to the UE via PDCCH / PDSCH or MAC CE.

[0022] In some embodiments of the method according to the first aspect, the method is characterized in that the model pre-configuration information can be structured into multiple partitions so that partial / block reconfiguration can be applied to preloading like full reconfiguration.

[0023] In some embodiments of the method according to the first aspect, the method is characterized in that, based on the content of the model pre-configuration information, the content can be divided into common attributes and UE-specific attributes, so that any combination of model pre-configuration information can be provided to the UE when necessary.

[0024] In some embodiments of the method according to the first aspect, the method is characterized in that a superset of model pre-configuration information is maintained at the source gNB or network side.

[0025] In some embodiments of the method according to the first aspect, the method is characterized in that different levels of model reconfiguration are performed based on different conditions and environments in which the model operates.

[0026] In some embodiments of the method according to the first aspect, the method is characterized in that the necessity of UE model reconfiguration is determined according to the location of model activation (eg network side or UE side or both).

[0027] In some embodiments of the method according to the first aspect, the method is characterized in that the location of model activation is at the network side and / or the UE side.

[0028] In some embodiments of the method according to the first aspect, the method is characterized in that, for a model only on the network side, no UE model reconfiguration is performed, and assistance information signaling from the UE may still be required. A model reconfiguration request needs to be sent to the target gNB(s) or the network side.

[0029] In some embodiments of the method according to the first aspect, the method is characterized in that, for a model on the UE side only or a model on the network-UE side, a full or partial / blocked reconfiguration of the UE model is performed; when there is a model activation for reconfiguration on the network side, a model reconfiguration request will also be sent to the target gNB(s) or the network side.

[0030] In some embodiments of the method according to the first aspect, the method is characterized in that the source gNB determines a high-mobility UE by monitoring the mobility state of the UE, the high-mobility UE is instructed to perform model reconfiguration based on an AI / ML model repository from the network in preparation for handover to another target gNB, and the high-mobility UE is identified using mobility pattern information with historical measurement data.

[0031] In some embodiments of the method according to the first aspect, the method is characterized in that for high mobility UEs with pre-loaded model reconfiguration, a model deactivation timer is applied so that the burden on network and / or UE resources is reduced when no handover occurs.

[0032] In some embodiments of the method according to the first aspect, the method is characterized in that, upon expiration of the model deactivation timer, the high mobility UE not undergoing handover uninstalls the pre-configured model.

[0033] In some embodiments of the method according to the first aspect, the method is characterized in that, for general / normal handover situations, RRC reconfiguration performed through handover command signaling indicates target gNB information by triggering activation of a preconfigured model and, if necessary, additional model preconfiguration information, and after handover is confirmed, the preconfigured model is pre-activated to establish a connection with the target gNB.

[0034] In some embodiments of the method according to the first aspect, the method is characterized in that, for advanced handover cases (Conditional Handover CHO), in the source gNB, candidate target gNBs for UE connection are prioritized in advance such that any model-related signaling overhead and model impact based on UE mobility are minimized.

[0035] In some embodiments of the method according to the first aspect, the method is characterized in that the CHO-based RRC reconfiguration signaling indicates additional new information about additional model pre-configuration information associated with the priority list of the target gNB.

[0036] In some embodiments of the method according to the first aspect, the method is characterized in that, after the CHO condition is met, a pre-configuration model is pre-enabled to establish a connection with the target gNB.

[0037] In some embodiments of the method according to the first aspect, the method is characterized in that during UE mobility with model support, a set of resources needs to be reserved in the target gNB, and the source gNB maintains a priority list of target gNBs and associated model pre-configuration instructions to be signaled to high mobility UEs.

[0038] According to a second aspect, the present disclosure relates to a wireless device comprising at least one memory and at least one processor configured to perform the method according to any one of the embodiments of the first aspect.

[0039] According to a third aspect, the present disclosure relates to a user equipment (UE), which comprises a wireless device according to any one of the embodiments of the present disclosure.

[0040] According to a fourth aspect, the present disclosure relates to a base station BS, comprising at least one memory and at least one processor, wherein the at least one processor is configured to execute the method according to any one of the embodiments of the first aspect.

[0041] According to a fifth aspect, the present disclosure relates to a wireless communication system, which includes at least one base station as described in any one of the embodiments of the present disclosure and at least one user equipment as described in any one of the embodiments of the present disclosure.

[0042] According to a sixth aspect, the present 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 the method according to the first aspect, and configure the at least one processor to perform the method for exchanging data according to any one of the embodiments of the present disclosure. The computer program product may use any programming language and may be in the form of source code, object code, or any intermediate code between source code and object code, such as a partially compiled form, or any other desired form.

[0043] According to a seventh aspect, the present disclosure relates to a computer-readable storage medium comprising instructions which, 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 the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 An exemplary table showing the contents of device model status information.

[0045] Figure 2 The signaling process of device model status information is shown.

[0046] Figure 3 An exemplary table showing the contents of model pre-configuration information.

[0047] Figure 4 The signaling process of model pre-configuration information is shown.

[0048] Figure 5 Flowchart showing gNB behavior for the pre-configured model.

[0049] Figure 6 Flowchart showing UE behavior for the pre-configured model.

[0050] Figure 7 A block diagram illustrating multiple partitions of model provisioning information.

[0051] Figure 8 A flowchart of model reconfiguration on the UE side is shown.

[0052] Figure 9 A flowchart of model reconfiguration on the network side is shown.

[0053] Figure 10 A flow chart of UE mobility detection is shown.

[0054] Figure 11 A flow chart of UE mobility monitoring is shown.

[0055] Figure 12 The signaling flow of the pre-configuration model for a general handover case is shown.

[0056] Figure 13 The signaling flow of the pre-configured model for the conditional handover (CHO) case is shown. DETAILED DESCRIPTION

[0057] 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 may be practiced. The detailed description includes specific details to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In particular, although terminology from 3GPP 5G NR may be used in this disclosure to illustrate the embodiments herein, this should not be considered as limiting the scope of the invention.

[0058] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are also 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.

[0059] Generally, all terms used herein should be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or a different meaning is implied from the context of its use. Unless otherwise expressly stated, all references to one / a kind / this element, device, part, mode, step, etc. should be openly interpreted as referring to at least one instance of an element, device, part, mode, step, etc. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as being after or before another step and / or it is implied that a step must be after or before another step. Where appropriate, any feature of any embodiment disclosed herein may be applicable to any other embodiment. Similarly, any advantage of any embodiment may be applicable to any other embodiment, and vice versa. Based on the following description, other purposes, features and advantages of the attached embodiments will become apparent.

[0060] In some embodiments, the more general term "network node" may be used, which may correspond to any type of radio network node or any network node that communicates with a UE (directly or via another node) and / or communicates with another network node. Examples of network nodes are NodeB, MeNB, ENB, a network node belonging to an MCG or SCG, a base station (BS), a multi-standard radio (MSR) radio node (such as an MSR BS, eNodeB, gNodeB), a network controller, a radio network controller (RNC), a base station controller (BSC), a relay, a donor node controlled relay, a base transceiver station (BTS), an access point (AP), a transmission point, a transmission node, an RRU, an RRH, a node in a distributed antenna system (DAS), a core network node (such as a mobile switching center (MSC), a mobility management entity (MME), etc.), operations and maintenance (O&M), an operations support system (OSS), a self-optimizing network (SON), a positioning node (such as an evolved serving mobile positioning center (E-SMLC)), minimization of drive tests (MDT), test equipment (physical node or software), etc.

[0061] In some embodiments, the non-limiting term user equipment (UE) or wireless device may be used and may refer to any type of wireless device that communicates with a network node and / or 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 (LEEs), laptop mounted equipment (LMEs), USB dongles, M1 category UEs, M2 category UEs, ProSe UEs, V2V UEs, V2X UEs, and the like.

[0062] Furthermore, terms such as base station / gNodeB and UE should be considered non-restrictive and, in particular, do not imply a hierarchical relationship between the two. In general, a "gNodeB" can be considered device 1 and a "UE" can be considered device 2, communicating with each other over a radio channel. In the following, a transmitter or receiver can be either a gNodeB (gNB) or a UE.

[0063] As will be appreciated by those skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Thus, the embodiments may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects.

[0064] For example, the disclosed embodiments may be implemented as hardware circuits comprising custom very large scale integrated ("VLSI") circuits or gate arrays, off-the-shelf semiconductors (e.g., logic chips, transistors, or other discrete components). The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, and the like. As another example, the disclosed embodiments may comprise one or more physical or logical blocks of executable code, which blocks may be organized, for example, as objects, procedures, or functions.

[0065] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing 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-transmissive. The storage device may not embody signals. In certain embodiments, the storage device utilizes only signals to access the code.

[0066] Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable storage medium. The computer-readable storage medium may be a storage device that stores code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0067] More specific examples of storage devices (a non-exhaustive list) would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disk read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0068] The code for performing the operations of the embodiment 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++, and conventional procedural programming languages ​​such as the "C" programming language, 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 stand-alone 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 through 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 using an Internet Service Provider ("ISP")).

[0069] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details (e.g., examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc.) are provided to provide a thorough understanding of the embodiments. However, those skilled in the relevant art will recognize that the embodiments may be practiced without one or more of the specific details, or with 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. Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that at least one embodiment includes the specific features, structures, or characteristics described in connection with that embodiment. Therefore, unless expressly stated otherwise, the phrases "one embodiment," "an embodiment," and similar language throughout this specification may, but do not necessarily, refer to the same embodiment, but rather to "one or more, but not all, embodiments." Unless expressly stated otherwise, the terms "including," "comprising," "having," and variations thereof mean "including, but not limited to." The enumerated listing of items does not imply that any or all of the items are mutually exclusive unless expressly specified otherwise.The terms "a" and "an" and "the" also mean "one or more" unless expressly specified otherwise.

[0070] Various aspects of the embodiments are described below with reference to schematic flow charts and / or schematic block diagrams of methods, apparatuses, systems, and program products according to the embodiments. It should be understood that each block of the schematic flow charts and / or schematic block diagrams, as well as combinations of blocks in the schematic flow charts and / or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine, such that instructions executed by the processor of the computer or other programmable data processing device create means for implementing the functions / actions specified in the flow charts and / or block diagrams.

[0071] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other device to operate in a specific manner so that the instructions stored in the storage device produce an article of manufacture including instructions for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0072] The code may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the code executed on the computer or other programmable apparatus provides a process for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0073] The flowcharts and / or blocks in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, 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 for implementing the specified logical function(s).

[0074] It should also be noted that in some alternative implementations, the functions indicated in the blocks may not occur in the order indicated in the figures. For example, two blocks shown in succession may actually be executed substantially in parallel, or the blocks may sometimes be executed in the reverse order depending on the functions involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks or portions thereof in the illustrated figures.

[0075] Although various arrow types and line types may be used in the flowcharts and / or block diagrams, it should be understood that they do not limit the scope of the corresponding embodiments. In fact, some arrows or other connectors may be used only to indicate the logical flow of the depicted embodiments. For example, arrows can indicate waiting or monitoring periods of unspecified duration between the enumerated steps of the depicted embodiments. It should also be noted that each block of the block diagrams and / or flowcharts and the combination of blocks in the block diagrams and / or flowcharts can be implemented by a dedicated hardware-based system or a combination of dedicated hardware and code that performs the specified function or action.

[0076] The description of an element in each figure may refer to an element in a subsequent figure. In all figures, the same reference numerals refer to the same elements, including alternative embodiments of the same elements.

[0077] 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 configurations in which the concepts described herein may be practiced. The detailed description includes specific details to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. For example, although 3GPP terminology from, for example, 5G NR may be used in this disclosure to illustrate the embodiments herein, this should not be viewed as limiting the scope of this disclosure.

[0078] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is explicitly assigned and / or a different meaning is implied from the context of their use. Unless expressly stated otherwise, all references to an element, device, component, method, step, etc. are to be interpreted as referring to at least one instance of that element, device, component, method, step, etc. Furthermore, the order of steps in any method disclosed herein, and particularly in the accompanying drawings, is for illustrative purposes only and is not intended to limit the present disclosure. The present disclosure may apply to the same steps performed in a different order, and / or to all or part of the steps performed in parallel or in combination, unless a step is explicitly described as preceding or following another step and / or a step is implied to necessarily precede or follow another step. Furthermore, in the accompanying drawings, steps indicated by dashed lines are considered optional with respect to the embodiment depicted in that figure. Where appropriate, any feature of any embodiment disclosed herein may apply to any other embodiment. Similarly, any advantage of any embodiment may apply to any other embodiment, and vice versa. Other objects, features, and advantages of the accompanying embodiments will become apparent from the following description.

[0079] This disclosure relates to a wireless communication system, which may be, for example, a 5G NR wireless communication system. More specifically, it refers to the radio access network (RAN) of the wireless communication system, which is used to exchange data with user equipment (UEs) via radio signals. For example, the RAN may send data (downlink DL), such as data received from a core network (CN), to the UE. The RAN may also receive data (uplink UL) from the UE, which may be forwarded to the CN.

[0080] In the illustrated example, the RAN includes one base station (BS). Of course, the RAN may include more than one BS to increase the coverage of the wireless communication system. Depending on the implemented wireless communication standard(s), each of these BSs may be referred to as a NB, eNodeB (or eNB), gNodeB (or, in the case of a 5G NR wireless communication system, a gNB), access point, etc.

[0081] The UE is located within the coverage of the BS. For example, the coverage of the BS corresponds to an area in which the UE can decode the PDCCH transmitted by the BS.

[0082] An example of a wireless device suitable for implementing any of the methods discussed in this disclosure performed at a UE corresponds to an apparatus that provides a wireless connection to a wireless communication system's radio access network (RAN) and can be used to exchange data with the RAN. Such a wireless device can be included in a UE. For example, a UE can be a cellular phone, a wireless modem, a wireless communication device, a handheld device, a laptop computer, etc. A UE can also be an Internet of Things (IoT) device such as a wireless camera, a smart sensor, a smart meter, smart glasses, a vehicle (manned or unmanned), a Global Positioning System device, etc., or any other device that can run an application that requires exchanging data with a remote recipient via a wireless device.

[0083] 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 memory, etc.). The one or more memories may store a computer program product in the form of a set of program code instructions, which are executed by the one or more processors to implement all or part of the steps of the method for exchanging data performed on the UE side according to any of the embodiments disclosed herein.

[0084] The wireless device may also include a main radio (MR) unit. The MR unit corresponds to the wireless device's main wireless communication unit and is used to exchange data with a base station 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 transceiver. In a preferred embodiment, the MR unit corresponds to a 5G NR wireless communication unit.

[0085] The following explanation provides a detailed description of the mechanisms for pre-configuring AI / ML-based models before handover occurs in the radio access network. AI / ML-based technologies are currently being applied to many different applications, and 3GPP has begun researching technologies to apply them to multiple use cases based on observed potential benefits. The AI / ML lifecycle can be divided into several phases, such as data collection / preprocessing, model training, model testing / validation, model deployment / updates, and model monitoring. Each phase is equally important for achieving target performance with any particular model(s).

[0086] A challenging issue when applying AI / ML models to any use case or application is managing the lifecycle of AI / ML models. This is primarily due to data / model drift that occurs during model deployment / inference and can lead to AI / ML model performance degradation. Essentially, after model deployment, the dataset statistics change, and the model's ability to reason with unseen data as input is also affected. In similar ways, the statistical properties of the dataset and the relationship between the input and output of the trained model may change as drift occurs. In this context, UE mobility 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 different configuration parameters.

[0087] To address this issue, collaboration between the UE and gNB is crucial. This ensures that model performance is tracked and the model is reconfigured to adapt to changing environments as the UE moves between gNBs. AI / ML models require model monitoring after deployment, as performance can drift and become unsustainable. This requires feedback to retrain / update the model or select an alternative model. Therefore, addressing AI / ML data / model drift by tracking model performance (e.g., predictability, accuracy, etc.) is crucial.

[0088] When deploying wireless communication networks that support AI / ML models, it is important to consider how to address AI / ML model activation and reconfiguration on wireless devices during operations (e.g., model training, inference, updates, etc.). In other words, by proactively reconfiguring any models in operation with the source gNB, the performance impact caused by UE mobility can be minimized when connecting to the target gNB.

[0089] Figure 1 This table illustrates an example of the content of the device model status information provided by the UE. Based on model operation status updates based on the UE's use of the "Device Model Status Information," the source gNB obtains the latest information regarding the UE's model operation, enabling any required model reconfiguration between the gNB and UE, if necessary. The device model status information contains categorized data types such as {model operation mode status, model training status, model inference status, model update status, model monitoring status, model ID, and ML capability status}. The structure of the device model status information can be flexibly configured and subcategorized via radio resource control (RRC) signaling.

[0090] Figure 2 This section describes the signaling process for device model status information. Device model status information can be sent from the UE to the gNB via PUCCH / PUSCH or MAC CE. From a scheduling perspective, this information signaling can be configured as periodic, semi-persistent, or aperiodic.

[0091] Figure 3 This table shows an example of the content of model pre-configuration information. "Model pre-configuration information" is used to pre-load the reconfiguration model for a new connection with the target gNB. Model pre-configuration information includes, for example, {model configuration parameters, model ID, model transfer type, and model lifecycle type}.

[0092] Figure 4 This section describes the signaling process for model pre-configuration information. Model pre-configuration information can be sent from the gNB to the UE via PDCCH / PDSCH or MAC CE. From a scheduling perspective, this information signaling can be configured as periodic, semi-persistent, or aperiodic.

[0093] Figure 5 A flowchart illustrates gNB behavior for pre-configured models. The pre-configured models used for preparation can be based on the following two scenarios. In the first scenario, full pre-configuration of the AI / ML model is considered, where the reconfigured model is fully loaded into the UE before handover is performed. In the second scenario, partial pre-configuration of the AI / ML model is considered, where the reconfigured model is partially loaded into the UE before handover is performed. The determination of whether full or partial model pre-configuration information is used can be based on network / UE-specific criteria. For example, it may depend on the UE ML capability status, model type or function, network data traffic status, and / or model-based service applications.

[0094] Figure 6A flowchart illustrating UE behavior for a preconfigured model is provided. On the UE side, the reconfigured model is preloaded so that it can be activated when a handover is triggered. After the handover is triggered, the UE switches to the preconfigured model for operation. Depending on the implementation, the timing of preloading and / or operational switching may vary. In other words, for example, preloading may occur after a handover is triggered, followed by an operational switch.

[0095] Figure 7 This block diagram illustrates multiple partitions of model pre-configuration information. Model pre-configuration information can be structured into multiple partitions, allowing partial / block reconfiguration to be applied to preloads in the same way as full reconfiguration. Based on the content of the model pre-configuration information, it can be divided / partitioned into common attributes and UE-specific attributes, allowing any combination of model pre-configuration information to be provided to the UE when necessary. A superset of model pre-configuration information is maintained at the source gNB or network side. This allows for different levels of model reconfiguration to be performed based on the varying conditions and environments of model operation.

[0096] Figure 8 A flowchart illustrates model reconfiguration on the UE side. The necessity of UE model reconfiguration is determined based on the location of model activation (e.g., network-side, UE-side, or both). For example, if the model is located only on the UE side, or if the model is available on both the network and UE sides, a full or partial / blocked reconfiguration of the UE model is required. In the event that a model is activated on the network side for reconfiguration, a model reconfiguration request also needs to be sent to the target gNB(s) or the network side.

[0097] Figure 9 A flowchart illustrating model reconfiguration on the network side is shown. For example, if the model resides only on the network side, there is no need to reconfigure the UE model. However, assistance information signaling from the UE may still be required. In this case, a model reconfiguration request is sent to the target gNB(s) or the network side so that any potential UEs for handover to the indicated target gNB can continue to be served by the model in the target gNB.

[0098] Figure 10 A flowchart for UE mobility detection is shown. When a gNB determines to pre-configure a UE model, it considers various scenarios and criteria. For example, by monitoring the UE's mobility status, the source gNB identifies "high-mobility" UEs. These UEs will be instructed to undergo model reconfiguration (based on the network's AI / ML model repository) in preparation for handover to another target gNB. How high-mobility UEs are identified to preemptively change model operation through model reconfiguration depends on network-specific implementation. However, for example, mobility pattern information from historical measurement data can be used to identify these UEs.

[0099] Figure 11 A flow chart for UE mobility monitoring is shown. For high-mobility UEs with pre-loaded model reconfiguration, a model deactivation timer is applied so that the burden on network / device resources can be reduced when no handover occurs. Upon expiration of the model deactivation timer, high-mobility UEs that do not undergo handover uninstall the pre-configured model.

[0100] Figure 12 This section describes the signaling flow for the pre-configured model for general handover scenarios. The pre-configured model, which supports UE mobility, is applicable to both general and advanced handover scenarios. First, for general / regular handover scenarios, RRC reconfiguration via handover command signaling triggers activation of the pre-configured model and, if necessary, appends model pre-configuration information to indicate the target gNB. After the handover is confirmed, the pre-configured model is pre-activated to establish a connection with the target gNB.

[0101] Figure 13 This document describes the signaling flow for a preconfigured model for conditional handover (CHO) scenarios. This is for advanced handover scenarios (e.g., conditional CHO). In the source gNB, candidate target gNBs for UE connection are prioritized in advance to minimize any model-related signaling overhead and the impact of the model on UE mobility. CHO-based RRC reconfiguration signaling indicates additional model preconfiguration information associated with the target gNB's priority list. After the CHO conditions are met, the preconfigured model is pre-enabled to establish a connection with the target gNB. However, during UE mobility with model support, a set of resources must be reserved in the target gNB, and the source gNB maintains the target gNB's priority list and the associated model preconfiguration instructions to be signaled to high-mobility UEs.

[0102] This application provides basic mechanisms for interaction and data information flow in radio access network cooperation for AI / ML support, especially in terms of UE mobility.

[0103] Based on the proposed invention, the gNB-UE behavior for AI / ML operations supporting wireless communications with UE mobility can be greatly improved in potential scenarios.

Claims

1. A method for gNB-UE behavior for model-based mobility using a preconfigured AI / ML model based on fully or partially preconfigured configuration, wherein: For fully pre-configured AI / ML models, the reconfigured model is fully loaded into the UE before the handover is performed. For partial pre-configuration of AI / ML models, the reconfiguration model is partially loaded to the UE before the handover is performed.

2. The method according to claim 1, wherein The decision to transmit full or partial model pre-configuration information is based on network / UE specific criteria.

3. A method according to any preceding claim, wherein: The network / UE specific criteria are UE ML capability status and / or model type and / or function, and / or network data traffic status and / or model-based service applications.

4. A method according to any preceding claim, wherein: The source gNB obtains model operation status updates from the UE via device model status information signaling, thereby obtaining the latest information about the UE model operation to facilitate any required model reconfiguration between the gNB and the UE.

5. A method according to any preceding claim, wherein: The device model status information includes classified data types such as model operation mode status and / or model training status and / or model inference status and / or model update status and / or model monitoring status and / or model ID and / or ML capability status, and The structure of the device model status information is flexibly configured or sub-classified through RRC signaling. Device model status information is sent from the UE to the gNB via PUCCH / PUSCH or MAC CE.

6. A method according to any preceding claim, wherein: The UE pre-loads the reconfigured model in advance based on the signaling of the model pre-configuration information received from the source gNB for the new connection with the target gNB.

7. A method according to any preceding claim, wherein: Model pre-configuration information includes, for example, model configuration parameters, model ID, model transfer type, and model lifecycle type. The model pre-configuration information is sent from the gNB to the UE via PDCCH / PDSCH or MACCE.

8. A method according to any preceding claim, wherein: Model pre-configuration information can be structured into multiple partitions, allowing partial / block reconfiguration to be applied to pre-loading just like full reconfiguration.

9. A method according to any preceding claim, wherein: Based on the content of the model pre-configuration information, the content can be divided into common attributes and UE-specific attributes, so that any combination of model pre-configuration information can be provided to the UE when necessary.

10. A method according to any preceding claim, wherein: Maintain a superset of model pre-configuration information at the source gNB or network side.

11. A method according to any preceding claim, wherein: Perform different levels of model reconfiguration based on the different conditions and environments in which the model operates.

12. A method according to any preceding claim, wherein: The necessity of UE model reconfiguration is determined based on the location of model activation (e.g., network side or UE side or both).

13. A method according to any preceding claim, wherein: The model is activated at the network side and / or the UE side.

14. A method according to any preceding claim, wherein: For network-side only models, UE model reconfiguration is not performed and assistance information signaling from the UE may still be required; a model reconfiguration request needs to be sent to the target gNB or the network side.

15. A method according to any preceding claim, wherein: For models on the UE side only or on the network-UE side, full or partial / block-wise reconfiguration of the UE model is performed; when there is a model activated for reconfiguration on the network side, a model reconfiguration request is also sent to the target gNB or the network side.

16. A method according to any preceding claim, wherein: The source gNB determines high-mobility UEs by monitoring the UEs’ mobility status. The high-mobility UEs are indicated for model reconfiguration based on an AI / ML model repository from the network in preparation for handover to other target gNBs. The high-mobility UEs are identified using mobility pattern information with historical measurement data.

17. A method according to any preceding claim, wherein: For high mobility UEs with pre-loaded model reconfiguration, a model deactivation timer is applied so that the burden on network and / or UE resources is reduced when handover does not occur.

18. A method according to any preceding claim, wherein: As the model deactivation timer expires, the high mobility UE that is not performing handover uninstalls the pre-configured model.

19. A method according to any preceding claim, wherein: For general / regular handover cases, RRC reconfiguration via handover command signaling indicates the target gNB information by triggering the activation of this pre-configured model and, if necessary, additional model pre-configuration information. After the handover is confirmed, this pre-configured model is pre-enabled to establish a connection with the target gNB.

20. A method according to any preceding claim, wherein: For advanced handover scenarios (Conditional Handover, CHO), candidate target gNBs for UE connection are prioritized in advance in the source gNB so that any model-related signaling overhead and model impact based on UE mobility are minimized.

21. A method according to any preceding claim, wherein: The CHO-based RRC reconfiguration signaling indicates additional new information about additional model pre-configuration information associated with the priority list of these target gNBs.

22. A method according to any preceding claim, wherein: After the CHO conditions are met, the pre-configured model is pre-enabled to establish a connection with the target gNB.

23. A method according to any preceding claim, wherein: During UE mobility execution with model support, a set of resources needs to be reserved in the target gNB and the source gNB maintains a prioritized list of these target gNBs and the associated model pre-configuration instructions to be signaled to high mobility UEs.

24. A wireless device comprising at least one memory and at least one processor configured to perform the method according to any one of the preceding claims.

25. A user equipment (UE), comprising the wireless device according to claim 24.

26. A base station BS, comprising at least one memory and at least one processor, the at least one processor being configured to execute the method according to any one of claims 1 to 24.

27. A wireless communication system comprising at least one base station according to claim 26 and at least one user equipment according to claim 25.

28. A computer program product comprising instructions which, 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 23.

Images