Data collection configuration

Abstract

In some examples, an apparatus for a user equipment includes at least one processor; and at least one memory including instructions configured to affect data collection configuration in a wireless communication network, the instructions, when executed by the at least one processor, cause the apparatus at least to establish a connection toward a network node of a radio access network; receive, from the network node, information related to data collection configuration parameters supported by the network node; and send, to a server for collecting training data, at least a portion of the received information to enable the server to request at least one data collection configuration that is for the UE and is adapted to network node configuration capabilities.

Description

Technical Field

[0001] This disclosure generally relates to scalable and efficient data collection configurations in wireless communication networks. Background Technology

[0002] In current wireless communication systems, user equipment (UE) receives configurations for data collection from networks such as gNBs (base stations) without any ability to influence or customize these configurations. This lack of control leads to inefficiencies, including biased datasets or redundant data collection, which can negatively impact the training and inference processes of AI / ML models on the UE side.

[0003] Furthermore, the network lacks full knowledge of the data already collected by the UE or its corresponding over-the-top (OTT) server. This limitation makes evaluating dataset quality and optimizing configuration computationally complex or infeasible for the network. For example, while the network can configure reference signals across multiple frequency bands, an OTT server may require more measurements from a specific frequency band to balance the dataset used for model training. Existing solutions lack a mechanism for efficiently transmitting this preference to the UE or OTT server.

[0004] Furthermore, scalability is a significant challenge. Allowing multiple UEs to send configuration requests simultaneously increases uplink traffic and processing complexity at the gNB. Consequently, due to real-time constraints, the network often ignores such requests, leaving no viable solution for the impact of scalable UEs on configuration settings. Summary of the Invention

[0005] The purpose of this disclosure is to provide a scalable solution that enables UEs or their respective OTT servers to adopt preferred data collection configurations to influence network configurations used for training, inference, and performance monitoring.

[0006] The foregoing and other objectives are achieved through the features of the independent claims.

[0007] Further implementations are apparent from the dependent claims, the specification, and the drawings.

[0008] A first aspect of this disclosure provides an apparatus for a user equipment (UE), the apparatus including at least one processor; and at least one memory including instructions configured to influence a data collection configuration in a wireless communication network, the instructions, when executed by the at least one processor, causing the apparatus to at least: establish a connection to a network node of a wireless access network; receive information from the network node relating to data collection configuration parameters supported by the network node; and, at least in part based on the received information, send information to a server for collecting training data to enable the server to request at least one data collection configuration for the UE and adapted to the network node's configuration capabilities.

[0009] In an implementation of the first aspect, the device may send a request to the network for information indicating a supported data collection configuration. The device may include, along with the request, at least one associated ID, wherein the at least one associated ID includes a mapping between training hypotheses and inference hypotheses based on selected physical or logical network conditions. The device may receive a configuration identifier ID from a server and include the configuration ID in the request. The device may receive an indication from the server requesting information indicating a supported data collection configuration. The device may send location-related information to the server along with the information indicating a supported data collection configuration. The device may send collected measurement data directly to the server via user plane communication or via a network node. The device may receive an indication from the server for a single request regarding information indicating a supported data collection configuration, wherein the single request indication includes an aggregation of multiple requests originating from user equipment serving the same network node as the device. The device can receive information from a network node related to data collection configuration parameters supported by the network node, wherein the parameters include at least one of logical parameters and physical parameters, and wherein the information includes at least one of the following: at least one feasible configuration, a predefined set of parameters defining values ​​or ranges of values ​​for one or more parameters to be configured by the network node, an indication to perform CSI Reference Signal (CSI-RS) measurements for a selected frequency range, multiple CSI-RS and their associated beamwidths, an upper limit on the number of configurations or parameters that can be requested at one time, and the applicable time period. The device can send location-related information to a server. The device can send a data collection configuration request to the network node, wherein the data collection configuration request includes parameter configurations adapted to the network node's configuration capabilities. In addition to the data collection configuration request, the device can also send a configuration ID received from the server. In addition to the data collection configuration request, the device can also send information received from the server and related to the type and / or number of user equipment and / or the required measurements. The device can receive and forward specific data collection configuration requests from the server to the network node, wherein the requests include parameter configurations adapted to the network node's configuration capabilities. The device can receive a data collection configuration in response to a data collection configuration request, perform data collection according to the received data collection configuration, and send a report related to the collected data to the server.

[0010] A second aspect of this disclosure provides a method comprising: establishing a connection at a device for a user equipment (UE) toward a network node of a radio access network; receiving at the device information related to data collection configuration parameters supported by the network node from the network node; and, based at least in part on the received information, sending information from the device to a server for collecting training data to enable the server to request at least one data collection configuration for the UE and adapted to the network node configuration capabilities.

[0011] A third aspect of this disclosure provides a non-transient computer-readable medium that stores instructions that, when executed by a processor, perform the method of the second aspect.

[0012] These and other aspects of the invention will become apparent from the embodiments described below. Attached Figure Description

[0013] To facilitate a clearer understanding of this disclosure, embodiments will now be described by way of example with reference to the accompanying drawings, in which:

[0014] Figure 1 It is a signaling diagram based on the example regarding the sharing of applicable (or supported or feasible) configuration information between the NW and the UE / its corresponding OTT server via the UE;

[0015] Figure 2 This is a signaling diagram based on the example regarding (NW-permitted) historical configuration information collected by the UE;

[0016] Figure 3 This is a signaling diagram based on an example regarding the process by which the OTT is responsible for extending UE configuration requests and simultaneously instructing the NW to the UE configuration request via (multiple) UEs;

