Method of advanced ml report signaling

Abstract

The method of data-driven AI / ML model signaling for ML status reporting with machine learning model operation in wireless mobile communication system including base station (e.g., gNB) and mobile station (e.g., UE) is described, furthermore the mapping relationship is measured for different types of model operation between network and UE so that this measurement can be applied to varying applications with priority index for ML status update based on prioritization.

Description

[0001] TITLE

[0002] Method of advanced ML report signaling

[0003] TECHNNICAL FIELD

[0004] The present disclosure relates to AI / ML based model status update report signaling, where techniques for pre-configuring and signaling the specific information about status update of machine learning model operation with different types are presented.

[0005] BACKGROUND

[0006] In 3GPP (3rd Generation Partnership Project), one of the selected study items as the approved Release 18 package is AI / ML (artificial intelligence / machine learning) as described in the related document (RP-213599) addressed in 3GPP TSG RAN (Technical Specification Group Radio Access Network) meeting #94e. The official title of AI / ML study item is “Study on AI / ML for NR Air Interface”, and currently RAN WG1 and WG2 are actively working on specification. The goal of this study item is to identify a common AI / ML framework and areas of obtaining gains using AI / ML based techniques with use cases.

[0007] According to 3GPP, the main objective of this study item is to study an AI / ML framework for air-interface with target use cases by considering performance, complexity, and potential specification impact. In particular, AI / ML model, terminology and description to identify common and specific characteristics for the framework will be one of key work scope. Regarding AI / ML framework, various aspects are under consideration for investigation, and one of key items is about lifecycle management of AI / ML model where multiple stages are included, as mandatory for model training, model deployment, model inference, model monitoring, model updating etc.

[0008] Earlier, in 3GPP TR 37.817 for Release 17, titled as Study on enhancement for Data Collection for NR and EN-DC, UE mobility was also considered as one of AI / ML use cases and one of scenarios for model training / inference is that both functions are located within RAN node. Followingly, in Release 18 the new work item of “Artificial Intelligence (AI)ZMachine Learning (ML) for NG-RAN” was initiated to specify data collection enhancements and signaling support within existing NG-RAN interfaces and architecture.

[0009] For the above active standardization works, currently there is no specification defined for signaling methods or network (e.g., gNB) I mobile station (e.g., UE) behaviors about supporting UE status update reporting about AI / ML model operation when multiple LCM (lifecycle management) operations are enabled on a device such as model training and inferencing and / or updating, etc. for one or more particular application scenarios with different set of ML features / functionalities. Since applicable conditions to support the enabled LCM operations can dynamically change due to indevice condition change and / or external condition change, the network side also need to be aware of accurate information about the reported ML status update for those LCM operations.

[0010] For various use cases / scenarios with ML operation, it is expected that the model performance can be significantly degraded with an applicable condition change, as the associated ML status update could not be reported to network accurately and / or with delay.

[0011] US 2021326701 A1 describes the method of transmitting the measurements to other node for neural network training and a method of reporting a UE capability to a server and configuring neural network parameters.

[0012] US 2022400373A1 shows a method, performed by a UE, for transmitting, to a BS, UE capability information indicating at least one radio capability of the UE and at least one machine learning (ML) capability of the UE and receiving, from the BS, based on the UE capability information, ML configuration information indicating at least one neural network function.

[0013] US 2022330012A1 shows the performance of a ML procedure based on at least one initial ML capability of the UE and determination of at least one updated ML capability for the ML procedure corresponding to an update to the at least one initial ML capability.

[0014] WO2023272718A1 shows that a UE indicates a support for an end-to-end multi-block machine learning application with block of the multi-block machine learning application.

[0015] US 2022377844A1 shows a network transmission of an ML model training request to activate the ML model training and a device transmission, based on receiving the ML model training request, ML model training results indicative of a trained ML model.

[0016] The object of the invention is to improve the performance of such known communication systems.

[0017] This object is solved by the subject matter of the independent claims. Further embodiments of the invention are defined in the dependent claims.

