Iterative explainability reporting for machine learning features

Abstract

Embodiments of the present disclosure relate to apparatus, methods, and computer readable storage media for iterative explainability reporting for machine learning features. The method includes transmitting, by a user equipment (UE) to a network node, an indication of a capability of the UE to iterate with the network node to determine an explainability reporting (ER) configuration, and iteratively communicating with the network node to determine an ER configuration for reporting a machine learning (ML) feature implemented at the UE, wherein iteratively communicating includes receiving, by the UE from the network node, at least two ER configuration requests and at least one configuration switch timer.

Description

Technical Field

[0001] The various example embodiments generally relate to machine learning features, and more specifically, to interpretability reporting and configuration for machine learning features implemented in user devices. Background Technology

[0002] Wireless networks offer significant advantages to user mobility. The ability to maintain connectivity while on the move not only benefits users but also contributes to greater efficiency and productivity across society. As user expectations for processing power, connection reliability, data speed, and battery life increase, the technologies used in wireless networks must keep pace. Therefore, there has been ongoing interest in improving wireless network technologies. Summary of the Invention

[0003] The independent claims provide the subject matter for several aspects. Additional aspects are defined in the dependent claims.

[0004] According to various aspects of this disclosure, a method includes: sending an indication from a user equipment (UE) to a network node of the ability of the UE to iterate with the network node to determine an interpretability report (ER) configuration; and iteratively communicating with the network node to determine the ER configuration for reporting machine learning (ML) features implemented at the UE, wherein the iterative communication includes the UE receiving at least two ER configuration requests and at least one configuration switching timer from the network node.

[0005] In one aspect of the method, the at least two ER configuration requests may include an indication of at least one of the fixed ER configurations.

[0006] In one aspect of the method, the at least two ER configuration requests may include a request for the UE to propose a complete ER configuration that is entirely configured by the UE.

[0007] In one aspect of the method, the at least one configuration switching timer may correspond to a minimum duration during which the UE may not change the ER configuration or the ER configuration parameters.

[0008] In one aspect of the method, iterative communication may also include at least one ER configuration configured by the UE, which is entirely configured by the UE.

[0009] In one aspect of the method, iterative communication may further include: the UE sending a first proposal to the network node using a first ER configuration of at least two ER configurations, wherein the first ER configuration is entirely configured by the UE; and the UE receiving an indication of approval or rejection of the first proposal from the network node.

[0010] In one aspect of the method, the UE may receive an indication of approval of the first proposal from the network node, and the method may further include the UE selecting a first ER configuration based on the first proposal for reporting ML-enabled features implemented at the UE.

[0011] In one aspect of the method, the UE may receive an indication of rejection of the first proposal from the network node, and the method may further include the UE sending a second proposal to the network node using a second ER configuration of at least two ER configurations, wherein the second ER configuration is entirely configured by the UE.

[0012] In one aspect of the method, the method may further include the UE sending at least two interpretability reports to the network node.

[0013] In one aspect of the method, iterative communication may further include: when the maximum number of iterations of iterative communication is reached, the UE sends a default ER configuration to the network node.

[0014] In one aspect of the method, sending at least two interpretability reports may include the UE sending a first interpretability report based on a first ER configuration to the network node before one of the configuration switching timers expires.

[0015] In one aspect of the method, sending at least two interpretability reports may further include: after one of the configuration switching timers in at least one configuration switching timer expires, the UE sends a second interpretability report based on the second ER configuration to the network node.

[0016] In one aspect of the method, iterative communication may also include the UE receiving from the network node an indication that only one of the at least two ER configurations is used.

[0017] In one aspect of the method, an indication to use only one of the at least two ER configurations may be an indication to use only the second ER configuration.

[0018] According to various aspects of this disclosure, an apparatus includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform at least any of the methods described above.

[0019] According to various aspects of this disclosure, a processor-readable medium stores instructions that, when executed by at least one processor of the device, cause the device to perform at least any of the methods described above.

[0020] According to various aspects of this disclosure, a method includes: receiving from a user equipment (UE) an indication of the ability of a network node to iterate with the UE and the network node to determine an interpretability report (ER) configuration; and iteratively communicating with the UE to determine the ER configuration for reporting machine learning (ML) enabled features implemented at the UE, wherein the iterative communication includes the network node sending at least two ER configuration requests and at least one configuration switching timer to the UE.

[0021] In one aspect of the method, the at least two ER configuration requests may include an indication of at least one of the fixed ER configurations.

[0022] In one aspect of the method, the at least two ER configuration requests may include a request for the UE to propose a complete ER configuration that is entirely configured by the UE.

[0023] In one aspect of the method, the at least one configuration switching timer may correspond to a minimum duration during which the UE may not change the ER configuration or the ER configuration parameters.

[0024] In one aspect of the method, iterative communication may further include: receiving from the UE a first proposal using a first ER configuration of at least two ER configurations, wherein the first ER configuration is entirely configured by the UE; and sending an indication to the UE of approval or rejection of the first proposal.

[0025] In one aspect of the method, the network node may send an indication of rejection of the first proposal to the UE, and the method may further include the network node receiving from the UE a second proposal using a second ER configuration from at least two ER configurations, wherein the second ER configuration is entirely proposed by the UE.

[0026] In one aspect of the method, iterative communication may also include receiving at least two interpretability reports from the UE by the network node.

[0027] In one aspect of the method, iterative communication may further include: when the maximum number of iterations of iterative communication is reached, the network node receives the default ER configuration from the UE.

[0028] In one aspect of the method, receiving at least two interpretability reports may include receiving a first interpretability report based on a first ER configuration from the UE by the network node before one of the configuration switching timers expires in at least one configuration switching timer.

[0029] In one aspect of the method, receiving at least two interpretability reports may further include: after one of the configuration switching timers in at least one configuration switching timer expires, the network node receives a second interpretability report from the UE based on the second ER configuration.

[0030] In one aspect of the method, iterative communication may further include the network node evaluating at least two interpretability reports; and the network node sending an indication to the UE to use only one of the at least two ER configurations.

[0031] In one aspect of the method, an indication to use only one of the at least two ER configurations may be an indication to use only the second ER configuration.

[0032] According to various aspects of this disclosure, an apparatus includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform at least any of the methods described above.

[0033] According to various aspects of this disclosure, a processor-readable medium stores instructions that, when executed by at least one processor of the device, cause the device to perform at least any of the methods described above.

[0034] Other aspects are shown in the Examples section, which are incorporated into this section by reference. Attached Figure Description

[0035] Some exemplary embodiments will now be described with reference to the accompanying drawings.

[0036] Figure 1 This is a diagram of an example embodiment of a wireless network between a network system and a user equipment (UE) according to one aspect of this disclosure; Figure 2 This is a diagram of an example component of a network system according to one aspect of this disclosure; Figure 3 This is a diagram illustrating an example iteration between a UE and a source radio station or source node (e.g., a network node such as a gNodeB (gNB)) according to one aspect of this disclosure; Figure 4 This is a diagram of an example process for building an interpretability report (ER) configuration using iteration, according to one aspect of this disclosure; Figure 5 This is a diagram illustrating an example process for building an interpretability report (ER) configuration using iterations for three levels, according to one aspect of this disclosure; Figure 6 This is a diagram of an example process for establishing an interpretability report (ER) configuration for Level 1 adaptability, according to one aspect of this disclosure; Figure 7 This is a diagram of an example process for establishing an interpretability report (ER) configuration for degree 2 adaptability, according to one aspect of this disclosure; Figure 8 This is a diagram illustrating an example process for establishing an interpretability report (ER) configuration for degree 3 adaptability, according to one aspect of this disclosure; Figure 9 This is a diagram of an example embodiment of signaling and operation between a UE and a source radio station or source node (e.g., a network node such as a gNodeB (gNB)) according to one aspect of this disclosure; Figure 10A and Figure 10B This is a diagram of an example embodiment of signaling and operation between a UE and a source radio station or source node (e.g., a network node such as a gNodeB (gNB)) according to one aspect of this disclosure; Figure 11A and Figure 11B This is a diagram illustrating an example embodiment of signaling and operation between a UE and a source radio station or source node (e.g., a network node such as a gNodeB (gNB)) according to one aspect of this disclosure; and Figure 12 This is a diagram of an example block diagram of a wireless station or node (e.g., a network node (such as a gNodeB (gNB)), a user node or UE, a relay node or other node) according to one aspect of this disclosure. Detailed Implementation

[0037] This application relates to interpretability reporting and configuration for machine learning features implemented in user equipment.

[0038] Transparency in artificial intelligence (AI) systems facilitates their widespread adoption and effective deployment. Achieving transparency hinges on the credibility of AI and machine learning (ML) solutions. Credibility in AI / ML spans multiple dimensions, including data integrity, model accuracy and performance, and the reliability of inference mechanisms. Ensuring that AI / ML components operate within well-defined and acceptable credibility parameters helps maintain system integrity, regulatory compliance, and user trust.

[0039] As used herein, “trustworthiness” (e.g., in 6G) is a measurable and coherent level of trust and / or confidence in a value provided by stakeholders of a 6G system. Trustworthiness can be quantified as a multidimensional and dynamic parameter that includes aspects of reliability, security, privacy, resilience, and reputation. The complex values ​​assigned to this parameter can be based on (but are not limited to) policies, behavioral evidence, and / or implementation-specific algorithms.

[0040] In the telecommunications sector, particularly regarding the 3GPP (3rd Generation Partnership Project) specifications, discussions on AI / ML trustworthiness have primarily focused on system architecture specifications. This disclosure describes a process for defining and implementing trustworthiness metrics for AI / ML features and data. These metrics may include measures related to interpretability, fairness, robustness, and performance, and are designed to provide measurable standards for evaluating the trustworthiness of AI / ML systems throughout their entire lifecycle, from training to deployment and inference.

[0041] One aspect of this disclosure is the introduction of a native trust architecture for sixth-generation (6G) networks, distinct from previous concepts such as “5G trust.” The proposed architecture is designed to adapt to the diverse requirements of a multi-stakeholder ecosystem, enabling flexible and reliable trust management tailored to specific use cases and operational contexts. Specifically, the trustworthiness of AI / ML systems can be proactively managed across all stages of the ML pipeline, including training, validation, testing, and inference. This includes applying preprocessing techniques to ensure data quality and trustworthiness, and continuously evaluating models through defined trustworthiness metrics. Integrating these evaluations into the overall management and orchestration of the AI / ML system provides a comprehensive approach to trusted AI.

[0042] The process described in this paper provides significant advantages over traditional networks and / or systems by achieving consistent and interpretable assessments of trustworthiness metrics for both producers (e.g., ML feature developers and service providers) and consumers (e.g., end users and operators). This dual-perspective alignment ensures that AI / ML systems can be trusted not only in their technical operations but also in their behavior as perceived by all stakeholders involved.

[0043] In the following description, specific details are set forth to provide a thorough understanding of the disclosed aspects. However, those skilled in the art will recognize that the aspects can be practiced without one or more of these specific details or using other methods, components, materials, etc. In other instances, well-known structures associated with transmitters, receivers, or transceivers have not been shown or described in detail to avoid unnecessarily obscuring the description of the aspects.

[0044] Throughout this specification, the reference to "an aspect" or "aspect" means that a particular feature, structure, or characteristic described in connection with that aspect is included in at least one aspect. Therefore, the phrases "in an aspect" or "in one respect" appearing in various places throughout this specification do not necessarily refer to the same aspect. Furthermore, a particular feature, structure, or characteristic may be combined in one or more aspects in any suitable manner.

[0045] The embodiments described in this disclosure can be implemented in wireless network devices, such as, but not limited to, those utilizing: Global Microwave Access Interoperability (WiMAX), Global System for Mobile Communications (GSM, 2G), GSM EDGE Radio Access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunications System based on Basic Wideband Code Division Multiple Access (W-CDMA) (UMTS, 3G), High-Speed ​​Packet Access (HSPA), Long Term Evolution (LTE), Advanced LTE, Enhanced LTE (eLTE), 5G New Radio (5G NR), 5G Advanced, 6G (and above), and 802.11ax (Wi-Fi 6), and other wireless network systems. The term "eLTE" here refers to LTE evolution connected to a 5G core. LTE is also referred to as Evolved UMTS Terrestrial Radio Access (EUTRA) or Evolved UMTS Terrestrial Radio Access Network (EUTRAN).