[0017] Figure 4 This is a signaling diagram based on an example of the process by which a UE / OTT requests parameter configuration from a gNB via a CN;

[0018] Figure 5 This is a signaling diagram based on an example of the process by which a UE / OTT requests parameter configuration from a gNB via the OAM function;

[0019] Figure 6 This is a schematic representation based on the example machine; and

[0020] Figure 7 This is a flowchart based on the example method. Detailed Implementation

[0021] Example embodiments are described below in great detail to enable those skilled in the art to embody and implement the systems and processes described herein. It is important to understand that embodiments may be provided in many alternative forms and should not be construed as limited to the examples set forth herein.

[0022] Therefore, although embodiments may be modified in various ways and various alternative forms may be taken, specific embodiments thereof are shown in the accompanying drawings and described in detail below as examples. This is not intended to limit the specific forms disclosed. Rather, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Throughout all the drawings and detailed descriptions, elements of the exemplary embodiments are consistently denoted by the same reference numerals (where applicable).

[0023] The terminology used to describe embodiments herein is not intended to limit the scope. The articles “a,” “an,” and “the” are singular because they have a single reference; however, their use in the singular form in this document should not preclude the existence of more than one reference. In other words, elements mentioned in the singular form may be numbered one or more unless the context explicitly indicates otherwise. It will also be understood that the terms “comprising,” “including,” “containing,” and / or “comprising” as used herein specify the presence of the stated features, items, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and / or combinations thereof. The term “and / or” is used only to describe the relationship between related objects and indicates that three relationships can exist such that A and / or B can indicate that A exists alone, A and B exist simultaneously, or B exists alone. The character “ / ” generally indicates that related objects are in an “or” relationship.

[0024] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall be interpreted in accordance with the conventions of the art. It should also be understood that, unless explicitly defined herein, commonly used terms should be interpreted as those in the relevant field, rather than as idealized or overly formal meanings.

[0025] The following contains specific information relating to implementations of this disclosure. The accompanying drawings and detailed disclosure are only illustrative of implementations. However, this disclosure is not limited to these implementations. Other variations and implementations of this disclosure will be apparent to those skilled in the art.

[0026] The phrases “in one implementation” or “in some implementations” can each refer to one or more of the same or different implementations. The term “coupling” is defined as a connection, either directly or indirectly through intermediate components, and is not necessarily limited to a physical connection. The expressions “at least one of A, B, and C” or “at least one of the following: A, B, and C” mean “only A, or only B, or only C, or any combination of A, B, and C.”

[0027] The terms "system" and "network" are used interchangeably.

[0028] For purposes of explanation and non-limitation, specific details such as functional entities, technologies, protocols, and standards are set forth to provide an understanding of this disclosure. In other examples, detailed disclosures of well-known methods, technologies, systems, and architectures have been omitted so as not to obscure this disclosure with unnecessary detail.

[0029] Those skilled in the art will readily recognize that any of the disclosed network functions or algorithms can be implemented by hardware, software, or a combination of both. The disclosed functions may correspond to modules that can be software, hardware, firmware, or any combination thereof.

[0030] Software implementation may include machine-readable and / or computer-readable and / or executable instructions stored on machine-readable and / or computer-readable and / or executable media such as memory or other types of storage devices. One or more microprocessors or general-purpose computers with communication processing capabilities may be programmed with corresponding executable instructions and perform the disclosed network functions(s) or algorithms(s).

[0031] Microprocessors or general-purpose computers may include application-specific integrated circuits (ASICs), programmable logic arrays, and / or utilize one or more digital signal processors (DSPs). Although some of the disclosed implementations are directed to software installed and executed on computer hardware, alternative implementations as firmware or hardware or a combination of hardware and software are also within the scope of this disclosure. Computer-readable media include, but are not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, optical disc read-only memory (CD-ROM), magnetic tape cassettes, magnetic tape, disk storage, or any other equivalent medium capable of storing computer-readable instructions.

[0032] The described examples can be implemented in communication networks such as any of the following radio access technologies (RATs): Universal Mobile Telecommunications System (UMTS, 3G) based on Basic Wideband Code Division Multiple Access (W-CDMA), High-Speed ​​Packet Access (HSPA), Long Term Evolution (LTE), Advanced LTE and Enhanced LTE (eLTE), 5G (also known as NR), or any future RAT (such as 6G).

[0033] As used herein, the term "network device" or "network node" refers to a node in a communication network through which user equipment can access the network and / or through which the node can control wireless communication and manage wireless resources within the cell. A network node or network device may be referred to as a base station (BS), access point (AP), or access node. Depending on the technology applied, a network device may be, for example, a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), an NR NB (also known as a gNB), a Remote Radio Unit (RRU), a Radio Headend (RH), a Remote Radio Headend (RRH), a relay, an Integrated Access and Backhaul (IAB) node, a low-power node, a non-terrestrial network (NTN), or non-terrestrial network equipment such as satellite network equipment, low Earth orbit (LEO) satellites and geostationary Earth orbit (GEO) satellites, or spacecraft network equipment.