[0018] BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 is an exemplary block diagram of ML status reporting with priority index.

[0020] Figure 2 is an exemplary table #1 of mapping relationship table for priority index.

[0021] Figure 3 is an exemplary table #2 of mapping relationship table for priority index.

[0022] Figure 4 is a flowchart of procedure of ML status update report at network side.

[0023] Figure 5 is a flowchart of procedure of ML status update report at device side when network provides indication message.

[0024] Figure 6 is a flowchart of procedure of ML status update report at device side with UE autonomous decision. Figure 7 is an exemplary block diagram of mapping relationship between ML status update and priority level.

[0025] Figure 8 is a signaling flow of ML status reporting with priority index for periodic case. Figure 9 is a signaling flow of ML status reporting with priority index for event-trigger case.

[0026] DETAILED DESCRIPTION

[0027] The detailed description set forth below, with reference to annexed 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 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 may be practiced without these specific details. In particular, although terminology from 3GPP 5G NR may be used in this disclosure to exemplify embodiments herein, this should not be seen as limiting the scope of the invention.

[0028] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only 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.

[0029] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0030] In some embodiments, a more general term “network node” may be used and may correspond to any type of radio network node or any network node, which communicates with a UE (directly or via another node) and / or with another network node. Examples of network nodes are NodeB, MeNB, ENB, a network node belonging to MCG or SCG, base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, gNodeB, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, RRU, RRH, nodes in distributed antenna system (DAS), core network node (e.g. Mobile Switching Center (MSC), Mobility Management Entity (MME), etc), Operations & Maintenance (O&M), Operations Support System (OSS), Self Optimized Network (SON), positioning node (e.g. Evolved- Serving Mobile Location Centre (E-SMLC)), Minimization of Drive Tests (MDT), test equipment (physical node or software), etc.

[0031] 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 communicating with a network node and / or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine (M2M) communication, PDA, PAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, UE category Ml, UE category M2, ProSe UE, V2V UE, V2X UE, etc.

[0032] Additionally, terminologies such as base station / gNodeB and UE should be considered non-limiting and do in particular not imply a certain hierarchical relation between the two; in general, “gNodeB” could be considered as device 1 and “UE” could be considered as device 2 and these two devices communicate with each other over some radio channel. And in the following the transmitter or receiver could be either gNodeB (gNB), or UE.

[0033] As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects.

[0034] For example, the disclosed embodiments may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off- the-shelf semiconductors such as 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, or the like. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function.

[0035] 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, referred hereafter as code. The storage devices may be tangible, non- transitory, and / or non-transmission. The storage devices may not embody signals. In a certain embodiment, the storage devices only employ signals for accessing code

[0036] Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the 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.

[0037] More specific examples, in a non-exhaustive list, of such storage devices would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc readonly 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.

[0038] Code for carrying out operations for embodiments may be any number of lines and may be written in any combination of one or more programming languages including an object- oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the “C” programming language, or the like, and / or machine languages such as assembly languages. The code may execute entirely on the user’s computer, partly on the user’s computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’s computer through any type of network, including a local area network (“LAN”), wireless LAN (“WLAN”), or a wide area network (“WAN”), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider (“ISP”)).

[0039] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of an embodiment. Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean “one or more but not all embodiments” unless expressly specified otherwise. The terms “including,” “comprising,” “having,” and variations thereof mean “including but not limited to,” unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a,” “an,” and “the” also refer to “one or more” unless expressly specified otherwise.

[0040] Aspects of the embodiments are described below with reference to schematic flowchart diagrams and / or schematic block diagrams of methods, apparatuses, systems, and program products according to embodiments. It will be understood that each block of the schematic flowchart diagrams and / or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and / or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart diagrams and / or block diagrams.

[0041] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function / act specified in the flowchart diagrams and / or block diagrams. The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart diagrams and / or block diagrams.

[0042] The flowchart diagrams and / or block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products according to various embodiments. In this regard, each block in the flowchart diagrams 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(s).

[0043] It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.