[0046] This disclosure may use the term "serving network device" to refer to a network node or network device (or part thereof) serving a UE. As used herein, the terms "send to," "receive from," and "cooperate with" (and variations thereof) include communication, which may or may not involve communication through one or more intermediate devices or nodes. The term "acquire" (and variations thereof) includes acquiring in a first instance or reacquiring after a first instance. The term "connection" may refer to a physical connection or a logical connection.

[0047] This disclosure uses 5G NR as an example of a wireless network, and may use smartphones and / or extended reality headsets as examples of user equipment (UE). It is intended and should be understood that such examples are merely illustrative, and this disclosure applies to other wireless networks and user equipment.

[0048] Figure 1 This is a diagram illustrating an example of a wireless network between a network system 100 and a user equipment (UE) 150. The network system 100 may include one or more network nodes 120, one or more servers 110, and / or one or more network devices 130 (e.g., test devices). Network node 120 will be described in more detail below. As used herein, the term "network apparatus" may refer to any component of the network system 100, such as server 110, network node 120, network device 130, any of the foregoing components(s), and / or any other (multi-functional) component of the network system 100. Examples of network apparatuses include, but are not limited to, apparatuses for implementing various aspects of 5G NR. This disclosure describes embodiments related to 5G NR and embodiments relating to aspects defined by the 3rd Generation Partnership Project (3GPP). However, it is contemplated that embodiments related to other wireless network technologies are included within the scope of this disclosure.

[0049] The following description provides further details of examples of network nodes. In a 5G NR network, a gNodeB (also known as a gNB) may include, for example, a node that provides New Radio (NR) user plane and control plane protocol terminals toward the UE and is connected to the 5G core (5GC) via an NG interface, as exemplified by Section 3.2 of 3GPP TS 38.300 V16.6.0 (2021-06), which is incorporated herein by reference.

[0050] gNB supports various protocol layers, such as Layer 1 (L1) physical layer, Layer 2 (L2) and Layer 3 (L3).

[0051] NR's Layer 2 (L2) is divided into the following sublayers: Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptation Protocol (SDAP), among which, for example: ○ The physical layer provides a transmission channel to the MAC sublayer; ○The MAC sublayer provides logical channels to the RLC sublayer; ○ The RLC sublayer provides RLC channels to the PDCP sublayer; ○ The PDCP sublayer provides radio bearers to the SDAP sublayer; ○The SDAP sublayer provides Quality of Service (QoS) flows to 5GC; ○ The control channels include the Broadcast Control Channel (BCCH) and the Physical Control Channel (PCCH).

[0052] Layer 3 (L3) includes, for example, Radio Resource Control (RRC), as per Section 6 of 3GPP TS 38.300 V16.6.0 (2021-06), which is incorporated herein by reference.

[0053] The gNB Central Unit (gNB-CU) includes, for example, logical nodes that host, for example, the gNB's Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) protocols, or the en-gNB's RRC and PDCP protocols, and controls the operation of one or more gNB Distributed Units (gNB-DUs). The gNB-CU terminates the F1 interface connected to the gNB-DU. The gNB-CU may also be referred to herein as a CU, Central Unit, Centralized Unit, or Control Unit.

[0054] A gNB Distributed Unit (gNB-DU) includes, for example, a logical node that hosts the Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) layers of, for example, a gNB or en-gNB, and its operation is partially controlled by the gNB-CU. A gNB-DU supports one or more cells. A cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface connected to the gNB-CU. The gNB-DU may also be referred to herein as a DU or Distributed Unit.

[0055] As used herein, the term "network node" may refer to any one or any combination of gNB, gNB-CU, or gNB-DU. RAN (Radio Access Network) nodes or network nodes (such as, for example, gNB, gNB-CU, or gNB-DU, or portions thereof) may be implemented using means, for example, having at least one processor and / or at least one memory having processor-readable instructions ("programs") configured to support and / or supply and / or process CU and / or DU-related functionalities and / or features, and / or at least one protocol (sub)layer (e.g., layer 2 and / or layer 3) of the RAN (Radio Access Network). Different functional divisions between central and distributed units are possible.

[0056] The gNB-CU and gNB-DU portions can be, for example, co-located or physically separated. The gNB-DU can even be further divided into, for example, two parts, one including processing equipment and the other including an antenna. The Central Unit (CU) can also be referred to as a Baseband Unit / Radio Equipment Controller / Cloud RAN / Virtual RAN (BBU / REC / C-RAN / V-RAN), Open RAN (O-RAN), or a portion thereof. The Distributed Unit (DU) can also be referred to as a Remote Radio Head / Remote Radio Unit / Radio Equipment / Radio Unit (RRH / RRU / RE / RU), or a portion thereof. In the various exemplary embodiments of this disclosure below, a network node supporting at least one of the Central Unit functions or Layer 3 protocols of a radio access network can be, for example, a gNB-CU. Similarly, a network node supporting at least one of the Distributed Unit functions or Layer 2 protocols of a radio access network can be, for example, a gNB-DU.

[0057] A gNB-CU can support one or more gNB-DUs. A gNB-DU can support one or more cells, and therefore can support the serving cell for a user equipment (UE), or candidate cells for handover, dual connectivity and / or carrier aggregation and other procedures.

[0058] User equipment (UE) 150 may be or may include wireless or mobile devices, devices having a radio interface for interacting with a RAN (Radio Access Network), smartphones, in-vehicle devices, IoT devices, or machine-to-machine (M2M) devices, and other types of user equipment. Such a UE 150 may include: at least one processor; and at least one memory including program code; wherein the at least one memory and the computer program code are configured, together with the at least one processor, to cause the device to perform at least a specific operation, such as, for example, an RRC connection to the RAN. Figure 12 Examples of components describing a UE are provided below. In an embodiment, UE 150 may be configured to generate messages to be transmitted to the RAN via radio (e.g., including a cell ID) (e.g., to reach and communicate with the serving cell). In an embodiment, UE 150 may generate, transmit, and receive RRC messages containing one or more RRC PDUs (Packet Data Units). Those skilled in the art will understand the RRC protocol and other processes that the UE may perform.

[0059] Continue to refer to Figure 1 In an example of a 5G NR network, network system 100 provides one or more cells that define the coverage area of ​​network system 100. As described above, network system 100 may include a gNB of the 5G NR network, or may include any other means configured to control radio communications and manage radio resources within the cells. As used herein, the term "resource" may refer to radio resources such as resource blocks (RBs), physical resource blocks (PRBs), radio frames, subframes, time slots, subbands, frequency regions, subcarriers, beams, etc. In embodiments, network node 120 may be referred to as a base station.

[0060] Figure 1 Examples are provided, and only network system 100 and UE 150 are illustrated. Those skilled in the art will understand that network system 100 includes... Figure 1 Components not shown in the diagram, and it will be understood that other user equipment can communicate with network system 100.

[0061] Figure 2 yes Figure 1 A block diagram of example components of network system 100. A 5G NR network can be described as an example of network system 100, and the aspects described below should also be applicable to other types of network systems. The network system can be configured according to... Figure 1The signals and connections shown operate to enable UE 150 to communicate with network system 100 via radio access network (RAN) 225. Additionally, the network system may be segmented into user plane components and functions and control plane components and functions, as shown and described herein. Unless otherwise stated, the terms “component,” “function,” and “service” are used interchangeably herein and may refer to instructions executed by one or more processors and implemented by those instructions.

[0062] The following describes example functionality of the components. This example functionality is merely illustrative, and it should be understood that additional operations and functions may be performed by the components described herein. Additionally, connections between components may be virtual connections over service interfaces, allowing any component to communicate with any other component. In this way, any component can act as a service "producer," providing services for network functionality to any other service "producer" component.

[0063] For example, a core network 210 is described in the control plane of the network system. The core network 210 may include an Authentication Server Function (AUSF) 211, an Access and Mobility Function (AMF) 212, and a Session Management Function (SMF) 213. The core network 210 may also include a Network Slice Selection Function (NSSF) 214, a Network Open Function (NEF) 215, a Network Repository Function (NRF) 216, and a Unified Data Management Function (UDM) 217, which may include a Unified Data Repository (UDR) 224.

[0064] Additional components and functions of the core network 210 may include application functions (AF) 218, policy control functions (PCF) 219, network data analysis functions (NWDAF) 220, analytical data repository functions (ADRF) 221, management data analysis functions (MDAF) 222, and operation and management functions (OAM) 223.

[0065] The user plane includes UE 150, Radio Access Network (RAN) 225, User Plane Function (UPF) 226, and Data Network (DN) 227. RAN 225 may include a combination of Figure 1 The RAN 225 describes one or more components, such as one or more network nodes. However, the RAN 225 may not be limited to such components. The UPF 226 provides connectivity for data transmitted through the RAN 225. For example, the UPF 226 identifies services from service providers, internet access, and third-party services.

[0066] AMF 212 handles connectivity and mobility tasks. AUSF 211 receives authentication requests from AMF 212 and interacts with UDM 217 to authenticate and verify network responses to determine successful authentication. SMF 213 performs Packet Data Unit (PDU) session management and manages session context with UPF 226.

[0067] NSSF 214 can select a Network Slice Instance (NSI) and determine the allowed Network Slice Selection Auxiliary Information (NSSAI). This selection and determination are used to configure AMF 212 to provide services to UE 150. NEF 215 ensures third-party access to network services to create private network services. NRF 216 acts as a repository for storing network functions to allow function registration and discovery of each other.

[0068] UDM 217 generates authentication vectors for use by AUSF 211 and AMF 212 and provides user identity processing. UDM 217 can connect to UDR 224, which stores data associated with authentication, applications, etc. AF 218 provides application services (e.g., streaming services) to users. PCF 219 provides policy control functions. For example, PCF 219 can assist in network slicing and mobility management, as well as provide Quality of Service (QoS) and accounting functions.

[0069] NWDAF 220 collects data (e.g., from UE 150 and network systems) to perform network analytics and provide insights into the capabilities that leverage analytics when providing services. ADRF 221 allows for the storage, retrieval, and removal of data and analysis by the consumer. MDAF 222 provides additional data analytics services for network functions. OAM 223 provides provisioning and management processing capabilities to manage elements in the network or elements connected to the network (e.g., UE 150, network nodes, etc.).

[0070] Figure 2 These are merely examples of components of a network system, and variations are contemplated within the scope of this disclosure. In embodiments, the network system may include... Figure 2 Other components not shown. In embodiments, the network system may not include... Figure 2 Each component is shown. In an embodiment, components and connections can be used with... Figure 2 The connections shown are implemented using different connections. These and other embodiments are contemplated within the scope of this disclosure.

[0071] As described above, according to various aspects of this disclosure, this disclosure relates to interpretability reporting and configuration for machine learning features implemented in a user device.

[0072] Figure 3This is a diagram illustrating an example iteration between a UE and a network (e.g., a network node such as a gNodeB (gNB)) according to one aspect of this disclosure. The Interpretability Report (ER) provided by the User Equipment (UE) is designed to convey meaningful insights to the network node regarding decisions or behaviors of ML-based functionalities on the UE side, without necessarily disclosing proprietary or detailed information about the underlying model itself. Since the network node acts as the consumer of this ER information, it can benefit from the ability to customize or adapt the content and format of the ER to better align with its operation and intended use cases. As used herein, any description relating to the ML model should also be considered as relating to ML-enabled features.

[0073] In various scenarios, static or one-off configurations of ER exchanges (such as initial settings during a Radio Resource Control (RRC) session) may be insufficient. Instead, iterative interaction mechanisms between the UE and the network to negotiate, refine, and converge to mutually acceptable ER formats / configurations / parameters can be beneficial. For example, ER configurations can include different sets of parameters and allowed combinations of values ​​that are predefined and mutually recognized based on the UE capability framework. As field conditions evolve (such as changes in the radio environment or UE context), the network may need to initiate updates to the ER configuration, indicating that static configuration approaches lack the necessary flexibility.