[0034] Furthermore, in a split Radio Access Network (RAN) connection, network devices can refer to a Central Unit (CU) and / or a Distributed Unit (DU) of a base station. The interface between the CU and DU may be referred to as the F1 interface in NR. In a split RAN architecture, node operations can be performed at least partially in a central / centralized unit (CU, such as a server, host, or node) that is operationally coupled to a DU (e.g., a radio headend / node). A CU can control one or more DUs that at least act as transmit / receive (Tx / Rx) nodes. In some embodiments, a DU may include, for example, a Radio Link Control (RLC), Media Access Control (MAC) layer, and a Physical (PHY) layer, while a CU may include layers above the RLC layer, such as the Packet Data Convergence Protocol (PDCP) layer, Radio Resource Control (RRC), and Internet Protocol (IP) layer. Other functional splits are also possible. In fact, any processing task can be performed in a CU or DU, and the boundary of responsibility transfer between the CU and DU may depend on the applied implementation.

[0035] The term "terminal device" refers to any terminal device capable of wireless communication. As examples, a terminal device may be referred to as a communication device, user equipment (UE), subscriber station (SS), or mobile station (MS). Terminal devices can include mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, USB dongles, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and so on.

[0036] As used herein, the term "resource" can refer to radio resources in the time domain, frequency domain, spatial domain, and / or code domain. Some examples of resources include, for example, physical resource blocks (PRBs), radio frames, subframes, time slots, subbands, frequency regions, subcarriers, beams, etc. The terms "transmit" and / or "receive" can refer to wirelessly transmitting and / or receiving on radio resources via a radio propagation channel.

[0037] 3GPP RAN2 is one of the working groups under the Technical Specification Group for Radio Access Networks (TSGRAN) of the 3rd Generation Partnership Project (3GPP). It is responsible for defining and developing specifications related to Radio Layer 2 and Radio Layer 3 protocols, which are critical for the operation of cellular networks, including LTE, 5G NR (New Radio), etc.

[0038] To enable offline training data collection, RAN2 discusses the various aspects and features that any chosen option should support. One aspect concerns the UE's request to start and stop data collection. Extending this start / stop effect is the impact on allowing / enabling the UE's configuration received from the gNB. This impact will enable the collection of high-quality data for training the UE-side model. In this context, high-quality can refer to different aspects, such as having an unbiased dataset. Since only the UE and / or its corresponding OTT server possess complete knowledge of the UE's hardware characteristics and the data collected from different cells in the mobile network, the OTT server and / or the UE can detect any remaining measurements to be collected (and what characteristics they possess) to achieve a sufficiently unbiased dataset.

[0039] In another example, during training, it can be concluded that more measurements or samples with specific characteristics, such as belonging to a particular cell and / or frequency range, are useful for training. In this case, the UE / corresponding OTT server may also need to transmit this specific expectation to the NW.

[0040] In the example of data collection configuration for UE-side model training, the options discussed in RAN2 are used for the UE to send data collection requests (e.g., start / stop). An aspect under investigation is whether a suggested data collection configuration / associated ID (if specific) / parameters can be provided to the network, but this aspect has not yet been finalized or agreed upon.

[0041] The precise definition and attributes of the associated ID have not yet been agreed upon in RAN1. However, typically, the associated ID may include at least one example of auxiliary information that can be transmitted from the NW to the UE to enable consistency between training and inference.

[0042] For example, during data collection, the NW can configure the UE with configurations X and Y corresponding to associated IDs #1 and ID #2. These IDs and configurations can refer to specific physical or logical conditions in the NW. Therefore, the UE can train a model for this physical condition / associated ID. Subsequently, during inference, if the NW indicates the applicability of associated ID #1, the UE can interpret which model should be used on its side. However, if the NW indicates the applicability of associated ID #3, the UE can conclude that none of its available models work well for this environment and therefore decide to use the conventional approach; alternatively, it can even request data collection to be initiated for a given associated ID (#3).

[0043] Based on the current process between the UE and gNB, the UE receives a configuration for data collection from the gNB without any influence or control over the details of that configuration. However, since the NW (e.g., the gNB) does not have full knowledge of the data already collected / being collected at, for example, the OTT server of the chip or UE vendor, it is infeasible or computationally complex for the NW to evaluate the quality of the collected dataset. For example, in ongoing data collection, the NW might attempt to configure the UE to transmit reference signals on various resource elements, including those with frequency bands from FR1 and FR2. However, it is possible that the OTT server already has multiple measurements related to FR1 and requires more measurements related to FR2 to obtain a balanced dataset for model training. According to the example, the UE and / or the OTT server should be allowed to indicate their preferences for data collection configuration to the NW. However, multiple UEs sending their different suggested configurations to the NW is not scalable, as this would not only increase uplink UL traffic but also increase gNB complexity, as the NW would have to process all these requests in a near-real-time manner (since the UE might only be in a given cell for a few seconds). Therefore, NW may have to ignore any received suggested configurations.

[0044] According to the example, the NW (e.g., gNB / core network (CN)) can provide some information about parameters that the NW (typically or during specific periods) may support for data collection purposes. In the example, some analysis may be performed by the network in advance to determine the parameters. For example, to extract parameters provided for data collection purposes, the NW may use historical information from UEs, such as indications of their applicability based on their previous requests or certain associated IDs. This information may be provided by the CN or the network's Operations Management and Maintenance (OAM) functions. This information may also be sent to the UE upon request or may be broadcast. In another example, the UE / CN / OAM may request this information from the gNB, or the CN / OAM may subscribe to receive updates related to the parameters.

[0045] In the example, in addition to sharing this information, the NW can allow the UE to collect historical configuration and area-related information, which can be used to determine which configuration requests have a high chance of being accepted by the NW. The gNB can indicate that this data is permitted for collection. Area-related information can relate to the area where the UE is being served and can include different levels of precision (e.g., within 10m, 1km, etc.). Other examples of area-related information can include identifiers for the serving cell, gNB, tracking area, etc.