[0044] Although various arrow types and line types may be employed in the flowchart and / or block diagrams, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and code. The description of elements in each figure may refer to elements of proceeding figures. Like numbers refer to like elements in all figures, including alternate embodiments of like elements.

[0045] This application is intended to provide fundamental mechanisms of interworking and data information flow in radio access network collaboration for AI / ML support, especially in priority-based mapping relationship between ML status update and priority index in ML operation aspect.

[0046] Based on the proposed application, gNB-UE behaviors for supporting AI / ML operation for wireless communication with joint ML operation can be greatly improved with the potential scenarios.

[0047] The following explanation will provide the detailed description of the mechanism about data-driven AI / ML model signaling for quasi-based ML model operation in a wireless mobile communication system including a base station (e.g., gNB) and a mobile station (e.g., UE)

[0048] An AI / ML lifecycle can be split into several stages such as data collection / pre- processing, model training, model testing / validation, model deployment / update, model monitoring, model switching / selection etc., where each stage is equally important to achieve target performance with any specific model(s). In applying an AI / ML model for any use case or application, one of the challenging issues is to manage the lifecycle of an AI / ML model. It is mainly because the data / model drift occurs during model deployment / inference, and it results in performance degradation of AI / ML model. Fundamentally, the dataset statistical changes occur after model is deployed and model inference capability is also impacted with unseen data as input. In a similar aspect, the statistical property of dataset and the relationship between input and output for the trained model can be changed with a drift occurrence. Then a model adaptation is required to support operations such as model switching, retraining, fallback, etc. When AI / ML model enabled wireless communication network is deployed, it is then important to consider how to handle an adaptation of the AI / ML model under operations such as model training, inference, monitoring, updating, etc.

[0049] Based on a specific network-UE ML collaboration in deployment scenarios (e.g., UE mobility case), ML applicable conditions for LCM operations can be significantly changed with different mobility ranges over time by degrading any activated LCM operations. When there are multiple applicable functionalities / models activated in UE, the associated status updates of one or multiple LCM operations (e.g., training / updating, inferencing / monitoring, etc.) could be congested for reporting to network side. Time-critical status updates about specific LCM operations (e.g., related to UE mobility) need to be prioritized for ML status reporting especially when ML report scheduling has conflict among multiple ML status updates in parallel so that any performance degradation of model(s) can be avoided or minimized by reconfiguring ML information within the limited time. By prioritizing ML status update reporting with the associated LCM operation and / or ML model(s), ML performance degradation due to applicable condition change is expected to be reduced and / or ML status report error due to delay with time gap between applicable condition change and reporting time can be also reduced.

[0050] In this method, for a finite list of LCM operations with ML models / functionalities that can be enabled at UE, the associated ML status reporting is pre-configured with the matched priority index so that any specific ML status update for the selected LCM operation(s) / model(s) can be prioritized for reporting according to different application scenarios deployed.

[0051] Figure 1 shows an exemplary block diagram of ML status reporting with a priority index where ML configuration information with ML status report setting and the matched priority index for specific applications are pre-configured for different ML application scenarios and the associated ML features or functionalities with one or multiple applicable models. The priority index is then used to match with LCM operation mode and the associated applicable condition information. ML status update content for reporting can contain the following information: • LCM operation mode update (e.g., training, inferencing, monitoring, etc.) and / or

[0052] • ML applicable condition update (e.g., configuration, scenario, deployment, model, etc.)

[0053] In this exemplary figure, UE mobility is detected during LCM operation and ML status update is requested for reporting. For reporting step, priority index is used to determine which ML status update need to be reported for specific conditions.

[0054] The priority index is pre-configured in advance by the network side and shared with UE first. Based on this, when the ML model is running on UE device, the related ML status update needs to be reported back to the network, NW. In Fig. 1 , the block diagram has a use case using UE mobility that influences ML status change with model performance impact.