[0074] Furthermore, direct and one-off exchanges of ERs may be insufficient to serve the dynamic nature of ML-based features. However, iterative configuration processes can be used to address ongoing variability. In certain scenarios, interpretability processes can also involve multiple UEs (potentially from different providers) employing ML-like functionality. In this case, network nodes can receive multiple ERs, depending on the UE-specific implementation or conditions, which may reflect consistent or slightly different interpretations.

[0075] Primarily due to the inherent dynamic nature of ERs, the use of iterative ER configuration differs from existing reconfiguration messaging. ERs are designed to provide interpretability of AI behavior without exposing the internal structure or logic of the AI ​​model or agent. Changes to ERs can be caused not only by external factors such as environmental changes but also by internal factors including changes in UE states and deployed ML models. The processes disclosed herein offer advantages over traditional networks by enabling the network to iteratively optimize interpretability information provided by one or more UEs without requiring access to proprietary model details. This iterative approach ensures that ERs are meaningful, relevant, and can be maximized by the network for monitoring, decision-making, or optimization tasks across a range of UE deployments.

[0076] Figure 3 The above description is merely an example, and variations are contemplated within the scope of this disclosure.

[0077] Figure 4 This is a diagram illustrating an example process for establishing an interpretability report (ER) configuration using an iterative approach, according to one aspect of this disclosure. The disclosed process enables network-assisted establishment and refinement of the ER through structured multi-operational interactions between the user equipment (UE) and the network node (NW).

[0078] Initially, in box 401 (Initial Phase), the UE indicates its ER capabilities to the network node. These capabilities can include not only a set of supported ER configurations, such as the level of interpretation detail, temporal-spatial correlation trends, and time window parameters, but also the UE's ability to participate in iterative exchanges with the network to negotiate and establish network-customized ERs. This capability allows for the generation of ERs that are better aligned with the operational requirements and intended use of the network node. Therefore, this process provides advantages over traditional ER methods by enabling the UE to participate in the iterative ER refinement process.

[0079] Following the capability exchange, in box 402 (Iterative Phase), iterative interactions can occur between the UE and the network node. This block is designed to converge to the desired ER configuration that supports the network's anticipated actions, such as triggering model updates, switching to alternative control mechanisms, and / or initiating other management procedures. Typically, the selected ER conforms to the capabilities indicated by the UE and does not require the UE to expose any internal details of its ML model or implementation. The structure and / or behavior of this iterative exchange are influenced by a degree of adaptability, such as degree 1, 2, or 3 reported by the UE, which reflects the flexibility available when adjusting the ER configuration.

[0080] Once the ER configuration is complete, in box 403 (Operational Phase), the ER is utilized in the operational settings. This block includes applying the agreed-upon ER structure and / or associated parameters and rules to send the ER to network nodes. For example, the ER may be sent in response to specific network conditions, such as reduced UE throughput or increased handover failure rate. This ensures that the ER remains responsive to dynamic network conditions and provides actionable insights without revealing sensitive information about the UE's internal ML processes.

[0081] Figure 4 The above description is merely an example, and variations are contemplated within the scope of this disclosure.

[0082] Figure 5This disclosure illustrates an example process for establishing an ER configuration using three possible degrees of adaptive ER configuration, representing one aspect of the procedure. The process provides network node-assisted setup and utilization of the degree of ER adaptability. It establishes a signaling framework in which network nodes participate in the selection and / or configuration of interpretability reports for ML functions operating on the UE side. Notably, this process offers advantages over conventional systems and networks by enabling ER content to be aligned with the specific needs and intended use cases of the network nodes, without exposing any internal details of the UE-side ML model, thus keeping the model a black box. To achieve this, an iterative process consisting of multiple rounds of signaling message exchange between the UE and the network node is employed. This interactive process ensures convergence to a mutually acceptable and network-relevant ER configuration while adhering to the UE's capability boundaries and maintaining model confidentiality.

[0083] In box 501, the UE sends an indication to the network node regarding its ability to iterate with the network node to determine the ER configuration. This indication may include the types of iterative ER configurations supported by the UE, which may include iterative ER configuration capabilities. The process then jumps to box 504, where the iteration process is initiated.

[0084] If the UE does not support any type of iterative ER configuration, the process enters a "static" pipeline, such as the previously established regular process, and continues to boxes 502 and 503. In box 502, the network node sends a request to the UE to indicate one of the pre-configured ERs and / or supported ERs. In box 503, the network node receives and utilizes the ER selected by the UE.

[0085] In box 504, an iterative process is initiated to enable multi-round exchanges between the UE and the network node. The goal of box 504 is to converge to the desired ER configuration and allow the network node to derive an agreed ER. The agreed ER should be aligned with the network node's usage and requirements, which may involve not only a specific UE but also depend on other UEs served by the network node (e.g., ...). Figure 4 (The second iteration phase). In doing so, network nodes select between different types of iterations (called "degrees of adaptability") based on the UE ER capabilities from box 501.

[0086] Boxes 505 and 506 are used for adaptability level 1.

[0087] In box 505, the UE, upon request (or previously indicated in box 501), is given a predefined list of ER configurations from which the network node can select. Additionally, a network node configures a conditional ER switching configuration timer, which allows the UE to automatically trigger changes between selected configurations. The ER switching configuration timer also avoids overly frequent switching between different configurations and provides the network node with sufficient time to evaluate reports received from the UE and / or select a customized ER configuration. In box 506, the interaction between the UE and the network node achieves the agreement on a desired combination of parameter values ​​from the available list. Once converged to the agreed ER configuration, the UE can then use the ER configuration (e.g., in a configuration such as...) Figure 4 During operation phase 403 (as shown). In various aspects, as part of adaptability level 1, the UE can parameterize the maximum number of iterations within the ER sequence and / or the allowed combinations between multiple performance reports.

[0088] Boxes 507 and 508 are used for Adaptability Level 2, an intermediate case between Level 1 and Level 3 solutions. In Box 507, the network node fixes a portion of the ER configuration and enables the UE to select a partial ER configuration (e.g., an ER configuration partially fixed by the network node). Typically, the partial configuration consists only of specific, selected parameter values ​​and / or values ​​constrained by the UE's ER capabilities and preset values ​​set by the network node. In Box 508, the interaction between the UE and the network node enables the selection of a partial ER configuration.

[0089] Boxes 509-511 are used for Adaptability Level 3, which allows network nodes to establish maximum flexibility in ER reports for the UE side. In Box 509, the network node can provide the UE with ER indications about what configuration is needed. For example, the network node can share an example ER for ML input / output samples. In doing so, the network node does not need additional information about the UE-side model. In Box 510, the UE autonomously searches for and / or determines the best ER configuration match that most closely aligns with the example shared by the network node. In all aspects, semantic-based interactions can be considered (6G). For example, the NW can provide one or more fixed configurations (“examples”) similar to Level 1 while requesting one or more suggestions for a complete ER configuration (e.g., including all parameter values) from the UE. Box 510 can iterate until a selection is made. Box 511 is an alternative for Level 3. Specifically, if the UE ER configuration is unacceptable to the network node and / or an unagreed maximum number of iterations is reached, Box 511 is adopted to use an alternative configuration. In all aspects, the (multiple) “example” configurations can also be used as alternative configurations.

[0090] The following example, a third-party configuration structure based on the UE's ER configuration, illustrates various degrees of adaptability in iterative UE ER settings.