[0046] Similar to the configuration parameters supported by the NW, the following provides an example set of content for UE requests based on examples (implying UE preferences regarding configurations received from the NW). The predefined set of parameters can be directly in the form of feasible configurations, such as CSI measurement configuration and RRC reconfiguration. In another example, the predefined set of parameters can define precise values ​​or ranges for one or more parameters that can be configured by the gNB. For example, a configuration request could indicate a request to perform CSI Reference Signal (CSI-RS) measurements for frequency ranges X and Y. In another example, the request could indicate a specific time period for RS transmission, such as per T ms. Another example could involve multiple CSI-RS and their beamwidths (e.g., a UE could request to receive CSI-RS when the beamwidth used by the gNB is narrower than a given predetermined threshold). In this context, parameters can refer to both logical and physical parameters. In other examples, some IDs with specific mappings to specific characteristics can be transmitted to the UE. As mentioned above, an example of such IDs is an associated ID.

[0047] According to the example, instead of multiple instructions from individual UEs, an indication of one (or a limited) set of parameters / configurations can be provided. In the example, the OTT server, CN, or OAM can be responsible for this scalability aspect. That is, one or more (e.g., a limited number) parameters / configurations can be selected for configuration by the gNB, rather than multiple UEs providing a set of parameters to the gNB. Depending on the location where scalable measurements are enforced, the path from the UE request to the gNB varies. For example, the OTT server can collect location-related information from the UEs, including information about the gNB they currently serve. This allows the OTT server to transmit requests for configurations for data collection to the appropriate UEs(s). In the example, the OTT server can instruct multiple UEs served by the same gNB to request only one configuration at a time, such as a set of configuration parameters. Where OTT ensures scalability, a UE configuration ID is introduced to further simplify the gNB's processing of received UE requests. In another embodiment, for example, if the associated ID has a fixed mapping to some underlying physical or logical conditions, the associated ID can be used.

[0048] In the example, OTT can enable scalability by ensuring that only one parameter / configuration set is requested from a gNB at a time. This cap can be changed if the gNB allows a higher number of requests. However, if the entity responsible for processing configuration requests and scalability is a CN or OAM, the cap can be larger because 1) these entities handle requests from more than one OTT server, and 2) they can directly request the gNB to identify the cap it can handle based on its available computing resources. In another example, the gNB can determine the cap and indicate it to the CN / OAM without an explicit request from the CN / OAM, or the gNB can indicate to the UE / CN / OAM that it is ready to receive new configuration / parameter sets. The gNB can indicate to (multiple) CN / OAM / UE its acceptance / rejection related to received UE requests, and indication of the reason for rejection, such as a scalability issue or inapplicability at the time. This helps the OTT server, for example, to provide improved requests in subsequent iterations / trials.

[0049] Note that this disclosure refers to the configuration used for data collection. However, the proposed enhancements also apply to configurations requested by the UE during inference, monitoring, and retraining. For example, the UE may request (multiple) specific configurations during inference to employ one of its already trained models while ensuring consistency between inference and training (including training data collection).

[0050] Figure 1 It is a signaling diagram based on the example regarding the sharing of applicable (or supported or feasible) configuration information between the NW and the UE / its corresponding OTT server.

[0051] exist Figure 1 In the example, the NW, such as gNB 107, considers the UE (103, 105)'s request for (multiple) specific configurations (or (multiple) parameters). Figure 1 In the example, this is facilitated by NW 107, which indicates the configuration parameters it can support.

[0052] At point 1, (multiple) UEs 103, 105 may have indicated to NW 107 that they do not have parameters corresponding to, for example, an associated ID or a specific range (e.g., from...). CSI_measConfigSufficient measurement is crucial. This helps the NW provide the UE / OTT server with more relevant and less redundant information about feasible configurations. As the UE discovers it lacks sufficient measurements, the NW can potentially identify (through analysis) which configurations can be supported. For example, the NW can analyze certain sets(s) of measurements the UE may never have been able to collect for or that indicate problems associated with those configurations, such as low power states or insufficient resources. Through this indication, the NW can identify which configurations are good or bad, and can declare what relevant configurations can be supported.

[0053] At point 2, OTT server 101 can request information from NW (gNB) 107 via UE 103 or UE 105. This information pertains to the configuration or set of configuration parameters that gNB 107 can use to configure the UE for data collection and / or inference. At point 3, the request for information can be based on a request from OTT server 101 or initiated by UE 103 or 105 itself.

[0054] According to the example, at point 4, NW 107 provides a predefined set of parameters to UE 103 based on this request. In the example, NW 107 can provide this information to a specific UE(s) based on the received request. In another example, NW can broadcast this information to all UEs it serves. In yet another example, NW can ignore / reject the request.

[0055] The predefined set of parameters can be in the form of a directly configurable configuration, or it can define precise values ​​or ranges for one or more parameters that can be configured by gNB 107. For example, gNB 107 can inform UE 103 that it can receive a configuration to perform CSI Reference Signal (CSI-RS) measurements for frequency ranges X and Y. Another example could involve multiple CSI-RS and their associated beamwidths. In this context, parameters can refer to both logical and physical parameters. In other examples, some IDs with specific mappings to specific characteristics can be transmitted to UE 103. An example of such IDs could be the associated IDs described above. These different forms also apply to OTT 101 and UEs 103 and 105 requesting specific configurations.

[0056] In the example, the applicable time frame for configuration and predefined parameters can be included in messages from NW 107 to UE 103. This applicable time frame determines the time window in which the indicated configuration and parameters are applicable, for example, in the case of a request from a UE / OTT server, which is most likely supported by NW 107. An upper limit on the number of configurations or parameters that can be requested at one time can also be declared from NW in the message. When no upper limit is provided, it can be considered a default value.