[0055] Figure 2 shows an exemplary table of a mapping relationship table for priority index where a mapping relationship between ML models with application scenarios and the associated ML status update content is pre-configured with the priority index. The priority index is then selected that is-matchesd with an LCM operation mode and the associated applicable condition data set or attribute data set. A priority index based mapping table can be based on different ML status update content such as a combination of LCM modes and attribute data set or combination of LCM models and applicable conditions. For example, attribute data sets may contain the combination of parameter set for {configuration, scenario, deployment, model}. Mapping relationship tables can be multiple for different scenarios or applications / environ- ments so that priority index can be configured for the associated applicable condition update and LCM operation mode update. The size of mapping relationship tables can vary depending on different configurations to be implemented, where total number of priority index values is finite.

[0056] Figure 3 shows another exemplary table of mapping relationship table for priority index. As shown in Figure 2, there could be another combined mapping relationship table(s) based on application scenarios, ML models, ML features with associated functionalities with a list of priority index values. Based on generation of these mapping relationship tables, the pre-configured mapping relationship information including priority index is sent to UE (e.g., through common RRC signaling or dedicated RRC signaling).

[0057] Therefore, the related ML status update is firstly triggered to report to the NW based on the priority index using the pre-configured mapping relationship table (as shown in Fig. 2 and Fig. 3 with some exemplary tables).

[0058] The priority index can be associated with several factors as shown in mapping relationship tables and determination of which ML status report with priority index is made by either NW or UE side. Depending on application scenarios and ML models / features / functions, high priority or low priority can be indexed and ML status update with high priority index will be then sent faster.

[0059] Figure 4 shows a flowchart of procedure of ML status update report at network side where network side has decision of sending priority index with indication message by gNB. Two methods of reporting ML status update signaling are possible such as:

[0060] • network side decision of sending priority index with indication message by gNB (e.g., through MAC CE or other available L1 / L2 signaling)

[0061] • UE autonomous decision of priority index

[0062] In this figure, gNB or network side configures mapping relationship information between ML status reporting and priority index. Based on network side decision of sending priority index, indication message is sent to UE through L1 / L2 signaling. When sending indication message for any particular priority index, the preference of receiving the indicated ML status update based on priority index is determined by network side.

[0063] Figure 5 shows a flowchart of procedure of ML status update report at device side when network provides indication message where the preferred priority index is determined by network side for particular ML status update reception. Since the preconfigured mapping relationship information including priority index is provided to UE in advance, the indication message from network side is then matched with priority index for the requested ML status update to be reported.

[0064] Figure 6 shows a flowchart of a procedure of an ML status update report at device side with UE autonomous decision where UE determines priority index to report any particular ML status update. In this case, UE sends the determined priority index with the associated ML status update to network side.

[0065] Figure 7 shows an exemplary block diagram of mapping relationship between ML status update and priority level, where depending on the configured LCM operation mode between network and UE, ML status reporting is split into high priority and low priority levels with index, e.g. the priority index, and the number of priority levels is finite / re-configurable. The mapping relationship between ML status update information and priority levels is pre-configured so that UE can determine the prioritized ML status reporting. For generating mapping relationship between ML status update and priority level, a set of key elements need to be considered such as ML application scenarios, ML features, ML functionalities, ML models / LCM phases, and attribute data sets that represent different combinations of the associated configuration, scenario, deployment, model, etc. or applicable conditions required to support LCM / model operations for any particular ML application scenarios.

[0066] Figure 8 shows a signaling flow of ML status reporting with priority index for periodic case where ML status reporting is performed periodically for different LCM operations enabled by UE. For example, finite list of ML status updates for specific LCM operations can be reported to network in different periodic settings based on prioritized order.

[0067] Figure 9 shows a signaling flow of ML status reporting with priority index for eventtrigger case where ML status reporting is triggered with the pre-configured threshold based on applicable condition change or attribute data change belonging to ML status update content so that network side can be reported for selected ML status update with the associated priority index. Fig. 8 and Fig. 9 are two flow charts. Fig. 8 is periodic case and ML status report is sent periodically based on priority index. In other words, the highest priority-based ML status update is sent first and continues to Nth report. Fig. 9 it is event-trigger case and UE device determines which ML status update and associated priority index will be sent.