[0091] The first example involves a "static" ER configuration ( Figure 4 (Boxes 502 and 503). The static ER configuration consists of three main components.

[0092] The first component includes one or more Key Performance Indicators (KPIs), which may encompass metrics, characteristics, and / or statistics (mandatory information). KPIs may include calculated or derived statistics based on the measured KPIs, such as mean, average, percentile (e.g., x%), and / or other relevant statistical measures. The second component includes KPI trend and spatiotemporal window information (also mandatory), which provides temporal and / or spatial context for the reported KPIs, such as trend patterns and associated observation windows. The third component is supplementary data pointers (optional information), which provide reference information such as addresses and protocol details that can be used by network nodes to retrieve supplementary non-real-time data associated with the reported ER. In each aspect, for the first category (KPIs), candidates for reporting may include any KPI or measurement that the UE can observe or calculate, and their statistical aggregation over time using any applicable function, or any combination thereof.

[0093] Table 1 below shows examples of supported static ER configurations.

[0094]

[0095] Table 1: Static ER Configuration As shown in Table 1 above, KPI option #1 corresponds to the mean of RSRP and RSRQ, while KPI option #2 provides the median of RSRP and RSRQ. KPI option #3 only includes the 90th percentile value of RSRP. Each KPI option is associated with a specific trend and time window configuration. For KPI options #1 and #2, the supported time windows are 0.1 seconds, 1 second, and 10 seconds. For KPI option #3, the supported time window is 10 seconds. The available KPI trend values ​​for KPI #1 include "Upward," "Downward," and "Random," while for KPI #2, only "Upward" and "Downward" are supported. KPI #3 again supports "Upward," "Downward," and "Random" as possible trend directions. In terms of aggregation level, KPI options #1 and #2 support "Instant" reporting for all associated time windows, while KPI option #3 supports "Recorded" reporting for 1-second and 10-second time windows.

[0096] Figure 5 The above description is merely illustrative, and variations are contemplated within the scope of this disclosure. In various embodiments, the process includes... Figure 5 The box is not shown in the diagram. In various embodiments, the process does not include... Figure 5 All boxes shown. In various embodiments, the process can be performed with... Figure 5 Different execution sequences are shown. Such and other variations are contemplated within the scope of this disclosure.

[0097] Figures 6-8 The diagrams show example procedures for establishing ER configurations for adaptation levels 1, 2, and 3, respectively.

[0098] Figure 6 This is a diagram of an example process 600 for establishing an ER configuration for degree 1 adaptability, according to one aspect of this disclosure. Process 600 may include configuration 601, configuration 603 (e.g., configuration #1 and configuration #2), and switching time 602 (e.g., ER switching time).

[0099] For example, the UE indicates the supported configuration parameters (e.g., similar to the above (multiple) "static" solutions), which are supplemented with the minimum value of the conditional ER configuration switching timer corresponding to each supported KPI trend configuration. In various aspects, the expected number of iterations (e.g., the number of switching between configurations) can also be configured by the network node. If more than two configurations are provided, the switching is performed sequentially according to the order of their assigned IDs. Therefore, an iteration begins with the first configuration and ends with the last available configuration (e.g., configuration #1 -> configuration #2 -> configuration #3 -> configuration #1 -> configuration #2 -> configuration #3 -> etc.).

[0100] Table 2 below shows examples of the supported iterative ER configurations for Adaptive Level 1.

[0101]

[0102] Table 2: ER Configuration for Level 1 As shown in Table 2 above, the ER configuration includes several predefined KPI options and associated parameters. Three KPI reporting options are supported. KPI option #1 corresponds to the mean of RSRP and RSRQ. KPI option #2 only provides the median of RSRQ. KPI option #3 only reports the 90th percentile value of RSRP.

[0103] Supported time window values ​​vary depending on the KPI option. For KPI #1, allowed time windows are 0.1 seconds, 1 second, and 10 seconds. For KPI options #2 and #3, supported time windows are 1 second and 10 seconds. The minimum supported switching time between different time window values ​​is 0.5 seconds. Each KPI option also supports specific trend values. For KPI #1, supported trend types are "rising" and "falling." For KPI options #2 and #3, supported trends include "rising," "falling," and "random." The minimum supported switching time between different ER trend values ​​is 1 second. Regarding aggregation levels, KPI #1 supports "instant" reporting for all associated time windows. Conversely, KPI options #2 and #3 support "recorded" reporting, specifically for 1-second and 10-second time windows. The minimum supported switching time between different aggregation levels is 5 seconds.

[0104] The following is an example of pseudocode for an ER configuration provided by a network node with a degree of adaptability of 1, based on a UE ER capability similar to that in Table 1. Here, the conditional switching time between configuration #1 and configuration #2 is 5s (e.g., the maximum value between the minimum switching times listed in Table 2 when the corresponding KPI trend changes), and the number of iterations (switches) is 10. Configuration #1 : KPI = Mean RSRP Time window = 1 second ER KPI trend = declining ER aggregation level = instant Configuration #2 : KPI = 90th percentile RSRQ Time window = 1 second ER KPI trend = random ER aggregation level = record Condition switching time between configuration #1 and configuration #2 = 5s Iteration (switching) count = 10 Figure 7 This is a diagram of an example process 700 for establishing an interpretability report (ER) configuration for degree 2 adaptability, according to one aspect of this disclosure. Process 700 may include configurations 701, 703, 705, 707 (e.g., configuration #1, configuration #2, configuration #3, and configuration #4) and switching times 702, 704, and 706 (e.g., ER switching times).

[0105] In this example, the UE indicates the supported configuration parameters (e.g., similar to Level 1 adaptability in Table 2), which extend the capability to suggest partial ER configurations. Enabling the suggestion and / or selection of partial configurations provides the benefit of reduced signaling overhead. The network then provides one or more ER configurations (e.g., similar to Level 1 adaptability), supplemented by requests for partial ER configurations suggested by one or more UEs, which are derived from configurations selected by the network nodes. In various respects, the expected number of iterations (e.g., the number of handovers between configurations) can also be configured by the NW (e.g., similar to Level 1 adaptability). If more than two configurations are provided, handovers are performed sequentially according to the order of their assigned IDs. Thus, an iteration begins with the first configuration and ends with the last available configuration (e.g., configuration #1 -> configuration #2 -> configuration #3 -> configuration #4 -> configuration #1 -> configuration #2 -> etc.).

[0106] The following is an example of pseudocode provided by a network node with Level 3 adaptability for ER configuration. Here, the network node can explicitly configure the conditional switching time based on the UE ER capability (e.g., as shown in Table 2). Here, the conditional switching time between configuration #1 and configuration #2 = 0.5 seconds, the conditional switching time between configuration #2 and configuration #3 = 1 second, the conditional switching time between configuration #3 and configuration #4 = 1 second, and the number of iterations (switches) = 5.

[0107] Configuration #1 : KPI = Mean RSRQ Time window = 0.1s ER KPI trend = declining ER aggregation level = instant Configuration #2 : KPI=90% - ile RSRQ Time window = 1 second ER KPI trend = declining ER aggregation level = record Configuration #3 : KPI = "Recommended Value" Time window = 1 second ER KPI Trend = "Recommended Value" ER aggregation level = "record" Configuration #4 : KPI = 95th percentile RSRP” Time window = 1 second ER KPI trend = "Change magnitude 10%" ER aggregation level = "record" The condition switching time between configuration #1 and configuration #2 is 0.5s. Condition switching time between configuration #2 and configuration #3 = 1 second Condition switching time between configuration #3 and configuration #4 = 1 second Iteration (switching) count = 5 Figure 8 This is a diagram of an example process 800 for establishing an Explainability Report (ER) configuration for Level 3 adaptability, according to one aspect of this disclosure. Process 800 may include configurations 801, 803, and 805 (e.g., configuration #1, configuration #2, and configuration #3) and handover times 802 and 804 (e.g., ER handover times). In this example, the UE indicates supported configuration parameters (e.g., similar to Level 2 adaptability in Table 2) that extend the capability to suggest a complete ER configuration. The network node then provides one or more ER configurations (e.g., similar to Level 2 adaptability), supplemented by requests for one or more UE-suggested complete ER configurations derived from network-selected configurations. In each aspect, the expected number of iterations (e.g., the number of handovers between configurations) may also be configured by the network node, similar to Level 1 and Level 2 adaptability. If more than two configurations are provided, handovers are performed sequentially according to their assigned IDs. Thus, an iteration begins with the first configuration and ends with the last available configuration (e.g., configuration #1 -> configuration #2 -> configuration #3 -> configuration #1 -> configuration #2 -> etc.). The following is an example of pseudocode for ER configuration provided by a network node with Level 3 adaptability. After receiving suggested configurations #2 and #3 from the UE, the network node can decide whether to use the configuration and / or select the corresponding conditional ER report handover time. The conditional handover time between configurations #1 and #2 is 1 second, the conditional handover time between configurations #2 and #3 is 5 seconds, and the number of iterations (handovers) is 3. When the configuration suggested by the UE is unacceptable to the network node, configuration #1 can be used by the network node as a backup configuration.

[0108] Configuration #1 : KPI = Mean RSRQ Time window = 0.1s ER KPI trend = declining ER aggregation level = instant Configuration #2 "Recommended RSRP configuration" Configuration #3 "Recommended RSRQ configuration" Condition switching time between configuration #1 and configuration #2 = 1 second Condition switching time between configuration #2 and configuration #3 = 5s Iteration (switching) count = 3 Figures 6-8 The above description is merely an example, and variations are contemplated within the scope of this disclosure.

[0109] Figure 9 , Figure 10A , Figure 10B , Figure 11A and Figure 11B This is a diagram of an example embodiment of signaling and operation between a UE and a source radio station or source node (e.g., a network node such as a gNodeB (gNB)) according to one aspect of this disclosure.

[0110] The proposed iterative approach reduces downlink (DL) signaling overhead by supporting multiple conditional ER configurations and enabling the UE to autonomously switch between these configurations at predefined times. This allows network nodes to subsequently deactivate or deconfigure configurations determined to be useless, further reducing uplink (UL) signaling load. Additionally, in the iterative degree 2 and degree 3 solutions, the network is enabled to request only the configurations it deems most suitable for a given ML-enabled feature or function. As a result, the associated DL configuration messages are more compact (e.g., smaller and / or shorter). The UE can respond by indicating the selected configuration (e.g., based on its index in a pre-configured list of configurations) within a single combined message sent back to the network node.

[0111] Figure 9 This is a diagram of example operations for network-assisted iterative interpretability reporting. These operations are... Figure 9 The components shown at the top perform the operation, including the UE and network devices (e.g., network nodes, gNBs). Such components can be, for example, combined... Figure 1 and Figure 2 The same component described above or otherwise.

[0112] At operation 901, the network node sends a capability request message to the UE, and the UE receives a capability request message from the network node. This request aims to determine whether the UE supports iterative interpretability reporting, including predefined ER configurations and conditional handover behaviors. In level 1, this request can specifically query the UE's ability to support a list of ER options and relevant timing constraints for adaptive use.

[0113] At operation 902, the UE sends a message indicating ML capabilities (including iterative ER configuration flexibility, such as level 1, level 2, or level 3) to the network node, and the network node receives the message indicating ML capabilities (including iterative ER configuration flexibility) from the UE. This indication specifies the supported level of adaptability (e.g., level 1, level 2, or level 3). This information enables the network to customize its configuration approach based on the UE's flexibility. The message may also include a list of supported ER parameters, a switching timer, or other constraints related to the selected level.

[0114] Operations 903-906 correspond to routine operations including exchanges between the UE and network nodes, configuring the ER configuration in a static manner, such as when the UE does not support iterative ER configuration.

[0115] At operation 903, the UE sends a message to the network node including an indication of the configuration of ML-enabled features, such as those used for ER reporting, and the network node receives a message from the UE including an indication of the configuration of ML-enabled features. This configuration typically corresponds to pre-configured and / or pre-supported ER settings based on the capabilities claimed by the UE. The message may include measurement and reporting parameters associated with the ML functionality, such as the type of KPI, time window, aggregation level, and / or trend options. Additionally, the message may specify information about conditional ER handover behavior and applicable constraints, such as minimum handover intervals. This allows the network to begin evaluating the initial ER while considering the UE's operational boundaries and supported configuration space.

[0116] At operation 904, the UE configures the ML-enabled features and associated ERs, thereby configuring the ER reporting mode. For example, the UE can apply specified KPI metrics, time window durations, trend assessment logic, and / or aggregation levels, as previously agreed with the network node. If multiple settings are provided, the configuration may also involve activating timers and / or thresholds associated with conditional switching between ER configurations.

[0117] In Operation 905, the UE uses configured ML features and generates a configured ER. This operation can be based on real-time observations and internal ML outputs. The ER reflects the statistical interpretation or behavioral trends associated with the decision-making process of the ML model and is formatted according to the selected configuration. The UE can also monitor whether internal or external conditions require switching to an alternative ER configuration based on any previously defined conditional rules.

[0118] At operation 906, the UE sends the generated ER to the network node, and the network node receives the generated ER from the UE. This operation can use a specified UL message format and / or a timing mechanism. If multiple ER configurations are active, ERs can be sent periodically, event-triggered, or in a conditional switching mode. Upon receipt, the network can analyze the ER content to derive insights into the UE's ML behavior, assess performance, and determine whether to maintain, reconfigure, or deactivate ML-enabled features.

[0119] Operations 907-920 correspond to the iterative ER configuration operations for degree 1 adaptability.

[0120] At operation 907, the network node sends a message to the UE including instructions on the configuration of ML-enabled features, along with associated measurements and reports, and the UE receives the same message from the network node. This message may specify which ML function to activate on the UE, and the expected reporting behavior, such as relevant KPIs, time windows, and / or aggregation or trend analysis criteria. The message may also include instructions on how the ER should be aligned with specific network-level objectives, such as optimized beam management, CSI prediction, and / or mobility decisions. Therefore, this operation is used to initiate a coordinated, interpretable reporting process tailored to the operational requirements of the network.

[0121] At operation 908, the UE sends a message to the network node acknowledging support for iterative ER reports with level 1 adaptability, and the network node receives a message from the UE acknowledging support for iterative ER reports with level 1 adaptability. This acknowledgment indicates that the UE is capable of handling a predefined set of ER configurations and can autonomously switch between configurations based on conditional parameters such as timers or thresholds. The message may also include a specific identifier for the supported configuration and / or any constraints on the handover behavior, enabling the network to continue with appropriate configuration strategies. This operation establishes the foundation for controlled iterations without requiring a complete reconfiguration signaling for each change.

[0122] At operation 909, the network node sends a message to the UE including an indication of the conditional ER configuration, which includes a configuration handover timer. The network node also receives a message from the UE containing the indication of the conditional ER configuration, which includes the configuration handover timer. This timer corresponds to a minimum time period during which the UE may not change the ER configuration; for example, it is the minimum duration that must elapse before the UE is permitted to switch from one ER configuration to another, thus preventing excessively frequent changes that could lead to signaling overhead or unstable reporting patterns. The message may also specify the applicable ER configurations that comply with this condition, allowing the UE to autonomously manage the handover logic. This operation ensures that the network node has sufficient time to evaluate the usefulness of each ER before a configuration change occurs.

[0123] At Operation 910, the UE configures the ML-enabled features to be used during operation (e.g., beam management, CSI prediction, or other supported functions) and associated ER configurations. This includes applying network-specified parameters such as selected KPIs, time windows, aggregation levels, and / or configuring handover timers. The UE is prepared to operate under one or more ER settings, managing transitions between them based on received conditional rules. This operation ensures that ML functionality and interpretability reporting align with network expectations while maintaining operational efficiency.

[0124] In Operation 911, the UE uses configured ML-enabled features to generate an ER and reports it based on configuration parameters. The ER reflects the UE's interpretation of the behavior of the ML model, which is captured through selected KPIs, trends, and / or aggregation logic defined in the configuration.

[0125] Operations 912-919 correspond to iterative communication between the UE and the network node to determine and configure the ER configuration. The corresponding configuration switching timer value is used to sequentially switch between the ER configurations in use.

[0126] At operation 912, the UE sends the generated ER corresponding to the first active configuration (e.g., configuration #1) to the network node, and the network node receives the generated ER corresponding to the first active configuration from the UE. This transmission allows the network to begin evaluating interpretive data and assessing its relevance to ongoing monitoring or decision-making processes.

[0127] At operation 913, the UE evaluates the configuration switching timer associated with the currently active ER configuration. The timer is determined to have not yet expired, meaning the UE continues to operate under the current configuration (e.g., configuration #1). Since the configuration remains valid, the UE continues to generate new ERs reflecting updated observations under the same configuration parameters.

[0128] At operation 914, the UE sends a newly generated ER corresponding to the first active configuration to the network node, and the network node receives the newly generated ER corresponding to the first active configuration from the UE. This ER is typically not a retransmission of a previously reported data, but rather a new instance that includes updated metrics, measurements, and / or contextual information aligned with the current reporting window and aggregation parameters. Using multiple ERs under the same configuration allows the network to observe timing patterns and performance consistency before a configuration switch occurs.

[0129] At operation 915, the UE re-evaluates the configuration handover timer and determines that the timer has now expired. Based on the conditional ER handover logic previously defined by the network node, this is signaled to allow the UE to switch to the next ER configuration in the sequence (e.g., configuration #2).

[0130] At operation 916, the UE generates a new ER based on the second currently active configuration (e.g., configuration #2) and sends the new ER to the network node, which then receives the new ER from the UE. This report reflects a different set of KPIs, trends, and / or aggregation logic, depending on how configuration #2 differs from the previous active settings. Switching to the new configuration ensures report diversity, enabling the network node to compare and evaluate the relative effectiveness of alternative ER profiles.

[0131] At Operation 917, the network node evaluates one or more ERs received from the UE across all configured reporting modes. This evaluation can be performed solely based on the content of the ER, such as reported KPIs, trends, and / or statistical outputs. In various aspects, the evaluation can be based on and / or incorporate external inputs, including performance monitoring data from the same UE / ER and / or information collected from UEs using the same ML-enabled features and their ER / performance reports. By leveraging both direct and contextual information, the network node gains a comprehensive understanding of the underlying ML model's behavior and assesses its impact and applicability to ongoing or future network-level decisions.

[0132] At Operation 918, the network node determines which configuration provides the most informative and relevant insight into the UE's ML-enabled behavior. The selected configuration is considered the expected ER configuration for continuing ER reporting under the current operating conditions.

[0133] At operation 919, the network node sends a message to the UE instructing the UE to reconfigure its reporting behavior to use only a specific ER configuration (e.g., configuration #2), and the UE receives the message from the network node instructing the UE to reconfigure its reporting behavior to use only a specific ER configuration. This reconfiguration reflects the network node's choice of the most informative and effective settings, as determined through previous evaluations. By limiting future ER transmissions to the selected configuration, the network node thereby reduces signaling overhead while maintaining high-value interpretable data.

[0134] At operation 920, the UE sends an ER corresponding to the selected ER configuration (e.g., configuration #2) to the network node, and the network node receives the ER corresponding to the selected ER configuration from the UE. The sent ER reflects metrics, trends, and / or aggregation parameters specifically defined by the selected configuration. This provides the benefit of simplified signaling, as the network node receives consistent and specifically tailored interpretable information without the unnecessary overhead associated with multiple configurations. Additionally, this selective reporting ensures that the network node obtains the most relevant insights needed to effectively monitor, manage, and optimize the ML-enabled features in the UE.

[0135] Figure 9 The operations described are merely examples, and variations are contemplated within the scope of this disclosure. In embodiments, the operations may include... Figure 9 Other operations not shown. In embodiments, operations may not include... Figure 9 Each operation is shown. In an embodiment, the operation can be in conjunction with... Figure 9 Different sequences are shown for implementation. These and other embodiments are contemplated within the scope of this disclosure.

[0136] The operation is described below from the UE's perspective. From this perspective, one approach may include: the user equipment (UE) sending an instruction to the network node regarding the UE's ability to iterate with the network node to determine the interpretability report (ER) configuration (e.g., Figure 9 Operation 902); and iteratively communicating with network nodes to determine the ER configuration used to report machine learning (ML) enabled features implemented at the UE (e.g., Figure 9 (Operation 912-Operation 919).

[0137] The operation is described below from the perspective of the network node. From this perspective, one approach may include: the network node receiving instructions from the user equipment (UE) regarding the UE's ability to iterate with the network node to determine the interpretability report (ER) configuration (e.g., Figure 9 (Operation 902); and iteratively communicate with the UE to determine the ER configuration used to report machine learning (ML) enabled features implemented at the UE (e.g., Figure 9(Operation 912-Operation 919).

[0138] Figure 10A and Figure 10B This is a diagram of example operations for network-assisted iterative interpretability reporting. These operations are... Figure 10A and Figure 10B The components shown at the top perform the operation, including the UE and network devices (e.g., network nodes, gNBs). Such components can be, for example, combined... Figure 1 and Figure 2 The same component described above or otherwise.

[0139] At operation 1001, the network node sends a capability request message to the UE, and the UE receives the capability request message from the network node. This request aims to determine whether the UE supports iterative interpretability reporting, including predefined ER configurations and conditional switching behaviors. In level 2, this request can query the UE's ability to support partial configuration flexibility, where the network node specifies specific fixed ER parameters while allowing the UE to autonomously select or suggest additional ER parameters within defined constraints.

[0140] At operation 1002, the UE sends a message to the network node indicating ML capabilities (including iterative ER configuration flexibility, e.g., level 1, level 2, or level 3), and the network node receives the message indicating ML capabilities (including iterative ER configuration flexibility) from the UE. For level 2 adaptability, this indication confirms the UE's ability to support partial ER configuration, whereby the UE can autonomously select or suggest values ​​for specific ER parameters while conforming to other ER parameters specified by the network node. This information allows the network node to leverage the UE's partial flexibility to minimize signaling overhead. The message may additionally include specific ER parameters that can be used based on the UE's selection, handover timers, or any operational constraints associated with partial configuration capabilities.

[0141] Operations 1003-1025 correspond to iterative communication between the UE and the network node to determine and configure the ER configuration. In these operations, the network node provides specific, fixed ER configuration parameters, while the UE autonomously proposes or selects additional ER parameters within previously indicated constraints. Corresponding configuration switching timer values ​​are used to sequentially switch between the ER configurations in use.

[0142] At operation 1003, the UE sends a message to the network node including an indication of the configuration of ML-enabled features, such as those used for ER reporting, and the network node receives a message from the UE including an indication of the configuration of ML-enabled features. This configuration typically corresponds to a partial ER configuration based on the UE's claimed Level 2 adaptability capabilities, with some parameters fixed by the network node and others chosen or proposed autonomously by the UE. The message may include measurement and reporting parameters associated with the ML functionality, such as the type of KPI, time window, aggregation level, and / or trend options. Additionally, the message may specify information about conditional ER handover behavior and applicable constraints, such as minimum handover intervals. This allows the network node to begin evaluating the initial ER while considering the UE's operational boundaries and supported partial configuration capabilities.

[0143] At operation 1004, the UE sends a message to the network node indicating that the UE supports iterative ER configuration with level 2 adaptability, and the network node receives a message from the UE indicating that the UE supports iterative ER configuration with level 2 adaptability. Specifically, this message confirms that the UE can operate within a partially flexible ER configuration, where specific ER parameters are fixed by the network node, while the UE autonomously selects or suggests additional parameter values ​​consistent with the constraints defined by its capabilities. The UE may also include information detailing which ER parameters or configurations are eligible for autonomous selection, enabling the network node to clearly understand the degree of flexibility and optimize subsequent iterative configuration signaling.

[0144] At operation 1005, the network node sends a message to the UE indicating one or more fully fixed ER configurations and one or more partially flexible ER configurations, and the UE receives the message from the network node indicating one or more fully fixed ER configurations and one or more partially flexible ER configurations. The fully fixed ER configurations correspond to parameters that remain static and are not subject to iterative modification or negotiation. The partially flexible ER configurations include parameters partially defined by the network node, allowing certain additional parameters to be opened for selection or suggestion by the UE within previously declared capability constraints. Therefore, subsequent configuration iterations between the UE and the network node focus specifically on determining and finalizing these remaining open parameters for the partially flexible ER configurations.

[0145] Operations 1006-1012 correspond to configuration iterations between the UE and the network node.

[0146] In Operation 1006, the UE acknowledges receiving fixed ER configuration information from the network node and considers any partially fixed ER configuration indicated by the network node. The UE autonomously selects or proposes values ​​for the remaining open parameters of the ER configuration. The UE makes this selection based on its previously reported capabilities, ensuring compliance with network-defined constraints and parameters already fixed by the network node. This operation effectively initiates iterative negotiation to finalize the partially flexible ER configuration.

[0147] At operation 1007, the UE sends a message to the network node indicating (configuration #1, configuration #2, and / or configuration #3) a plurality of ER configuration proposals detailing parameter values ​​autonomously selected and / or suggested by the UE, and the network node receives a message from the UE detailing (multiple) ER configuration proposals detailing parameter values ​​autonomously selected and / or suggested by the UE. These ER configuration proposals reflect the UE's capability constraints, previous instructions received from the network node, and the degree of flexibility permitted under Level 2 adaptability. By explicitly transmitting the selected ER parameters, the UE enables the network node to evaluate the alignment of the proposals with network operational requirements and initiate subsequent negotiation rounds if necessary.

[0148] At operation 1008, the network node examines (multiple) ER configuration proposals and makes selections for the remainder of the ER configuration, such as parameter values ​​for any unresolved parts of the ER configuration. This ensures that the selections are closely aligned with network-specific operational objectives, target performance metrics, and reporting requirements.

[0149] At operation 1009, the network node sends a message to the UE indicating whether it accepts or rejects the most recent ER configuration proposal provided by the UE, and the UE receives a message from the network node indicating whether it accepts or rejects the most recent ER configuration proposal provided by the UE. If the network node accepts the proposal, the iterative negotiation ends successfully, and the process proceeds directly to operation 1013. Conversely, if the network node rejects the proposal, the process continues to operation 1010, initiating another round of negotiation.

[0150] At operation 1010, based on the rejection at operation 1009, which was triggered by the rejection transmitted by the network node at operation 1009, the UE autonomously selects alternative parameter values ​​or combinations for those ER configuration parameters that remain unresolved (e.g., reselecting the remaining ER configuration parts / parameters). In doing so, the UE considers previously stated capability constraints, previous instructions from the network node, and feedback indicated by the network node's most recent rejection.

[0151] At operation 1011, the UE sends a message to the network node indicating a revised (“new”) ER configuration proposal, and the network node receives the revised (“new”) ER configuration proposal from the UE. The revised proposal explicitly indicates updated parameter selections designed to better meet the operational requirements of the network node (as implied by the previous rejection).

[0152] In operation 1012, the network node evaluates the revised ER configuration proposal and selects parameter values ​​for any remaining open configuration elements, thereby ensuring alignment with desired network behavior, resource management considerations, and interpretability reporting requirements. The network node then sends an appropriate accept or reject message to the UE, instructing the UE on its decision regarding the latest ER configuration proposal. If the instruction is accepted, the iterative negotiation successfully concludes, and the process proceeds to operation 1013. If the instruction is rejected, the process returns to operation 1010, prompting the UE to perform additional reselection of unresolved parameters.

[0153] The iterations of Operations 1006-1012 continue until the network nodes select and / or agree on one or more ER configurations or the maximum number of iterations is reached. In scenarios where the maximum number of iterations is reached without mutual agreement on any ER configuration, the UE adopts the default ER configuration previously specified by the network node. The existence of this alternative configuration ensures that the interpretability reporting mechanism remains operational even without successful iteration convergence, thereby maintaining reliable and consistent network-level visibility into the UE-side ML behavior.

[0154] At operation 1013, the UE configures the agreed-upon ER configuration. This configuration includes all previously negotiated parameters, which may include fully fixed ER parameters initially provided by the network node, as well as some flexible parameters chosen or proposed by the UE and accepted by the network node. The UE applies the finalized ER configuration to manage subsequent interpretability reporting behavior during ongoing ML-enabled operations.

[0155] In Operation 1014, the UE employs configured ML-enabled features and generates interpretability reports during ML operations using agreed-upon ER configurations. The ER configurations used by the UE can correspond to any previously defined configuration (e.g., configurations explicitly fixed by the network node and / or partially flexible configurations generated autonomously by the UE and accepted by the network node). By operating under these mutually agreed-upon ER configurations, the UE ensures consistent and relevant reporting, thereby providing the network node with actionable insights into the behavior, effectiveness, and performance of the ML-enabled features.

[0156] Operations 1015-1025 correspond to the reporting iterations between the UE and the network node, reflecting the... Figure 9The process is similar to operation 912-919.

[0157] At operation 1015, the UE sends the generated ER corresponding to the first active configuration (e.g., configuration #1) to the network node, and the network node receives the generated ER corresponding to the first active configuration from the UE.

[0158] At operation 1016, the UE evaluates the configuration switching timer associated with the currently active ER configuration. The timer is determined to have not yet expired, meaning the UE continues to operate under the current configuration (e.g., configuration #1). Since the configuration remains valid, the UE continues to generate new ERs reflecting updated observations under the same configuration parameters.

[0159] At operation 1017, the UE sends the newly generated ER corresponding to the first active configuration to the network node, and the network node receives the newly generated ER corresponding to the first active configuration from the UE.

[0160] At operation 1018, the UE re-evaluates the configuration handover timer and determines that the timer has now expired. Based on the conditional ER handover logic previously defined by the network node, this is signaled to allow the UE to switch to the next ER configuration in the sequence (e.g., configuration #2).

[0161] At operation 1019, the UE generates a new ER based on the second currently active configuration (e.g., configuration #2), sends the new ER to the network node, and the network node receives the new ER from the UE.

[0162] In operation 1020, the UE generates another ER based on the configuration of the second current activity reflecting the updated observation (e.g., configuration #2) and sends the ER to the network node, and the network node receives the ER from the UE.

[0163] At operation 1021, the UE re-evaluates the configuration handover timer and determines that the timer has now expired. Based on the conditional ER handover logic previously defined by the network node, this is signaled to allow the UE to switch to the next ER configuration in the sequence (e.g., configuration #3).

[0164] At operation 1022, the UE generates a new ER based on the third currently active configuration (e.g., configuration #3) and sends the ER to the network node, and the network node receives the ER from the UE.

[0165] At operation 1023, the network node evaluates one or more ERs received from the UE across all configured reporting modes (configuration #1, configuration #2, and / or configuration #3).

[0166] At operation 1024, the network node determines which configuration provides the most informative and relevant insight into the behavior of ML-enabled UE.

[0167] At operation 1025, the network node sends a message to the UE instructing the UE to reconfigure its reporting behavior to use only one specific ER configuration (e.g., configuration #3), and the UE receives the message from the network node instructing the UE to reconfigure its reporting behavior to use only one specific ER configuration. This reconfiguration reflects the network node's selection of the most informative and effective settings, as determined through previous evaluations.

[0168] At operation 1026, the UE sends the ER corresponding to the selected ER configuration (e.g., configuration #3) to the network node, and the network node receives the ER corresponding to the selected ER from the UE. This provides the benefit of simplified signaling because the network node receives consistent and specifically tailored interpretable information without the unnecessary overhead associated with multiple configurations.

[0169] Figure 10A and Figure 10B The operations described are merely examples, and variations are contemplated within the scope of this disclosure. In embodiments, the operations may include... Figure 10A and Figure 10B Other operations not shown. In embodiments, operations may not include... Figure 10A and Figure 10B Each operation is shown. In an embodiment, the operation can be performed in conjunction with... Figure 10A and Figure 10B The different sequences shown are used to implement this. These and other embodiments are contemplated within the scope of this disclosure.

[0170] The operation is described below from the UE's perspective. From this perspective, one approach may include: the user equipment (UE) sending an instruction to the network node regarding the UE's ability to iterate with the network node to determine the interpretability report (ER) configuration (e.g., Figure 10A Operation 1002); iteratively communicate with network nodes to determine the ER configuration used to report machine learning (ML) enabled features implemented at the UE (e.g., Figure 10A and Figure 10B Operations 1003-1025), wherein iterative communication includes the UE receiving from the network node an indication of at least one partial ER configuration and at least one configuration switching timer (e.g., Figure 10A (Operation 1005).

[0171] The operation is described below from the perspective of the network node. From this perspective, one approach may include: the network node receiving instructions from the user equipment (UE) regarding the UE's ability to iterate with the network node to determine the interpretability report (ER) configuration (e.g., Figure 10A Operation 1002); and iteratively communicating with the UE to determine the ER configuration used to report machine learning (ML) enabled features implemented at the UE (e.g., Figure 10A and Figure 10B Operations 1003-1025), wherein iterative communication includes the network node sending an indication to the UE of at least one partial ER configuration and at least one configuration switching timer (e.g., Figure 10A (Operation 1005).

[0172] Figure 11A and Figure 11B This is a diagram of example operations for network-assisted iterative interpretability reporting. These operations are... Figure 11A and Figure 11B The components shown at the top perform the operation, including the UE and network devices (e.g., network nodes, gNBs). Such components can be, for example, combined... Figure 1 and Figure 2 The same component described above or otherwise.

[0173] At operation 1101, the network node sends a capability request message to the UE and receives a capability request message from the UE. This request aims to determine whether the UE supports iterative interpretability reporting, including predefined ER configurations and conditional handover behaviors. In level 3, the capability request can specifically query the UE's ability to autonomously suggest or generate complete ER configurations. These suggested configurations may include a complete set of parameters, which the UE independently determines based on examples, guidelines, and / or instructions provided by the network node.

[0174] At operation 1102, the UE sends a message to the network node indicating ML capabilities (including iterative ER configuration flexibility, e.g., level 1, level 2, or level 3), and the network node receives the message indicating ML capabilities (including iterative ER configuration flexibility) from the UE. For level 3 adaptability, this indication can confirm the UE's ability to autonomously propose or generate a complete ER configuration (including all relevant parameters and values). The UE also indicates support for full flexibility in defining ER parameters, allowing the network node to provide minimal or example-based guidance. This enables highly customized, interpretable reporting that closely adapts to the specific operational preferences and objectives of the network node.

[0175] Operations 1103-1023 correspond to iterative communication between the UE and the network node to determine and configure the ER configuration.

[0176] At operation 1103, the UE sends a message to the network node including an indication of the configuration of features enabled for ML, such as those used for ER reporting, and the network node receives a message from the UE including an indication of the configuration of features enabled for ML. This configuration typically corresponds to a fully autonomous ER configuration generated by the UE based on its claimed Level 3 adaptive capabilities, where all or substantially all ER parameters are independently selected or proposed by the UE. The message may include measurement and reporting parameters associated with ML functionality, such as KPI type, time window, aggregation level, and / or trend options, each determined autonomously by the UE. Additionally, the message may specify information regarding conditional ER handover behavior and applicable constraints, such as minimum handover intervals. This comprehensive autonomous proposal allows the network node to begin evaluating the initial ER while clearly understanding the full range of UE capabilities and utilizing maximum UE flexibility in configuration selection.

[0177] At operation 1104, the UE sends a message to the network node including an indication that the UE supports iterative ER configuration with level 3 adaptive capability, and the network node receives a message from the UE including an indication that the UE supports iterative ER configuration with level 3 adaptive capability. Specifically, this message confirms that the UE can operate under fully autonomous ER configuration conditions, where the UE independently proposes a complete set of ER parameters based on minimal guidance or example instructions from the network node. The UE can also specify detailed information about the degree of autonomous selection capability, such as supported KPI options, aggregation methods, reporting intervals, and trend assessment parameters. By explicitly providing this information, the UE ensures that the network node clearly understands the full range of configuration autonomy available for the level 3 iterative ER process.

[0178] At operation 1105, the network node sends a message including an ER configuration request to the UE, and the UE receives the message including an ER configuration request from the network node. This message includes one or more fully fixed (e.g., alternate) configurations (e.g., predefined by the network node) and a request for the UE to propose a preferred full ER configuration (for the UE to autonomously propose a preferred full ER configuration). Additionally, the ER configuration request includes a configuration switching timer. Therefore, the configuration iteration will focus on the selection and / or generation of the UE's preferred full ER configuration. In various aspects, the network node can provide indications about the target ER configuration, which may include example inputs and outputs of ML features, as well as the expected corresponding ER content. This can help the UE autonomously generate a suitable proposal.

[0179] Operations 1106-1112 correspond to configuration iterations between the UE and the network node.

[0180] In operation 1106, the UE acknowledges receiving the request and searches for the ER configuration that best matches the network node's request.

[0181] At operation 1107, the UE sends a message to the network node indicating (multiple) ER configuration proposals (configuration #1, configuration #2, and / or configuration #3) detailing parameter values ​​autonomously selected and / or suggested by the UE, and the network node receives a message from the UE indicating (multiple) ER configuration proposals (configuration #1, configuration #2, and / or configuration #3) detailing parameter values ​​autonomously selected and / or suggested by the UE. These ER configuration proposals reflect the UE's capability constraints, previous instructions received from the network node, and the high degree of flexibility permitted under Level 3 adaptability.

[0182] At operation 1108, the network node checks (multiple) ER configuration proposals and / or selects any additional parts and / or parameters.

[0183] At operation 1109, the network node sends a message to the UE indicating whether it accepts or rejects the most recent ER configuration proposal provided by the UE, and the UE receives a message from the network node indicating whether it accepts or rejects the most recent ER configuration proposal provided by the UE. If the network node accepts the proposal, the iterative negotiation ends successfully, and the process proceeds directly to operation 1113. Conversely, if the network node rejects the proposal, the process continues to operation 1110, initiating another round of negotiation.

[0184] At operation 1110, based on the rejection at operation 1109, which was triggered by the rejection transmitted by the network node at operation 1109, the UE autonomously selects alternative parameter values ​​or combinations for those ER configuration parameters that remain unresolved (e.g., reselecting the remaining ER configuration parts / parameters).

[0185] At operation 1111, the UE sends a message to the network node indicating a revised (“new”) ER configuration proposal, and the network node receives the revised ER configuration proposal from the UE. The revised proposal explicitly indicates updated parameter selections designed to better meet the operational requirements of the network node (as implied by the previous rejection).

[0186] In operation 1112, the network node evaluates the revised ER configuration proposal and / or selects parameter values ​​for any remaining open configuration elements to ensure alignment with desired network behavior, resource management considerations, and interpretability reporting requirements. The network node then sends an acceptance or rejection message to the UE, instructing the UE on its decision regarding the latest ER configuration proposal. If acceptance is indicated, the iterative negotiation successfully concludes, and the process proceeds to operation 1113. If rejection is indicated, the process returns to operation 1110, prompting the UE to perform additional reselection of unresolved parameters.

[0187] The iterations of Operations 1106-1112 continue until the network node selects and / or agrees on one or more ER configurations or the maximum number of iterations is reached. In scenarios where the maximum number of iterations is reached without mutual agreement on any ER configuration, the UE adopts the default ER configuration previously specified by the network node.

[0188] At operation 1113, the UE configures the agreed-upon ER configuration. These configurations include all previously negotiated parameters, such as the ER configuration proposed entirely by the UE. The UE applies the finalized ER configuration to manage subsequent interpretability reporting behavior during ongoing ML-enabled operations.

[0189] In Operation 1114, the UE employs a configured ML-enabled feature and generates an interpretability report during ML operation using an agreed-upon ER configuration. The ER configuration used by the UE can correspond to any previously defined configuration (e.g., an ER configuration entirely proposed by the UE). By operating under these mutually agreed-upon ER configurations, the UE ensures consistent and relevant reporting, thereby providing network nodes with actionable insights into the behavior, effectiveness, and performance of the ML-enabled feature.

[0190] Operations 1115-1123 correspond to the reporting iterations between the UE and the network node, reflecting the... Figure 9 Operations 912-919 and Figure 10A and Figure 10B The process is similar to operation 1015-operation 1025.

[0191] At operation 1115, the UE sends the generated ER corresponding to the first active configuration (e.g., configuration #2) to the network node, and the network node receives the generated ER corresponding to the first active configuration from the UE.

[0192] At operation 1116, the UE evaluates the configuration switching timer associated with the currently active ER configuration. The timer is determined to have not yet expired, meaning the UE continues to operate under the current configuration (e.g., configuration #2). Since the configuration remains valid, the UE continues to generate new ERs reflecting updated observations under the same configuration parameters.

[0193] At operation 1117, the UE sends the newly generated ER corresponding to the first active configuration to the network node, and the network node receives the newly generated ER corresponding to the first active configuration from the UE.

[0194] At operation 1118, the UE re-evaluates the configuration handover timer and determines that the timer has now expired. Based on the conditional ER handover logic previously defined by the network node, this is signaled to allow the UE to switch to the next ER configuration in the sequence (e.g., configuration #3).

[0195] At operation 1119, the UE generates a new ER according to the second currently active configuration (e.g., configuration #3) and sends the ER to the network node, and the network node receives the ER from the UE.

[0196] In operation 1120, the UE generates another ER based on the configuration of the second current activity reflecting the updated observation (e.g., configuration #3), and sends the ER to the network node, and the network node receives the ER from the UE.

[0197] At Operation 1121, the network node evaluates one or more ERs received from the UE across all configured reporting modes (Configuration #2 and / or Configuration #3).

[0198] At operation 1122, the network node determines which configuration provides the most informative and relevant insight into the behavior of ML-enabled UE.

[0199] At operation 1123, the network node sends a message to the UE instructing the UE to reconfigure its reporting behavior to use only one specific ER configuration (e.g., configuration #3), and the UE receives the message from the network node instructing the UE to reconfigure its reporting behavior to use only one specific ER configuration. This reconfiguration reflects the network node's selection of the most informative and effective settings, as determined through previous evaluations.

[0200] At operation 1124, the UE sends an ER corresponding to the selected ER configuration (e.g., configuration #3) to the network node, and the network node receives an ER corresponding to the selected ER configuration from the UE. This provides the benefit of simplified signaling because the network node receives consistent and specifically tailored interpretable information without the unnecessary overhead associated with multiple configurations.

[0201] Figure 11A and Figure 11B The operations described are merely examples, and variations are contemplated within the scope of this disclosure. In embodiments, the operations may include... Figure 11A and Figure 11B Other operations not shown. In embodiments, operations may not include... Figure 11A and Figure 11B Each operation is shown. In an embodiment, the operation can be performed in conjunction with... Figure 11A and Figure 11B The different sequences shown are implemented. These and other embodiments are contemplated within the scope of this disclosure.

[0202] The proposed iterative approach offers several key advantages. First, iteratively, it implements an over-the-air “bounded search” method to identify the optimal ER information content generated by the UE. This allows network nodes to make precise and informed decisions regarding Radio Resource Management (RRM), such as triggering a handover to a new ML configuration or activating a backup non-ML operation mode when necessary. Second, network nodes maintain complete control over the iterative process. For example, network nodes can explicitly set fixed ER configuration parameters and select handover timer values, ensuring full flexibility to dynamically adjust based on the network node's current traffic conditions and signaling load.

[0203] Furthermore, this iterative approach significantly reduces downlink (DL) signaling overhead. This reduction is achieved by providing multiple conditional ER configurations, which the UE autonomously switches between at predefined intervals. The network node is then able to deactivate any ER configuration determined to be less beneficial, further reducing uplink (UL) signaling overhead as the UE ceases sending unnecessary reports. Additionally, the degree 2 and degree 3 iterative solutions offer further efficiency advantages. Specifically, these solutions allow the network node to request only the ER configuration deemed most relevant to the features enabled by the specific ML in use from the UE. As a result, DL configuration messages are more concise, as the network node sends shorter messages specifying only the selected parameters. Furthermore, the UE can return configuration selections to the network node in a single combined message by referencing an index from a pre-configured capability-based list, further optimizing overall signaling efficiency.

[0204] The operation is described below from the UE's perspective. From this perspective, one approach may include: the user equipment (UE) sending an instruction to the network node regarding the UE's ability to iterate with the network node to determine the interpretability report (ER) configuration (e.g., Figure 11A (Operation 1102); iteratively communicate with network nodes to determine the ER configuration used to report machine learning (ML) features implemented at the UE (e.g., Figure 11A and Figure 11B Operations 1103-1123), wherein iterative communication includes the UE receiving at least two ER configuration requests and at least one configuration switching timer from the network node (e.g., Figure 11A (Operation 1104).

[0205] The operation is described below from the perspective of the network node. From this perspective, one approach may include: the network node receiving from the user equipment (UE) an indication of the UE's ability to iterate with the network node to determine the interpretability report (ER) configuration (e.g., Figure 11A(Operation 1102); and iteratively communicate with the UE to determine the ER configuration used to report machine learning (ML) enabled features implemented at the UE (e.g., Figure 11A and Figure 11B Operations 1103-1123), wherein iterative communication includes the network node sending at least two ER configuration requests and a configuration handover timer to the UE (e.g., Figure 11A (Operation 1104).

[0206] Figure 12 This is a block diagram of a wireless station or node 1200 (e.g., UE, user equipment, AP, BS, eNB, gNB, RAN node, network node, TRP, or other node) according to one aspect of this disclosure. The network node 120 (e.g., the wireless station) may include, for example, one or more radio frequency (RF) or wireless transceivers 1202A, 1202B (e.g., RF transceivers), wherein each wireless transceiver includes a transmitter for transmitting signals and a receiver for receiving signals. The wireless station also includes a processor 1204 and / or a control unit / entity to execute instructions or software and control the transmission and reception of signals, and a memory 1206 to store data and / or instructions.

[0207] Processor 1204 may also make decisions or determinations, generate frames, packets, or messages for transmission, decode received frames or messages for further processing, and perform other tasks or functions described herein. For example, processor 1204 (which may be a baseband processor) may generate messages, packets, frames, or other signals for transmission via wireless transceiver 1202 (1202A or 1202B). Processor 1204 may control the transmission of signals or messages on a wireless network and may control the reception of signals or messages, etc., via a wireless network (e.g., after down-conversion by wireless transceiver 1202). Processor 1204 may be programmable and capable of executing software or other instructions stored in memory or other computer media to perform the various tasks and functions described above, such as one or more of the tasks or methods described above. Processor 1204 may be (or may include) hardware, programmable logic, a programmable processor executing software or firmware, and / or any combination of these. Using other terms, processor 1204 and wireless transceiver 1202 together may be considered, for example, a wireless transmitter / receiver system.

[0208] Additionally, refer to Figure 12 The controller (or processor) 1208 can execute software and instructions, and can provide overall control for the station or node 1200, and can provide... Figure 12Other systems, not shown, provide control, such as controlling input / output devices (e.g., a display, a keypad), and / or can execute software for one or more applications that may be available on the wireless station or node 1200, such as, for example, an email program, an audio / video application, a word processor, an IP voice application, or other applications or software.

[0209] Additionally, a storage medium may be provided, which includes stored instructions that, when executed by a controller or processor, enable the processor 1204 or other controller or processor to perform one or more of the functions or tasks described above.

[0210] According to another example embodiment, the RF or (multiple) wireless transceivers 1202A / 1202B can receive signals or data and / or transmit or send signals or data. The processor 1204 (and possibly the transceivers 1202A / 1202B) can control the RF or wireless transceivers 1202A or 1202B to receive, transmit, broadcast, or send signals or data.

[0211] Example embodiments are provided or described for each example method, including: apparatus (e.g., Figure 12 (of 1200), including components for performing any method (e.g., Figure 12 The processor 1204, wireless transceiver 1202A and / or 1202B and / or memory 1206; non-transitory computer-readable storage medium (e.g., Figure 12 The memory 1206 includes instructions stored thereon, which are processed by at least one processor (e.g., Figure 12 The processor 1204 is configured to cause the computing system (e.g., Figure 12 (1200) executes any example method; and the device (e.g., Figure 12 (of the 1200), including at least one processor (e.g., Figure 12 The processor 1204) and at least one memory including computer program code (e.g., Figure 12 The memory (1206) and computer program code are configured together with at least one processor (1204) to enable the device (e.g., 1200) to perform at least any of the example methods.

[0212] Other embodiments of this disclosure include the following examples. Unless otherwise indicated, a "component" may be implemented by a processor and a memory storing instructions executable by the processor. Components for transmitting or receiving may be implemented by a transceiver.

[0213] Example 1.1. A method comprising: The user equipment (UE) sends an instruction to the network node regarding the ability to iterate between the UE and the network node to determine the interpretability report (ER) configuration; and Iteratively communicate with network nodes to determine ER configuration for reporting machine learning (ML) enabled features implemented at the UE.

[0214] Example 1.1. A method comprising: The user equipment (UE) sends an instruction to the network node regarding the ability to iterate between the UE and the network node to determine the interpretability report (ER) configuration; and Iterative communication with network nodes to determine ER configuration for reporting machine learning (ML) features implemented at the UE includes: The UE receives at least two ER configuration requests and at least one configuration switching timer from the network node.

[0215] Example 1.2. According to the method of Example 1.1, wherein the at least two ER configuration requests include an indication of at least one fixed ER configuration in the fixed ER configurations.

[0216] Example 1.3. According to the method of Example 1.1 or Example 1.2, wherein the at least two ER configuration requests include a request for a complete ER configuration proposed for the UE that is entirely configured by the UE.

[0217] Example 1.4. According to any one of Examples 1.1 to 1.3, where at least one configuration switching timer corresponds to a minimum duration during which the UE cannot change the ER configuration or cannot change the ER configuration parameters.

[0218] Example 1.5. According to any one of Examples 1.1 through 1.4, the iterative communication further includes: At least one ER configuration is configured by the UE, and the at least one ER configuration is entirely configured by the UE.

[0219] Example 1.6. According to any one of Examples 1.1 to 1.5, the iterative communication further includes: The UE sends a first proposal to the network node using a first ER configuration out of at least two ER configurations, wherein the first ER configuration is entirely configured by the UE; and The UE receives an indication of approval or rejection of the first proposal from the network node.

[0220] Example 1.7. The method according to Example 1.6, wherein the UE receives an indication of approval of the first proposal from the network node, and wherein the method further includes: The UE selects a first ER configuration based on a first proposal for reporting ML-enabled features implemented at the UE.

[0221] Example 1.8. The method according to Example 1.6, wherein the UE receives an indication of rejection of the first proposal from the network node, and wherein the method further includes: The UE sends a second proposal to the network node using the second ER configuration from at least two ER configurations, which is entirely configured by the UE.

[0222] Example 1.9. Following the method in Example 1.8, it also includes: The UE sends at least two interpretability reports to the network node.

[0223] Example 1.10. Following the method of Example 1.8, iterative communication further includes: When the maximum number of iterations for iterative communication is reached, the UE sends the default ER configuration to the network node.

[0224] Example 1.11. The method of Example 1.9, wherein sending at least two interpretability reports includes: Before one of the configuration switching timers expires, the UE sends a first interpretability report based on the first ER configuration to the network node.

[0225] Example 1.12. The method of Example 1.11, wherein sending at least two interpretability reports further includes: After one of the configuration switching timers expires at least once, the UE sends a second interpretability report based on the second ER configuration to the network node.

[0226] Example 1.13. According to any one of Examples 1.9 to 1.12, the iterative communication further includes: The UE receives an instruction from the network node to use only one of the at least two ER configurations.

[0227] Example 1.14. According to the method of Example 1.13, the instruction to use only one of the at least two ER configurations is an instruction to use only the second ER configuration.

[0228] Example 1.15. An apparatus comprising: At least one processor; and At least one memory stores instructions that, when executed by at least one processor, cause the device to perform at least one of the methods according to Examples 1.1 to 1.14.

[0229] Example 1.16. A processor-readable medium storing instructions that, when executed by at least one processor of the device, cause the device to perform at least the method according to any one of Examples 1.1 to 1.14.

[0230] Example 2.1. A method comprising: The network node receives an indication from the user equipment (UE) regarding the ability to iterate between the UE and the network node to determine the interpretability report (ER) configuration; and Iterative communication with the UE to determine the ER configuration for reporting machine learning (ML) enabled features implemented at the UE includes: The network node sends at least two ER configuration requests and at least one configuration switching timer to the UE.

[0231] Example 2.2. According to the method of Example 2.1, wherein the at least two ER configuration requests include an indication of at least one fixed ER configuration in the fixed ER configurations.

[0232] Example 2.3. According to the method of Example 2.1 or Example 2.2, wherein the at least two ER configuration requests include a request for a complete ER configuration proposed for the UE that is entirely configured by the UE.

[0233] Example 2.4. According to any one of Examples 2.1 to 2.3, at least one configuration switching timer corresponds to a minimum duration during which the UE cannot change the ER configuration or cannot change the ER configuration parameters.

[0234] Example 2.5. According to any one of Examples 2.1 through 2.4, the iterative communication further includes: The network node receives a first proposal from the UE using a first ER configuration, which is entirely configured by the UE; and The network node sends an indication to the UE to approve or reject the first proposal.

[0235] Example 2.6. The method according to Example 2.5, wherein the network node sends an indication of rejection of the first proposal to the UE, and wherein the method further includes: The network node receives a second proposal from the UE using the second ER configuration from at least two ER configurations, the second ER configuration being entirely proposed by the UE.

[0236] Example 2.7. Following the method of Example 2.6, iterative communication further includes: The network node receives at least two interpretability reports from the UE.

[0237] Example 2.8. Following the method of Example 2.6, iterative communication further includes: When the maximum number of iterations for iterative communication is reached, the network node receives the default ER configuration from the UE.

[0238] Example 2.9. Following the method of Example 2.7, where receiving at least two interpretability reports includes: Before one of the configuration switching timers expires, the network node receives a first interpretability report based on the first ER configuration from the UE.

[0239] Example 2.10. According to the method of Example 2.9, receiving at least two interpretability reports further includes: After one of the configuration switching timers expires at least once, the network node receives a second interpretability report from the UE based on the second ER configuration.

[0240] Example 2.11. According to any one of Examples 2.7 to 2.10, the iterative communication further includes: At least two interpretability reports should be evaluated by network nodes; and The network node sends an instruction to the UE to use only one of the at least two ER configurations.

[0241] Example 2.12. According to the method of Example 2.11, the instruction to use only one of the at least two ER configurations is an instruction to use only the second ER configuration.

[0242] Example 2.13. An apparatus comprising: At least one processor; and At least one memory stores instructions that, when executed by at least one processor, cause the device to perform at least one of the methods according to Examples 2.1 to 2.12.

[0243] Example 2.14. A processor-readable medium storing instructions that, when executed by at least one processor of the device, cause the device to perform at least the method according to any one of Examples 2.1 to 2.12.

[0244] Example 3.1. A user equipment (UE) includes: A component for sending an indication from the UE to the network node regarding the UE's ability to iterate with the network node to determine the Interpretability Report (ER) configuration; and Components for iteratively communicating with network nodes to determine ER configuration for reporting machine learning (ML) features implemented at the UE, including: A component for receiving at least two ER configuration requests and at least one configuration switching timer from a network node by the UE.

[0245] Example 3.2. The UE according to Example 3.1, wherein the at least two ER configuration requests include an indication of at least one fixed ER configuration in the fixed ER configurations.

[0246] Example 3.3. A UE based on Example 3.1 or Example 3.2, wherein the at least two ER configuration requests include a request to propose a complete ER configuration for the UE that is entirely configured by the UE.

[0247] Example 3.4. A UE according to any one of Examples 3.1 to 3.3, wherein at least one configuration switching timer corresponds to a minimum duration during which the UE cannot change the ER configuration or cannot change the ER configuration parameters.

[0248] Example 3.5. A UE according to any one of Examples 3.1 to 3.4, wherein the components for iterative communication further include: A component for configuring at least one ER configuration, which is entirely configured by the UE.

[0249] Example 3.6. A UE according to any one of Examples 3.1 to 3.5, wherein the components for iterative communication further include: A component for transmitting a first proposal using a first ER configuration from at least two ER configurations, wherein the first ER configuration is entirely configured by the UE; and A component for receiving instructions on the approval or rejection of a first proposal.

[0250] Example 3.7. The UE according to Example 3.6, wherein the UE receives an indication of approval of the first proposal, and wherein the UE further includes: A component used to select the first ER configuration for reporting ML-enabled features implemented at the UE.

[0251] Example 3.8. The UE according to Example 3.6, wherein the UE receives an indication of rejection of the first proposal, and wherein the UE further includes: A component for sending a second proposal using a second ER configuration from at least two ER configurations, the second ER configuration being entirely configured by the UE.

[0252] Example 3.9. Based on the UE of Example 3.8, it also includes: A component used to send at least two interpretability reports.

[0253] Example 3.10. According to the UE of Example 3.8, the components for iterative communication further include: This component is used to send the default ER configuration when the maximum number of iterations for iterative communication is reached.

[0254] Example 3.11. According to the UE of Example 3.9, the components for sending at least two interpretability reports include: A component for sending a first interpretability report based on a first ER configuration before one of the at least one configuration switching timers expires.

[0255] Example 3.12. According to the UE of Example 3.11, the component for sending at least two interpretability reports further includes: A component for sending a second interpretability report based on a second ER configuration after one of the at least one configuration switching timers expires.

[0256] Example 3.13. A UE according to any one of Examples 3.9 to 3.12, wherein the components for iterative communication further include: A component for receiving instructions on using only one of at least two ER configurations.

[0257] Example 3.14. The UE according to Example 3.13, wherein the indication to use only one of the at least two ER configurations is an indication to use only the second ER configuration.

[0258] Example 4.1. A network node comprising: A component for receiving instructions from a user equipment (UE) regarding the ability to iterate between the UE and network nodes to determine the interpretability report (ER) configuration; and Components for iteratively communicating with the UE to determine ER configuration for reporting machine learning (ML) enabled features implemented at the UE, including: A component used to send at least two ER configuration requests and at least one configuration switching timer.

[0259] Example 4.2. A network node according to Example 4.1, wherein the at least two ER configuration requests include an indication of at least one fixed ER configuration in the fixed ER configurations.

[0260] Example 4.3. Based on the network node of Example 4.1 or Example 4.2, at least two ER configuration requests include a request for the UE to propose a complete ER configuration that is entirely configured by the UE.

[0261] Example 4.4. A network node according to any of Examples 4.1 to 4.3, wherein at least one configuration switching timer corresponds to a minimum duration during which the UE cannot change the ER configuration or cannot change the ER configuration parameters.

[0262] Example 4.5. A network node according to any one of Examples 4.1 to 4.4, wherein the components for iterative communication further include: A component for receiving a first proposal using a first ER configuration from at least two ER configurations, wherein the first ER configuration is entirely configured by the UE; and A component used to indicate whether a component approves or rejects a first proposal.

[0263] Example 4.6. A network node according to Example 4.5, wherein the network node sends an indication of rejection of the first proposal, and wherein the network node further includes: A component for receiving a second proposal using a second ER configuration from at least two ER configurations, the second ER configuration being entirely configured by the UE.

[0264] Example 4.7. Based on the network nodes in Example 4.6, it also includes: A component for receiving at least two interpretability reports.

[0265] Example 4.8. Based on the network node of Example 4.6, the components for iterative communication further include: A component used to receive the default ER configuration when the maximum number of iterations for iterative communication is reached.

[0266] Example 4.9. A network node according to Example 4.7, wherein the components for receiving at least two interpretability reports include: A component for receiving a first interpretability report based on a first ER configuration before one of the at least one configuration switching timers expires.

[0267] Example 4.10. The network node according to Example 4.9, wherein the component for receiving at least two interpretability reports further includes: A component for receiving a second interpretability report based on a second ER configuration after one of the at least one configuration switching timers expires.

[0268] Example 4.11. A network node according to any one of Examples 4.7 to 4.10, wherein the components for iterative communication further include: Components used to evaluate at least two interpretable reports; and A component used to send an instruction that only one of at least two ER configurations is used.

[0269] Example 4.12. Based on the network node in Example 4.11, the indication that only one of the two ER configurations is used is the indication that only the second ER configuration is used.

[0270] The embodiments and aspects disclosed herein are examples of this disclosure and may be embodied in various forms. For example, although some embodiments herein are described as separate embodiments, each embodiment herein may be combined with one or more other embodiments herein. The specific structural and functional details disclosed herein should not be construed as limiting, but rather serve as the basis for the claims and as a representative basis for teaching those skilled in the art to employ this disclosure in various ways with virtually any suitable detailed structure. Throughout the description of the accompanying drawings, the same reference numerals may refer to similar or identical elements.

[0271] The phrases “in one respect,” “in all respects,” “in multiple respects,” “in some respects,” or “in other respects” may each refer to one or more of the same or different respects under this disclosure. The phrase “multiple respects” may refer to two or more.

[0272] In various embodiments, the terms "first message" and "second message," as well as any subsequent messages, may refer to any messages sent or received in sequence, and are not necessarily limited to any particular message.

[0273] The phrases “in embodiments,” “in various embodiments,” “in multiple embodiments,” “in some embodiments,” or “in other embodiments” can each refer to one or more embodiments according to the same or different embodiments of this disclosure. The phrase “A or B” means “(A), (B), or (A and B)”, and the phrase “at least one of A, B, or C” means “(A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C)”. Any method, program, algorithm, or code described herein can be translated into or expressed in a programming language or computer program. As used herein, the terms "programming language" and "computer program" each include any language used to specify instructions to a computer, and include (but are not limited to) the following languages ​​and their derivatives: assembly language, Basic, batch files, BCPL, C, C++, Delphi, Fortran, Java, JavaScript, machine code, operating system command languages, Pascal, Perl, PL1, Python, scripting languages, Visual Basic, meta-languages ​​that specify their own programs, and all first-, second-, third-, fourth-, fifth-, or higher-generation computer languages. Databases and other data schemas are also included, as well as any other meta-languages. There is no distinction between languages ​​that are interpreted, compiled, or use both compilation and interpretation methods simultaneously. There is no distinction between a compiled version and a source version of a program. Therefore, a reference to a program in which a programming language can exist in more than one state (such as source, compiled, object, or linked) is a reference to any and all such states. A reference to a program can encompass the actual instructions and / or the intent of those instructions.

[0274] While various aspects of this disclosure have been shown in the accompanying drawings, they are not intended to be limited thereto, as the scope of this disclosure is intended to be as broad as would be permitted in the art, and the specification is to be interpreted in the same manner. Therefore, the foregoing description should not be construed as restrictive, but merely as an example of particular aspects. Other modifications within the scope and spirit of the appended claims will be contemplated by those skilled in the art.

Claims

1. A method for communication, comprising: The user equipment (UE) sends an instruction to the network node indicating the ability of the UE and the network node to iterate and determine the interpretability report (ER) configuration; as well as Iterative communication with the network node to determine the ER configuration for reporting machine learning ML features implemented at the UE, the iterative communication including: The UE receives at least two ER configuration requests and at least one configuration switching timer from the network node.

2. The method of claim 1, wherein the at least two ER configuration requests include an indication of at least one fixed ER configuration in the fixed ER configurations.

3. The method according to claim 1 or 2, wherein the at least two ER configuration requests include a request for the UE to propose a complete ER configuration entirely configured by the UE.

4. The method according to claim 1 or 2, wherein the at least one configuration switching timer corresponds to a minimum duration during which the UE cannot change the ER configuration or cannot change the ER configuration parameters.

5. The method according to claim 1 or 2, wherein the iterative communication further comprises: The UE configures at least one ER configuration, and the at least one ER configuration is entirely configured by the UE.

6. The method of claim 1 or 2, wherein the iterative communication further comprises: The UE sends a first proposal to the network node to use a first ER configuration out of at least two ER configurations, wherein the first ER configuration is entirely configured by the UE. as well as The UE receives an indication of approval or rejection of the first proposal from the network node.

7. The method of claim 6, wherein the UE receives an indication of approval of the first proposal from the network node, and wherein the method further comprises: The UE selects the first ER configuration based on the first proposal to report the ML-enabled feature implemented at the UE.

8. The method of claim 6, wherein the UE receives an indication of rejection of the first proposal from the network node, and wherein the method further comprises: The UE sends a second proposal to the network node using the second ER configuration of the at least two ER configurations, the second ER configuration being entirely configured by the UE.

9. The method according to claim 8, further comprising: The UE sends at least two interpretability reports to the network node.

10. The method of claim 8, wherein the iterative communication further comprises: When the maximum number of iterations for the iterative communication is reached, the UE sends a default ER configuration to the network node.

Images