[0057] At point 6, the received information can be processed by UE 103. Alternatively, the information can be forwarded to OTT server 101 for interpretation and processing. In the event that NW 107 rejects / ignores a request from the UE, the UE can notify OTT server 101. It should be noted that regarding... Figure 1 A network entity (e.g., gNB) is logically provided between UEs 103 and 105 and OTT server 101 to relay messages / data between UEs 103 and 105 and OTT server 101; however, this entity is omitted for clarity.

[0058] Figure 2 This is a signaling diagram based on the example regarding (NW-permitted) historical configuration information collected by the UE. Figure 2 In the example, at points 1 and 2, UEs 103 and 105 can collect configuration from NW 107. Therefore, UEs 103 and 105 can estimate which parameters are feasible to configure for which areas, during which time windows, or for what type of channel conditions. For example, the configuration for RRC reconfiguration can be enhanced to include an indication of whether the UE is allowed to collect configuration. In this example, this indication could be a one-bit flag indicating allow / disallow. In another example, the indication could include information about whether collection is allowed only at UEs 103 and 105, only at OTT server 101, or both. This collected configuration can be processed by the UE or the corresponding OTT server to allow them to use it for the extraction of configuration and / or configuration parameters supported by the NW for their data collection requests.

[0059] Therefore, gNB 107 provides a configuration dedicated to UEs 103 and 105, and UEs 103 and 105 provide this configuration to OTT server 101 (at position 3 / 4). Note that in Figure 1 In the example, NW 107 provides configuration to UE 103 and 105.

[0060] Figure 3 This is a signaling diagram based on an example of the process by which the OTT is responsible for extending UE configuration requests while simultaneously instructing the NW to the UE configuration request via (multiple) UEs.

[0061] Regardless of whether the UE / OTT server has information about the previous NW configuration (e.g., based on the reference above). Figure 2 The described signaling) or has information about feasible / supported NW configurations at a given time period (e.g., based on the reference above). Figure 1 The UE (103; 105) / OTT server 101 can request specific configurations or configuration parameters from the NW 107, based on some information from the signaling described.

[0062] Figure 3 The process of a UE being served by the same gNB (1) is described. The same signaling and procedures are applied to other UE groups served by other gNBs. Reference Figure 3 At point 2, assume that OTT server 101 is the endpoint for data collected for training the UE-side model (this data may also be stored on the UE side depending on the data size). At point 3, OTT 101 can determine that new data / measurements should be collected from UEs 103 and 105, which require gNB configuration. Some examples of implementation-specific decisions include: - When a UE is served in a specific cell or geographic area, OTT 101 can identify that it does not have a sufficient number of samples collected; - OTT 101 can identify the lack of CSI measurements for interference measurement, also known as IM (compared to channel measurements), and therefore this information is needed to account for the effects of interference in training AI / ML models; Depending on hardware performance (RF module performance), OTT 101 can identify the need for collecting data with specific characteristics, such as measurements performed considering a specific frequency range; - OTT 101 can identify one or more UEs that have an unsuitable model or whose model performance is below the threshold that triggers model retraining. In this case, the collection of new data with specific characteristics is required.

[0063] At four locations, UEs 103 and 105 can share information about their locations with OTT server 101 in different forms. For example, location information may include information about the location of the UE with specific precision, or it may be an ID that identifies the UE's approximate location in the NW, such as within 500m, or it may be an ID that uniquely identifies the gNB serving the UE, or the UE may indicate to the OTT server the model(s) IDs it has available or is using, where the model ID may represent or include metadata information of the model.

[0064] Based on the information shared at the other four locations, OTT server 101 can determine which UEs 103 and 105 are served by the same gNB 107 at five locations. Therefore, OTT server 101 will generate only one configuration or only one set of configuration parameters for UEs 103 and 105 served by the same gNB 107 at a given time. Different configurations / parameters can be provided to the UEs and then to the gNB. This allows for a scalable solution and does not overload the gNB with too many different configurations.

[0065] At 6 to 9, the configuration / parameters from 5 may be transmitted to the UEs 103, 105. In an example, the OTT server 101 may transmit the configuration / parameters to only one UE. Then this one UE may forward the request containing them to the serving gNB 107. Although receiving only one such request is scalable from the NW's perspective, since the gNB may not have information that the UE belongs to the owner of the OTT server, the NW may then apply the configuration to only that UE. Therefore, in this example, the request may further include some information about which UEs shall receive the requested configuration. One example is to state that X UEs from, for example, vendor Z shall be configured with the requested parameters. In this case, to identify the target UEs (UEs from vendor Z), the gNB may request some relevant information from the CN.

[0066] According to an example, the UE configuration ID is assigned, for example, by the OTT server 101, and refers to a configuration request from the OTT server 101 that shall be applied to a specific group of UEs (in an example, the group of UEs may comprise at least two UEs connected to the same gNB). Then, for example:

[0067] UE1 receives a data collection configuration and the correspondingly assigned UE configuration ID from the OTT server 101. UE2 receives the same correspondingly assigned configuration ID from the OTT server 101. UE1 forwards the received information to the gNB. UE2 forwards the received information to the gNB. In another example, UE2 may send only the ID (without the configuration). Due to the same configuration ID, the gNB recognizes that both requests from UE1 and UE2 are related to the same configuration request. Thus, the gNB may then decide to allow one request and reject the other based on some criteria (e.g. current load, etc.). The gNB may alternatively decide to allow both requests to enable the OTT server to collect more relevant data. The gNB may alternatively reject both requests based on other criteria, such as due to scalability issues, i.e. receiving many different configurations at the same time.