[0068] Depending on application scenarios or LCM operations, both periodic and eventtrigger method can be used separately or combined together for ML status reporting. On the other hand, UE grouping based multicast can be used for sending priority index as indication message for requesting specific ML status update. In case that the same priority index is sent to more than one single UE for ML status update request, multiple UEs can be grouped together based on using common mapping relationship information applicable to those UEs.

[0069] A further embodiment is characterized by that instead of requesting from UEs which models are supported that the UE receives via broadcast of the gNB a catalogue of supported models e.g., as a new “AI / ML” SIB, then, UE internally identifies the most suitable candidate model and reports the chosen index according to indices sent via AI / ML SIB.

Claims

CLAIMS1. A method of forming a mapping relationship between machine learning, ML, status update and a priority index, comprising:• Pre-configuring the priority index for different ML application scenarios and associated ML features with one or multiple applicable models;• Configuring ML status update content that is one of an life cycle management, LCM, operation mode update and / or an ML applicable condition update;• Mapping of ML models with application scenarios and associated ML status update content;• Setting mapping relationship tables with the priority index;• Transmitting the pre-configured mapping relationship information including priority index.

2. The method according to claim 1 , wherein transmitting the pre-configured mapping relationship information is performed through one of common RRC signaling or dedicated RRC signaling.

3. The method according to any previous claim, further including reporting ML status update signaling.

4. The method according to claim 3, wherein reporting ML status update signaling comprises one of:• Deciding on network side to send the priority index with an indication message by the gNB, or• autonomously deciding by the UE to send the priority index.

5. The method according to claim 4, wherein sending the priority index with an indication message by the gNB is performed through one of MAC CE or other available L1 / L2 signaling.

6. The method according to any previous claim, further comprising: configuring the mapping relationship information between ML status reporting and priority index by a gNB or the network side, and sending an indication message to a UE through L1 / L2 signaling based on a network side decision of sending the priority index.

7. The method according to any previous claim, wherein the preferred priority index is determined by the network side for particular ML status update reception.

8. The method according to claim 4, wherein the UE determines the priority index to report any particular ML status update and the UE sends the determined priority index with the associated ML status update to the network side.

9. The method according to claim 1 , wherein depending on the configured LCM operation mode between network and UE, ML status reporting is split into high priority and low priority levels and a set of key elements contain one of ML application scenarios, ML features, ML functionalities, ML models, LCM phases, and attribute data sets that represent different combinations of the associated configuration, scenario, deployment, model, etc. or applicable conditions required to support LCM / model operations for any particular ML application scenarios.

10. The method according to any previous claim, wherein the signaling flow of ML status reporting with priority index for one of a periodic case and an event-trigger case comprises one of:• A periodic case, in which ML status reporting is performed periodically for different LCM operations enabled by UE. For example, finite list of ML status updates for specific LCM operations can be reported to network in different periodic settings based on prioritized order.• An event-trigger case in which ML status reporting is triggered with the preconfigured threshold based on applicable condition change or attribute data change belonging to ML status update content for facilitating that network side receives a report for selected ML status update with the associated priority index.11 . The method according to any previous claim, wherein UE grouping based multicast can be used for sending priority index as indication message for requesting specific ML status update and the same priority index is sent to more than one single UE for ML status update request by grouping multiple UEs based on using common mapping relationship information applicable to those UEs.

12. Apparatus for forming mapping relationship between ML status update and priority index, the apparatus comprising a wireless transceiver, a processor coupled with a memory in which computer program instructions are stored, said instructions being configured to implement steps of the claims 1 to 11 .

13. User Equipment comprising an apparatus according to claim 12.

14. Base station comprising an apparatus according to claim 12.

15. Wireless communication system, wherein the gNB comprises a processor coupled with a memory in which computer program instructions are stored, said instructions being configured to implement steps of one of claims 1 to 11 , and wherein the UE comprises a processor coupled with a memory in which computer program instructions are stored, said instructions being configured to implement steps of one of the claims 1 to 11 .

Images