[0068] According to an example, the NW may provide information that it supports requests for RS transmission on a certain time period on, for example, a frequency range x1 to x2. However, the UE may still request an RS configuration with a frequency band allocation between x3 and x4, for example, where x1<x3<x2 and x4>x2 or x2<x3<x4.

[0069] In another example, the NW can provide information about its support for RS transmission requests within a certain time period, for example, frequency range x1 to x2. The NW may not provide any information about the available beamwidth. The UE can still request RS transmissions using a narrow beam. In another example, OTT server 101 can send the same desired configuration parameters to different UEs, and the UE forwards the request to NW 107. This is still scalable because at point 5, OTT 101 ensures that only one set of parameters is active / present at a time in the UE configuration request. In other words, the gNB receives multiple copies of the same configuration request. Even if other OTT servers perform similar actions, the gNB only needs to process a limited number of different parameters at a time.

[0070] To further reduce the computational complexity of the gNB and the latency caused by determining which UEs have the same configuration, UEs requesting the same configuration can indicate a so-called UE configuration ID to the gNB. This UE configuration ID can be part of a request from all UEs. In another example, one UE can send its UE configuration ID and the requested parameters, while other UEs only send requests with their UE configuration IDs. This configuration ID can be assigned by the OTT server 101 and should be distinguishable from UE configuration IDs used by other OTT servers. In another example, the configuration can include only the associated ID to enable scalability and fast processing of requests by the gNB. Furthermore, it can be sent via UE Assistance Information (UAI). Figure 3 Requests at positions 8 and 9.

[0071] At locations 10 to 12, if multiple configuration requests are valid, NW 107 responds by configuring UEs 103 and 105 accordingly. Conversely, if NW 107 determines that a UE should not receive a requested configuration, it can explicitly reject the request. In the example, the rejection could indicate that it is due to a scalability issue, i.e., receiving many different configurations simultaneously. This indication is particularly useful if the location information exchanged at location 4 does not uniquely clarify which UEs are served by which gNB. In another example, the UE does not receive any requested configurations from the NW that might imply rejection.

[0072] At position 13, UEs 103 and 105 can notify OTT server 101 of the acceptance / rejection of the configuration request. OTT server 101 can use this information in the design of other requests. Measurements and data collected at the UE side can be sent to the OTT server in different ways. For example, in a gNB-centric example, UEs 103 and 105 can send the collected data to gNB 107. In this case, the messages at positions 6 to 9 can include the address of OTT server 101, allowing gNB 107 to forward this information to OTT server 101. In CN-based or OAM-based examples, UEs 103 and 105 requests can include information mapping which CN-based or OAM-based data collection jobs correspond to the configuration requested by the UE. Therefore, gNB 107 can understand where to send the data after receiving it from UEs 103 and 105. In another example, UEs 103 and 105 can send data to OTT server 101 in a way that is transparent to the gNB, for example, through the user plane.

[0073] Figure 4 This is a signaling diagram based on an example of the process by which a UE / OTT requests parameter configuration from a gNB via a CN. Figure 4 In the example, the OTT server 101 does not need to know the location of the UE (e.g., it does not need to know the location of the UE). Figure 3 (Message transmission 4), because the UE's selection can be assisted by CN 401.

[0074] At point 1, gNB 107 may share some information about the configuration parameters it typically and / or supports within a specific time window. Here, gNB 107 may indicate the number of configurations and / or an upper limit on the number of parameters requested with specific values ​​or ranges. This upper limit can be indicated from gNB 107 to CN 401. The procedures at points 2 and 3 are as described above. Figures 1 to 3 As stated above.

[0075] At point 4, OTT server 101 transmits its preferred configuration parameters to CN 401. Figure 4 In the example, due to the scalability of CN401 supervision, the OTT 101 request can include various parameters and different ranges. The request can also include information about geographic regions. For example, configuring UE IDs X1 and X2 to collect data based on configuration Y in geographic region Z. In other examples, a UE belonging to a specific vendor might be the target. In yet another example, a specific gNB might be the target. (Reference above) Figure 3 This describes some examples of what request configurations can include.

[0076] exist Figure 4In the example, an OTT request can be sent to, for example, a single UE to avoid overcrowding from different requests from different UEs (CN 401). The OTT request in this scenario can implicitly and explicitly include multiple configuration requests. It can also include OTT address information.

[0077] At point 5, the selected UEs 103 and 105 forward the requested configuration to CN 401. This communication can be accomplished, for example, via NAS message forwarding. The advantage of doing so is that, unlike UAI, NAS requests are not ignored by CN 401. In another example, instead of points 4 and 5, OTT server 101 can communicate directly with CN 401, for example, via NEF, and indicate the OTT request regarding the configuration.

[0078] At points 6 and 7, CN 401 is responsible for scalability. For example, CN 401 can receive requests from UEs 103 and 105 to configure some UEs using configuration X and some UEs using configuration Y. In this case, CN 401 can transmit configuration X to gNB 107, wait for the data collection to end, and then request gNB 107 to configure some UEs using configuration Y at different time intervals. It is possible to provide more than one configuration to the gNB at a time. However, an upper limit can be selected for this number. When the request includes ranges / values ​​for some parameters, such as ranges X1 and X2 for the frequency ranges of the allocated RS, the same process applies, that is, CN decides whether to request configurations for both requested ranges from the gNB simultaneously or subsequently.

[0079] At point 8, gNB 107 can assess (via CN 401) the feasibility of applying configurations for a given UE. In addition to assessing the feasibility of applying configurations requested by the UE, gNB can also verify the UE before applying configurations, considering factors such as current RRM requirements. This verification can be initiated by gNB. In one example, gNB 107 can transmit the verification to OTT 101 via CN401 before configuring the UE.

[0080] At points 9 to 11, if gNB 107 rejects the configuration indicated by CN 401 based on, for example, gNB 107's internal logic and RRM requirements, gNB 107 can notify CN 401. CN 401 can request the same configuration again at a different time. Furthermore, CN 401 can notify UEs 103 and 105 about the received rejection. Information regarding the set of given configuration parameters can be exchanged with the UE after receiving the first rejection or after receiving multiple rejections from the gNB (via NAS). UEs 103 and 105 then notify OTT 101 accordingly. If gNB 107 accepts the configuration indicated by CN 401, the procedures at points 10 and 12 are followed. At point 12, the signaling procedure based on the CN solution can be applied.

[0081] Figure 5 This is a signaling diagram based on an example of the process by which a UE / OTT requests parameter configuration from a gNB via the OAM function. Figure 5 The example is similar to the reference above. Figure 4 The example described. However, in Figure 5 In the example, OAM function 501 is responsible for the scalability of the requested configuration. Furthermore, to select a specific set of UEs, Minimum Drive Test (MDT) based on enhanced signaling can be used, while to target a specific area, an enhanced management-based MDT approach can be employed. MDT is a standardized mechanism introduced by 3GPP to optimize the collection of network performance data by leveraging UEs rather than relying solely on traditional drive tests. MDT enables network operators to collect real-world data from UEs in the domain, thereby reducing the need for expensive and labor-intensive drive tests while providing a more comprehensive view of network performance.

[0082] At positions 1 through 4, correspond to OAM 501 (instead of the reference above). Figure 4 The CN 401 exchange information about some configuration parameters supported by the gNB.

[0083] At points 5 and 6, for the configurations of OTT requests arriving at OAM 501, UEs 103 and 105 transmit them to gNB 107, and gNB 107 forwards them to OAM 501 for further processing.

[0084] At points 7 and 8, OAM 501 is responsible for scalability. Therefore, considering the requested configurations from different OTT servers and the ongoing MDT initiation work at OAM, OAM 501 can provide gNB 107 with enhanced MDT configuration for data collection. In managed MDT, the gNB in ​​the determined area of ​​the OTT request is the target for receiving MDT configuration / activation. In the signaling-based case, a specific UE can be tracked and gNB(s) selected accordingly. The process at point 9 is similar to, for example, the above reference. Figures 1 to 4 The process described.

[0085] At point 10, since there is currently no direct interface between OAM 501 and UEs 103 and 105, gNB 107 can notify OAM 501 of a rejection. The reason for the rejection could be, for example, insufficient scalability. In one example, a traditional activation mechanism could be used solely for the purpose of rejection. Therefore, in this case, OAM 501 can provide gNB 107 with fewer configuration / configuration parameters compared to a failure scenario. At point 8, if OAM 501 instructs gNB 107 that MDT activation involves the configuration of the specific OTT server 101 requested, gNB 107 can also forward rejection-related information to OTT server 101 via one or more UEs.

[0086] At positions 11 to 12, if accepted, UEs 103 and 105 are configured according to the requested parameters received from OAM 501.

[0087] At point 13, the data collected at UEs 103 and 105 is then sent to gNB 107, and from gNB 107 is sent to OTT server 101 (note that MDT activation should already include the address information of OTT server 101).

[0088] Examples of this disclosure may be provided as methods, systems, or machine-readable instructions, such as any combination of software, hardware, firmware, etc. Such machine-readable instructions may be included on or on a computer-readable storage medium (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-readable program code thereon.

[0089] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, and systems according to examples of this disclosure. Although the flowcharts described above show a particular order of execution, the order of execution may differ from that depicted. A block described in one flowchart may be combined with a block from another flowchart. In some examples, some blocks in the flowchart may not be necessary and / or additional blocks may be added. It should be understood that each flowchart and / or block in the flowchart and / or block diagram, as well as combinations of flowchart illustrations and / or block diagrams, can be implemented using machine-readable instructions.

[0090] Machine-readable instructions can be executed by, for example, a machine, such as a general-purpose computer, a platform including user equipment such as a smart device (e.g., a smartphone), a special-purpose computer, an embedded processor, or other programmable data processing device, to implement the functions described in the specification and figures. In particular, a processor or processing device can execute machine-readable instructions. Therefore, modules of the device can be implemented by a processor that executes machine-readable instructions stored in memory or a processor that operates according to instructions embedded in a logic circuit system. The term "processor" will be interpreted broadly to include CPUs, processing units, ASICs, logic units, or programmable gate groups, etc. Methods and modules can be executed entirely by a single processor or divided among several processors.

[0091] Such machine-readable instructions can also be stored in computer-readable storage, which can instruct a computer or other programmable data processing device to operate in a specific mode. For example, instructions can be provided on a non-transient computer-readable storage medium encoded with instructions that can be executed by a processor.

[0092] Figure 6 This is a schematic diagram of the machine as illustrated in the example. Machine 600 may be, for example, a system or device, user equipment, a network node or part thereof, or a server or other network entity or function. Machine 600 includes a processor 603 and a memory 605 for storing instructions 602 executable by the processor 603. The machine includes storage 609, which may be used to store data 601, such as configuration parameters and / or configuration, as referenced above. Figures 1 to 5 As described.

[0093] Instructions 607, executable by processor 603, enable machine 600 to establish a connection to a network node of the wireless access network, receive information related to data collection configuration parameters supported by the network node from the network node, and send at least a portion of the received information to a server for collecting training data, thereby enabling the server to request at least one data collection configuration for the UE that is adapted to the network node's configuration capabilities.

[0094] Therefore, machine 200 can implement one or more data collection configurations for the UE or its corresponding OTT server to suggest to the NW for training data collection methods in a scalable and efficient manner.

[0095] Such machine-readable instructions can also be loaded onto a computer or other programmable data processing device to cause the computer or other programmable data processing device to perform a series of operations to produce a computer-implemented process. Therefore, the instructions that execute on the computer or other programmable device provide operations for implementing functions specific to the processes(s) in the flowchart and / or the blocks(s) in the block diagram. Furthermore, the teachings herein can be implemented in the form of a computer or a software product such as a non-transitory machine-readable storage medium, which is stored in the storage medium and includes a plurality of instructions, such as machine-readable instructions, for causing a computer device to implement the methods described in the examples of this disclosure.

[0096] In some examples, certain methods can be executed in cloud computing or web-based environments. Cloud computing environments can provide a variety of services and applications via the Internet. These cloud-based services (e.g., Software as a Service, Platform as a Service, Infrastructure as a Service, etc.) can be accessed through other remote interfaces, such as web browsers or user devices. The various functionalities described herein can be provided through remote desktop environments or any other cloud-based computing environment.

[0097] Figure 7 This is a schematic representation of the method according to the example. In block 701, the means for the UE establishes a connection to a network node of the radio access network. In block 703, the means receives information from the network node relating to data collection configuration parameters supported by the network node. In block 705, the means sends at least a portion of the received information to a server for collecting training data to enable the server to request at least one data collection configuration for the UE and adapted to the network node's configuration capabilities.

[0098] The foregoing description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or limiting to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of this disclosure. The embodiments disclosed herein should be considered illustrative rather than restrictive in all respects. Reference should be made to the appended claims and their equivalents in determining the scope of this disclosure.

Claims

1. An apparatus for a user equipment (UE), comprising: At least one processor; as well as At least one memory, the at least one memory including instructions configured to influence data collection configuration in a wireless communication network, the instructions, when executed by the at least one processor, causing the device to at least: Establish connections to network nodes in the wireless access network; Receive information related to data collection configuration parameters supported by the network node from the network node; as well as Based at least in part on the received information, information is sent to a server for collecting training data to enable the server to request at least one data collection configuration, the at least one data collection configuration being targeted at the UE and adapted to network node configuration capabilities.

2. The apparatus of claim 1, wherein the apparatus is configured to at least: Send a request to the network for information indicating supported data collection configurations.

3. The apparatus of claim 2, wherein the apparatus is configured to at least: Together with the request, it includes at least one associated ID, wherein the at least one associated ID includes a mapping between training hypotheses and inference hypotheses based on selected physical or logical network conditions.

4. The apparatus according to claim 2 or 3, wherein the apparatus is configured to at least: Receive configuration identifier ID from the server; and The configuration ID is included in the request.

5. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: Receive an instruction from the server, the instruction being used to request information indicating supported data collection configurations.

6. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: Along with the information indicating supported data collection configuration, information related to the location of the device is sent to the server.

7. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: The collected measurement data is sent directly to the server via user plane communication or via network nodes.

8. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: The device receives an indication of a single request from the server, the single request being for information on data collection configuration supported by the indication, wherein the indication of the single request includes an aggregation of multiple requests originating from user equipment serving the same network node as the device.

9. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: Receive information from the network node relating to data collection configuration parameters supported by the network node, wherein the parameters include at least one of logical parameters and physical parameters, and wherein the information includes at least one of the following: At least one feasible configuration; A predefined set of parameters, which defines the values ​​or ranges of values ​​for one or more parameters to be configured by the network node; Instructions to perform CSI-RS measurements of the CSI reference signal for the selected frequency range; Multiple CSI-RS and their associated beamwidths; The maximum number of configurations or parameters that can be requested at one time; Applicable time period.

10. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: send location-related information to the server.

11. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: send a data collection configuration request to the network node, wherein the data collection configuration request includes parameter configuration adapted to the configuration capabilities of the network node.

12. The apparatus of claim 11, wherein the apparatus is configured to at least: send a configuration ID received from the server in addition to the data collection configuration request.

13. The apparatus of claim 11 or 12, wherein the apparatus is configured to at least: send information, received from the server, in addition to the data collection configuration request, and relating to the type and / or number of user devices and / or the required measurements.

14. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: receive from the server and forward a specific data collection configuration request to the network node, wherein the request includes parameter configuration adapted to the configuration capabilities of the network node.

15. The apparatus according to any of the preceding claims, wherein the apparatus is configured to at least: receive a data collection configuration in response to the data collection configuration request, perform data collection according to the received data collection configuration, and send a report related to the collected data to the server.

16. A method for communication, comprising: At the device used for user equipment (UE), a connection is established toward the network node of the radio access network; At the device, information related to data collection configuration parameters supported by the network node is received from the network node; as well as Based at least in part on the received information, the device sends information to a server for collecting training data to enable the server to request at least one data collection configuration, the at least one data collection configuration being targeted at the UE and adapted to network node configuration capabilities.

17. A computer-readable medium storing instructions that, when executed by a processor, perform the method according to claim 16.

Images