Method, apparatus and computer program product for collecting data from user equipment device

Abstract

A method, an apparatus, and a computer program product provide means for establishing a mechanism by which a network may configure a user device to determine how to handle an indication of a region of a user device location when establishing a network connection. One example method includes receiving a first indication of an area of a location of a device from a visited network, wherein the device includes a user equipment (UE); and determining whether the device will ignore the first indication for network selection based on a second indication in the device, wherein the second indication is received from the home network of the device via a container transparent to the visited network. The area of the device location may include a country of the device location. The container may include a direction control of the roaming transparent container. The container may be delivered via a rejection message.

Description

Technical Field

[0001] Example embodiments of the present disclosure generally relate to collecting data from user equipment devices, and more specifically, to collecting non-standardized data via a network that can be used to train artificial intelligence and machine learning models. Background Art

[0002] Mobile devices, such as cellular phones, tablet computers, etc., have evolved into instrumental tools with countless capabilities to benefit the device users. Mobile devices are ubiquitous and have an ever-increasing level of functionality. These mobile devices include a sensor suite that can collect data related to the user, the movement of the mobile device, and the environmental context of the mobile device, as well as other available information. The amount of data collected at the mobile device is substantial, and much of this data can be privacy sensitive.

[0003] The data available on mobile devices can be used for a variety of purposes. In addition, user anonymous data is beneficial in many cases, where the mobile device data provides useful information to service providers. The data collected on mobile devices can be collected in a variety of formats and include different data elements. The type of data and the format of the data can vary based on the device manufacturer, the operating system of the mobile device, the application through which certain data is collected, etc. Thus, although a large amount of data is available from an ever-increasing number of mobile devices, much of this data has little utility outside of a specific application or use case. Summary of the invention

[0004] Various embodiments generally relate to collecting data from user equipment devices, and more specifically, to collecting non-standardized data via a network that can be used to train artificial intelligence and machine learning models. Some embodiments provided herein include: at least one processor; and at least one memory including computer program code, at least one memory and computer program code configured to, together with at least one processor, cause the device to: determine a non-standardized data collection policy; based on the non-standardized data collection policy, receive a non-standardized data request; determine whether the non-standardized data request complies with the non-standardized data collection policy; provide a non-standardized data request that complies with the non-standardized data collection policy; provide the non-standardized data request to a user equipment UE device; receive data from the UE device in response to the non-standardized data request; and provide the data in a transparent container to an external server.

[0005] According to one embodiment, a non-standardized data request based on a non-standardized data collection policy is received from an external server. In one embodiment, data received from a UE device is received in a transparent container, wherein the data is decoded by the apparatus.

[0006] According to one embodiment, the device is further enabled to provide a non-standardized data collection policy to an external server. The non-standardized data collection policy of an embodiment includes an indication of the data content that is allowed to be transmitted from the UE device to the external server. According to one embodiment, the data content that is allowed to be sent is based on one or more of the following items: the type of data; configuration information, radio access network (RAN) area, network coverage area, g NodeB (gNB) service area, location management function (LMF) service area The geographical area for data collection. In one embodiment, a non-standardized data request to the UE device is provided in a transparent container. The data of one embodiment includes location data, wherein the external server uses the location data for artificial intelligence / machine learning model training.

[0007] According to one embodiment, the data content allowed to be transmitted is also based on one or more of a server identifier or a device identifier. According to one embodiment, a non-standardized data request includes a metadata field, and the metadata field describes the data to be collected in response to the non-standardized data request. According to one embodiment, the data in response to the non-standardized data request includes metadata in the metadata field, wherein the metadata field is not in a transparent container. According to one embodiment, the metadata includes one or more of the following items: the type of measurement data, the manufacturer or device information associated with the UE device, the geographic area of ​​data collection, the timestamp of data collection, the session information of the collected data, the quality information of the collected data, the amount of data collected, or the number of data samples collected. According to one embodiment, the non-standardized data collection policy includes the protocol in which the non-standardized data request should be signaled and an indication of the protocol required to carry the data collected in response to the non-standardized data request.

[0008] According to one embodiment, the non-standardized data request includes a physical layer signaling requirement, wherein the physical layer signaling requirement includes standardized configuration information of a signal associated with the non-standardized data request. The physical layer signaling requirement may include one or more of a downlink positioning reference signal (DL PRS) bandwidth, a number of transmission and reception points (TRP), or a quality of service (QoS). The device of the embodiment provides a request to at least one of the following items to establish the signaling required for the non-standardized data request: a location management function LMF or a g NodeB gNB. The device of the embodiment receives a response from at least one of the LMF or gNB associated with the actual setting of the LMF or gNB. According to one embodiment, the data in response to the non-standardized data request includes non-standardized data sent via a standardized data protocol. The standardized data protocol includes one or more of the following items: a long-term evolution LTE positioning protocol LPP or a radio resource control RRC.

[0009] An embodiment provided herein includes a computer program product, which includes at least one non-transitory computer-readable storage medium having computer-executable program code instructions stored thereon, the computer-executable program code instructions including program code instructions, which are configured when executed to: determine a non-standardized data collection policy; receive a non-standardized data request based on the non-standardized data collection policy; determine whether the non-standardized data request complies with the non-standardized data collection policy; provide a non-standardized data request that complies with the non-standardized data collection policy; provide the non-standardized data request to a user equipment UE device; receive data from the UE device in response to the non-standardized data request, wherein the data cannot be decodable by the network; and provide the data in a transparent container to an external server.

[0010] According to one embodiment, a non-standardized data request based on a non-standardized data collection policy is received from an external server. In one embodiment, data received from a UE device is received in a transparent container where the data is not visible to the network. According to an embodiment, the computer executable program code instructions also include program code instructions configured to provide a non-standardized data collection policy to an external server. The non-standardized data collection policy of the embodiment includes an indication of the data content that is allowed to be transmitted from the UE device to the external server. According to one embodiment, the data content that is allowed to be sent is based on one or more of the following items: the type of data, configuration information, radio access network (RAN) area, network coverage area, node B (gNB) service area, location management function (LMF) service area, or geographic area for data collection. In one embodiment, the data content that is allowed to be transmitted is also based on one or more server identifiers or device identifiers. In one embodiment, a non-standardized data request for a UE device is provided in a transparent container. The data of the embodiment includes location data, wherein the external server uses location-related data for artificial intelligence / machine learning model training. According to one embodiment, the non-standardized data request includes a metadata field that describes the data to be collected in response to the non-standardized data request.

[0011] According to one embodiment, the data in response to the non-standardized data request includes metadata in a metadata field, wherein the metadata field is not in a transparent container. According to one embodiment, the metadata includes one or more of the following items: the type of measurement data, the vendor or device information associated with the UE device, the geographical area of ​​data collection, the timestamp of data collection, the session information of the collected data, the quality information of the collected data, the amount of data collected, or the number of data samples collected. According to one embodiment, the non-standardized data request includes a physical layer signaling requirement, wherein the physical layer signaling requirement includes standardized configuration information of the signal associated with the non-standardized data request. The physical layer signaling requirement may include one or more of the following items: downlink positioning reference signal (DL PRS) bandwidth, the number of transmission and reception points (TRP), or quality of service (QoS). The computer program product of the embodiment includes program code instructions for providing a request to establish the required signaling for the non-standardized data request to at least one of a location management function (LMF) or a g NodeB (gNB). The computer program product of the embodiment includes program code instructions for receiving a response from at least one of the LMF or gNB associated with the actual establishment of the LMF or gNB. According to an embodiment, the data responsive to the non-standardized data request comprises non-standardized data sent via a standardized data protocol. The standardized data protocol comprises one or more of Long Term Evolution (LTE) Positioning Protocol (LPP) or Radio Resource Control (RRC).

[0012] An embodiment provided herein includes a method, which includes: determining a non-standardized data collection policy; receiving a non-standardized data request based on the non-standardized data collection policy; determining whether the non-standardized data request complies with the non-standardized data collection policy; providing a non-standardized data request that complies with the non-standardized data collection policy; providing the non-standardized data request to a user equipment (UE) device; receiving data from the UE device in response to the non-standardized data request; and providing the data in a transparent container to an external server.

[0013] According to one embodiment, a non-standardized data request based on a non-standardized data collection policy is received from an external server. In one embodiment, data received from a UE device is received in a transparent container in which the data is invisible to the network. According to one embodiment, the method includes providing a non-standardized data collection policy to an external server. The non-standardized data collection policy of the embodiment includes an indication of the data content allowed to be transmitted from the UE device to the external server. According to one embodiment, the data content allowed to be sent is based on one or more of the following items: measurement data, configuration information, radio access network (RAN) area, network coverage area, g NodeB (gNB) service area, location management function (LMF) service area data collection geographic area. In one embodiment, a non-standardized data request to a UE device is provided in a transparent container. The data of one embodiment includes location-related data, wherein the external server location-related data is used for artificial intelligence / machine learning model training.

[0014] According to one embodiment, the non-standardized data request includes a metadata field, and the metadata field describes the data to be collected in response to the non-standardized data request. According to an embodiment, the data in response to the non-standardized data request includes metadata in the metadata field, wherein the metadata field is not in a transparent container. According to one embodiment, the metadata includes one or more of the following items: the type of measurement data, the manufacturer or device information associated with the UE device, the geographical area of ​​data collection, the timestamp of data collection, the session information of the collected data, the quality information of the collected data, the amount of collected data, or the number of collected data samples. According to one embodiment, the non-standardized data request includes a physical layer signaling requirement, wherein the physical layer signaling requirement includes standardized configuration information of the signal associated with the non-standardized data request. The physical layer signaling requirement may include one or more of the following items: downlink positioning reference signal (DL PRS) bandwidth, the number of transmission and reception points (TRP), or quality of service (QoS). The method of the embodiment includes providing a request to at least one of the following items to establish the signaling required for the non-standardized data request: location management function LMF or gNodeB gNB. The method of an embodiment includes receiving a response from at least one of the LMF or the gNB associated with an actual setting of the LMF or the gNB. According to an embodiment, the data in response to the non-standardized data request includes non-standardized data sent via a standardized data protocol. The standardized data protocol includes one or more of a Long Term Evolution (LTE) Positioning Protocol (LPP) or a Radio Resource Control (RRC).

[0015] One embodiment provided herein includes a device comprising: a component for determining a non-standardized data collection policy; a component for receiving a non-standardized data request based on the non-standardized data collection policy; a component for determining whether the non-standardized data request complies with the non-standardized data collection policy; a component for providing a non-standardized data request that complies with the non-standardized data collection policy; a component for providing a non-standardized data request to a user equipment (UE) device; a component for receiving data from the UE device in response to the non-standardized data request; and a component for providing data in a transparent container to an external server.

[0016] According to one embodiment, a non-standardized data request based on a non-standardized data collection policy is received from an external server. In some embodiments, data received from a UE device is received in a transparent container where the data is not visible to the network. According to one embodiment, the device includes a component for providing a non-standardized data collection policy to an external server. The non-standardized data collection policy of the embodiment includes an indication of the data content allowed to be transmitted from the UE device to the external server. According to one embodiment, the data content allowed to be sent is based on one or more of the following items: the type of data, configuration information, radio access network (RAN) area, network coverage area, g NodeB (gNB) service area, location management function (LMF) service area / or geographic area for data collection. In one embodiment, the data content allowed to be sent is also based on one or more of a server identifier or a device identifier. In one embodiment, a non-standardized data request for a UE device is provided in a transparent container. The data of one embodiment includes location-related data, wherein the data related to the location of the external server is used for artificial intelligence / machine learning model training.

[0017] According to one embodiment, the non-standardized data request includes a metadata field, and the metadata field describes the data to be collected in response to the non-standardized data request. According to one embodiment, the data in response to the non-standardized data request includes metadata in the metadata field, wherein the metadata field is not in a transparent container. According to one embodiment, the metadata includes one or more of the following items: type of measurement data, vendor or device information associated with the UE device, geographic area of ​​data collection, timestamp of data collection, session information of the collected data, quality information of the collected data, amount of data collected, or number of data samples collected.

[0018] According to one embodiment, the non-standardized data request includes a physical layer signaling requirement, wherein the physical layer signaling requirement includes standardized configuration information of a signal associated with the non-standardized data request. The physical layer signaling requirement may include one or more of a downlink positioning reference signal (DL PRS) bandwidth, a number of transmission and reception points (TRPs), or a quality of service (QoS). The apparatus of the embodiment includes a device for providing a request to establish the required signaling for the non-standardized data request to at least one of a location management function (LMF) or a gNodeB (gNB). The apparatus of the embodiment includes a device for receiving a response from at least one of the LMF or gNB associated with the actual establishment of the LMF or gNB. According to an embodiment, the data in response to the non-standardized data request includes non-standardized data sent via a standardized data protocol. The standardized data protocol includes one or more of a long term evolution (LTE) positioning protocol (LPP) or a radio resource control (RRC).

[0019] One embodiment provided herein includes at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the apparatus to: receive a non-standardized data request having a non-standardized data collection strategy; collect measurements and non-standardized data according to the non-standardized data collection strategy; transmit the non-standardized data in a transparent container together with metadata according to the non-standardized data collection strategy. The apparatus of the embodiment is also configured to request a physical layer signaling requirement, wherein the physical layer signaling requirement includes standardized configuration information of a signal associated with the non-standardized data request. In one embodiment, the physical layer signaling requirement includes one or more of a downlink positioning reference signal (DL PRS) bandwidth, a number of transmission and reception points (TRPs), or a quality of service (QoS). The apparatus of the embodiment is also caused to request approval to transmit the non-standardized data together with the metadata field before sending the non-standardized data in the transparent container together with the metadata.

[0020] Embodiments provided herein include a computer program product having at least one non-transitory computer-readable storage medium having computer executable program code instructions stored therein. The computer executable program code instructions are configured to: receive a non-standardized data request having a non-standardized data collection strategy; collect measurements and non-standardized data according to the non-standardized data collection strategy; transmit the non-standardized data in a transparent container together with metadata according to the non-standardized data collection strategy. The computer program product of an embodiment also includes program code instructions for requesting a physical layer signaling requirement, wherein the physical layer signaling requirement includes standardized configuration information of a signal associated with the non-standardized data request. In one embodiment, the physical layer signaling requirement includes one or more of a downlink positioning reference signal (DL PRS) bandwidth, a number of transmission and reception points (TRPs), or a quality of service (QoS). The computer program product of an embodiment also includes program code instructions for requesting approval to transmit the non-standardized data together with the metadata field before sending the non-standardized data in the transparent container together with the metadata.

[0021] An embodiment provided herein includes a method comprising: receiving a non-standardized data request having a non-standardized data collection strategy; collecting measurements and non-standardized data according to the non-standardized data collection strategy; and transmitting the non-standardized data in a transparent container together with metadata according to the non-standardized data collection strategy. The method of the embodiment also includes requesting a physical layer signaling requirement, wherein the physical layer signaling requirement includes standardized configuration information of a signal associated with the non-standardized data request. In one embodiment, the physical layer signaling requirement includes one or more of a downlink positioning reference signal (DL PRS) bandwidth, a number of transmission and reception points (TRPs), or a quality of service (QoS). The method of the embodiment also includes requesting approval to transmit the non-standardized data together with the metadata field before sending the non-standardized data in the transparent container together with the metadata.

[0022] One embodiment provided herein includes an apparatus comprising: a component for receiving a non-standardized data request having a non-standardized data collection strategy; a component for collecting measurements and non-standardized data according to the non-standardized data collection strategy; and a component for transmitting the non-standardized data in a transparent container together with metadata according to the non-standardized data collection strategy. The apparatus of the embodiment also includes a component for requesting a physical layer signaling requirement, wherein the physical layer signaling requirement includes standardized configuration information of a signal associated with the non-standardized data request. In one embodiment, the physical layer signaling requirement includes one or more of a downlink positioning reference signal (DL PRS) bandwidth, a number of transmission and reception points (TRPs), or a quality of service (QoS). The apparatus of the embodiment also includes a component for requesting approval to transmit the non-standardized data together with the metadata field before sending the non-standardized data in the transparent container together with the metadata.

[0023] The above overview is provided only to summarize some example embodiments to provide a basic understanding of some aspects of the present disclosure. Therefore, it should be understood that the above embodiments are only examples and should not be interpreted as narrowing the scope or spirit of the present invention in any way. It should be understood that in addition to the embodiments summarized here, the scope of the present invention also includes many possible embodiments, some of which will be further described below. Other features, aspects and advantages of this theme will become apparent from the specification, drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Having thus generally described certain example embodiments of the present disclosure, non-limiting and non-exhaustive embodiments of the present disclosure will now be described with reference to the accompanying drawings, which are not necessarily drawn to scale. The components shown in the drawings may or may not be present in certain embodiments described herein. Some embodiments may include fewer (or more) components than those shown in the drawings.

[0025] Figure 1 An overview of an example mobile network (e.g., 5GS) according to an example embodiment of the present disclosure is shown;

[0026] Figure 2 A block diagram of an example apparatus according to an example embodiment of the present disclosure is provided;

[0027] Figure 3 is a signal flow diagram of a method for collecting non-standardized data according to an example embodiment of the present disclosure;

[0028] Figure 4 A method for collecting non-standardized data according to an exemplary embodiment of the present disclosure is provided. Figure 3 Continuation of the signal flow graph;

[0029] Figure 5 is a signal flow diagram of another method for collecting non-standardized data according to an example embodiment of the present disclosure; and

[0030] Figure 6 is a flow chart of a method for collecting non-standardized data according to an example embodiment of the present disclosure. DETAILED DESCRIPTION

[0031] Some embodiments of the present invention will now be described more fully below with reference to the accompanying drawings, in which some but not all embodiments of the present invention are shown. In fact, various embodiments of the present invention can be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; on the contrary, these embodiments are provided so that the present disclosure will satisfy applicable legal requirements. The same reference numerals always represent the same elements. As used herein, the terms "data", "content", "information", "electronic information", "signal", "command" and similar terms are used interchangeably to refer to data that can be captured, transmitted, received and / or stored according to various embodiments of the present invention. Therefore, the use of any such terms should not be used to limit the spirit and scope of the embodiments of the present disclosure. In addition, in the case where a first computing device is described herein as receiving data from a second computing device, it should be understood that the data can be received directly from the second computing device, or can be received indirectly via one or more intermediate computing devices, such as one or more servers, repeaters, routers, network access points, base stations, hosts, repeaters, etc., sometimes referred to as "networks" herein. Similarly, where a first computing device is described herein as sending data to a second computing device, it should be understood that the data may be sent or transmitted directly to the second computing device, or may be sent or transmitted indirectly via one or more intermediate computing devices, such as, for example, one or more servers, remote servers, cloud-based servers (e.g., cloud utilities), repeaters, routers, network access points, base stations, hosts, repeaters, and the like.

[0032] The term "including" means including but not limited to and should be interpreted in the manner in which it is commonly used in a patent context. The use of broader terms such as includes, comprises, and having should be understood to provide support for narrower terms such as consisting of, consisting essentially of, and consisting essentially of. Furthermore, to the extent that the terms "including" and "comprising" and variations thereof are used in the detailed description or claims, these terms are intended to be inclusive in a manner similar to the term "comprising".

[0033] The phrases "in one embodiment," "according to one embodiment," "in some embodiments," "in various embodiments," and the like generally refer to the fact that the particular feature, structure, or characteristic following the phrase may be included in at least one embodiment of the present disclosure, but not necessarily all embodiments of the present disclosure. Thus, a particular feature, structure, or characteristic may be included in more than one embodiment of the present disclosure, such that these phrases are not necessarily referring to the same embodiment.

[0034] As used herein, the terms "example," "exemplary," and the like are used to mean "serving as an example, instance, or illustration." Any implementation, aspect, or design described herein as an "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations, aspects, or designs. Rather, the use of the terms "example," "illustrative," and the like are intended to present concepts in a concrete manner.

[0035] If the specification states that a component or feature "may", "may", "can", "should", "preferably", "likely", "typically", "optionally", "for example", "often" or "likely" (or other such language) is included or has a property, the particular component or feature need not be included or have that property. Such components or features may optionally be included in some embodiments, or may be excluded.

[0036] As used herein, the term "computer-readable medium" refers to non-transitory storage hardware, non-transitory storage device, or non-transitory computer system memory that can be accessed by a controller, microcontroller, computing system, or module of a computing system to encode computer-executable instructions or software programs thereon. The non-transitory "computer-readable medium" can be accessed by a computing system or module of a computing system to retrieve and / or execute computer-executable instructions or software programs encoded on the medium. Examples of non-transitory computer-readable media may include (but are not limited to) one or more types of hardware memory, non-transitory tangible media (e.g., one or more magnetic storage disks, one or more optical disks, one or more USB flash drives), computer system memory, or random access memory (e.g., DRAM, SRAM, EDORAM), etc.

[0037] In addition, as used herein, the term "circuitry" refers to (a) a hardware circuit implementation only (e.g., an implementation in analog circuits and / or digital circuits); (b) a combination of a circuit and a computer program product including software and / or firmware instructions stored on one or more computer-readable memories that work together to cause the device to perform one or more functions herein; and (c) a circuit, such as a microprocessor or a portion of a microprocessor, that requires software or firmware for operation, even if the software or firmware is not physically present. This definition of "circuitry" applies to all uses of this term herein, including in any claims. As another example, as used herein, the term "circuitry" also includes an implementation including one or more processors and / or portions thereof and accompanying software and / or firmware. As another example, as used herein, the term "circuitry" also includes, for example, a baseband integrated circuit or an application processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, other network devices (e.g., a core network device), a field programmable gate array, and / or other computing devices.

[0038] Mobile devices are highly capable computers that use sensor arrays that generate large amounts of data. Most of this data is collected for specific use cases within applications or by service providers for specific purposes. However, the data collected at mobile devices can be widely used in a variety of services and service providers. These mobile devices, along with other types of computing devices, are referred to here as user equipment (UE). In addition, with the advancement of artificial intelligence (AI) and machine learning (ML) models, the collection of training data is beneficial to improving these models and making them more accurate and useful. The embodiments described here are dedicated to utilizing the large amounts of data available on mobile devices to provide a large amount of training data, which will benefit AI / ML models while maintaining the privacy of users of mobile devices.

[0039] In order to train the AI / ML model, an entity such as an external vendor server (e.g., a mobile device manufacturer, a mobile device service carrier, a mobile device chip manufacturer, etc.) needs to collect data from the network. Depending on the AI / ML model, different types of data may be sought. One such type involves uplink (UL) / downlink (DL) positioning-related measurements and / or UE location information. Most positioning-related data has been standardized within the positioning service (LCS) / LTE positioning protocol (LPP) framework. For example, time-based or angle-based measurements and user equipment (UE) location information (e.g., one or more of absolute location coordinates, measurements, general location information, etc.) are explicitly defined within the corresponding fields in the LPP message.

[0040] While standardized data is relatively straightforward to process, it is not possible to specify / standardize all data required by an AI / ML model. For example, since each vendor may develop and deploy arbitrarily different models, the vendor may not disclose the model inputs. UE vendors may wish to train their models outside of the 3GPP (3rd Generation Partnership Project) standardized methods that take into account non-standardized auxiliary inputs (e.g., signal-to-noise ratio (SNR), Doppler, sensor measurements, etc.). For example, the UE may use Doppler measurements as model inputs, which are not specified in the LPP. Similarly, the UE may be able to use unconfigured measurements, where the UE may passively monitor any ongoing DL PRS (positioning reference signal) transmissions for which it is not configured, through an internal implementation that will be used as a model input to the UE-side AI / ML model.

[0041] Collecting non-standardized data, such as for training as well as monitoring, retraining and updating UE-side AI / ML models, is of particular interest to UE vendors. UE vendors may develop AI / ML models for UEs taking into account different UE categories, power and computing capabilities of UEs, and may not disclose such details of their AI / ML models for positioning purposes deployed at the UE, which may be part of a proprietary algorithm. According to some embodiments, it may not be practical or even possible to standardize each granularity required by different vendors (e.g., 1dB step RSRP (reference signal received power), 0.25dB step, etc.) to a point where inefficient signaling (e.g., floating point) is required to cover all different possible situations. In addition, according to some embodiments, it is not feasible to add new data types for non-standardized data collection as a definition requirement, generate a protocol in RAN2 (Radio Layer 2), and then wait for delays between all RANs (Radio Access Networks) to integrate the changes into the specification. Such a process may take more than six months, not including the implementation and deployment time that may double or triple that time period.

[0042] Currently, there is no framework for UE vendor servers to collect non-standardized positioning related data from 3GPP networks. Specifically, for offline training of AI / ML models on the UE side, the existing positioning framework is not suitable for data collection. Therefore, further enhancements are needed. The example embodiments described here control the flow of data to external parties through the network, where the data sent does not need to be standardized.

[0043] The exemplary embodiments described herein collect data from UE devices for AI / ML training data, which is used by the vendor server to generate, build and train the AI / ML model used at the UE. The embodiments employ a framework for the network to enable control and management of non-standardized data collected by a vendor server (e.g., an OTT (over-the-top) server) external to the UE, which the vendor server uses to train, as well as monitor, retrain and update the UE-side model.

[0044] According to an example embodiment, the network may define conditions on what and how the UE may report to a vendor server external to the UE in the form of a non-standardized data collection policy. For example, the network may define a policy as "X type of measurements from a specific area / area of ​​interest / cell / time may be shared with vendor Y's server". After acquiring such a policy, the external vendor server may send a request to the network for non-standardized data collection based on the policy. The request may include, for example: a) metadata fields; b) transparent containers (e.g., data containers that transmit transparent or invisible data to the network); and c) physical layer (PHY) signaling requirements, which may be optional.

[0045] The metadata field may indicate any standardized information associated with the non-standardized data collection request in order to enable as much network control over the data collection as possible, such as the type of data requested (e.g., DL PRS measurements), vendor information of the UE / server, area / time related information of the requested data, size of the requested data, etc. The transparent container contains the actual UE-vendor / implementation specific requirements / requests for the non-standardized data collection, which are only visible to the UE and not to the network (e.g., non-standardized Doppler measurement request). The PHY signaling requirements indicate standardized configuration information of the signal associated with the requested data collection, such as DL PRS bandwidth, number of TRPs (transmission and reception points), etc. These standardized configuration information are required to collect non-standardized data, and the network may set this standardized configuration information to assist in non-standardized data collection. The PHY signaling requirements are optional elements, and the network may not have to set such required signaling configuration in the network for data collection.

[0046] The network may trigger any relevant data collection entities (e.g., LMF for positioning) based on a request from an external vendor server and let the UE know what is actually being requested, such as by forwarding a transparent container and optionally configuring any necessary PHY signaling (e.g., DL PRS sent by the gNB to enable non-standardized data collection). The inclusion of data collection entities such as LMF does not need to be involved and may only involve specific use cases that require and / or benefit from such involvement. In the case of LMF, the involvement is based on the positioning use case and is merely an example of a relevant data collection entity. In other embodiments, such as for CSI or beam management use cases, the management entity may trigger one or more gNBs to request the necessary signaling. After collecting the requested non-standardized data, the UE provides the collected data back to the external server via the network via a transparent container, accompanied by metadata that complies with the data collection policy. The example embodiments provided herein enable the network to gain control over the collection and transmission of non-standardized data without necessarily requiring access to the actual content of the collected data.

[0047] The example embodiments described herein can be implemented on a network. Figure 1 , an example mobile network 100 is shown. Mobile network 100 (also known as a cellular network) is a type of network in which at least the last link is wireless and provides voice and / or data services to multiple devices. Mobile network 100 can be a third generation (3G), fourth generation (4G) and / or next generation (e.g., fifth generation or 5G) network.

[0048] Mobile network 100 is shown as providing communication services to UE 110. UE 110 may be enabled for voice services, data services, machine-to-machine (M2M) or machine-type communication (MTC) services, Internet of Things (IoT) services, and / or other services. UE 110 may be an end-user device such as a mobile phone (e.g., a smart phone), a tablet or PDA, a computer with a mobile broadband adapter, and the like.

[0049] The mobile network 100 includes one or more radio access networks (RAN 120) that communicate with the UE 110 through a radio interface. The RAN 120 of an exemplary embodiment may support 5G, wireless local area network (WLAN) access, fixed access, satellite radio access, new radio access technology (RAT), etc. As an example, the RAN 120 may be implemented by one or more base stations 124 scattered over a geographical area. The base station 124 may include an entity that communicates with the UE on a licensed spectrum using radio communication technology and interfaces the UE with the core network 130. The base station 124 in the NG-RAN may be referred to as a gNodeB (NR base station) and / or an ng-eNodeB (LTE base station supporting a 5G core network). As another example, the RAN 120 may include a WLAN that includes one or more wireless access points (WAPs). A WLAN is a network in which a UE can connect to a local area network (LAN) through a wireless (radio) connection. A WAP is a node that communicates with a UE on an unlicensed spectrum using radio communication technology and provides the UE with access to the core network. An example of a WAP is a Wi-Fi access point operating in the 2.4 GHz or 5 GHz radio frequency band. The term "base station" may refer to an eNodeB, a gNodeB, an ng-eNodeB, a WAP, etc.

[0050] UE 110 is able to attach to a cell of RAN 120 to access core network 130. Thus, RAN 120 represents a radio interface between UE 110 and core network 130. Core network 130 is a central part of mobile network 100 that provides various services to customers connected through RAN 120. One example of core network 130 is an evolved packet core (EPC) network as described by 3GPP for LTE. Another example of core network 130 is a 5G core (5GC) network as described by 3GPP. Core network 130 includes network elements 132, which may include servers, devices, apparatuses, or equipment (including hardware) that provide services to UE 110. Network elements 132 in the EPC network may include a mobility management entity (MME), a serving gateway (S-GW), a packet data network gateway (P-GW), and the like. The network elements 132 in the 5G network may include access and mobility management function (AMF), location management function (LMF), session management function (SMF), user plane function (UPF), policy control function (PCF), unified data management (UDM), etc.

[0051] The core network 130 may communicate with third-party entities, such as a vendor server 136, which may include a service provider server (e.g., a cellular carrier server), a device manufacturer server, a component (e.g., a microchip) manufacturer server, etc. The vendor server may provide one or more services to the UE, and according to certain example embodiments described herein, train, build, and improve AI / ML models related to the services provided by the vendor server. To this end, the vendor server may collect data from the UE over the network, as described herein.

[0052] Reference now Figure 2 , an example apparatus 300 is provided. In some cases, apparatus 300 may be an embodiment of UE 110 and / or may be implemented by or otherwise associated with UE 110. Alternatively, apparatus 300 may be an embodiment of network element 132, or may be implemented by or otherwise associated with network element 132.

[0053] The apparatus 300 may include a processor 302, a memory 304, and a network interface 306. The apparatus 300 may be configured to perform the operations described herein. Although these components are described with respect to the performance of various functions, it should be understood that a particular implementation must include the use of specific hardware. It should also be understood that some of these components may include similar or common hardware. For example, two sets of circuit systems may utilize the use of the same processor, network interface, storage medium, etc. to perform their associated functions, so that each set of circuit systems does not require duplicate hardware.

[0054] In some embodiments, the processor 302 (and / or a coprocessor or any other processing circuit system assisting or otherwise associated with the processor) can communicate with the memory 304 via a bus for transferring information between components of the device. The memory 304 is non-transitory and can include, for example, one or more volatile and / or non-volatile memories. In other words, for example, the memory 304 can be an electronic storage device (e.g., a computer-readable storage medium). The memory 304 can be configured to store information, data, content, applications, instructions, etc. for enabling the apparatus to perform various functions according to the example embodiments disclosed herein.

[0055] The processor 302 can be implemented in a variety of different ways, and can include, for example, one or more processing devices configured to execute independently. In some non-limiting embodiments, the processor 302 can include one or more processors configured in series via a bus to enable independent execution of instructions, pipelining, and / or multithreading. The use of the term "processor" can be understood to include a single-core processor, a multi-core processor, multiple processors within a device, and / or a remote or "cloud" processor.

[0056] In some embodiments, the processor 302 may be configured to execute instructions stored in the memory 304 and / or circuitry accessible to the processor 302. In some embodiments, the processor 302 may be configured to perform hard-coded functions. Thus, whether configured by hardware or software methods, or by a combination thereof, the processor 302 may represent an entity (e.g., physically contained in a circuitry) capable of performing operations according to the embodiments disclosed herein, while being configured accordingly. Alternatively, as another example, when the processor 302 is implemented as an executor of software instructions, the instructions may specifically configure the processor 302 to perform the algorithms and / or operations described herein when executing the instructions.

[0057] In some embodiments, the apparatus 300 may include input / output circuitry that in turn may communicate with the processor 302 to provide output to a user and / or other entity, and in some embodiments, receive an indication of an input. The input / output circuitry may include a user interface and may include a display, and may include a web user interface, a mobile application, a query initiating computing device, etc. The processor and / or user interface circuitry including the processor may be configured to control one or more functions of one or more user interface elements via computer program instructions (e.g., software and / or firmware) stored on a memory accessible to the processor (e.g., memory 304, etc.).

[0058] The network interface 306 can be any device, such as a device or circuit system implemented in hardware or a combination of hardware and software, which is configured to receive and / or send data from / to a network and / or any other device, circuit or module that communicates with the device 300. In this regard, the network interface 306 may include, for example, a network interface for implementing communication with a wired or wireless communication network. For example, the network interface 306 may include one or more network interface cards, antennas, buses, switches, routers, modems, and any other device that supports hardware and / or software or is suitable for implementing communication via a network. Additionally or alternatively, the network interface 306 may include a circuit system for interacting with an antenna / multiple antennas to cause signal transmission via the antenna / multiple antennas or processing the reception of signals received via the antenna / multiple antennas.

[0059] It should also be noted that all or some of the information discussed herein may be based on data received, generated and / or maintained by one or more components of the device 300. In some embodiments, one or more external systems (such as remote cloud computing and / or data storage systems) may also be utilized to provide at least some of the functionality discussed herein.

[0060] The embodiments described herein provide for the collection of non-standardized data according to predetermined policies that enable efficient and accurate generation of a corpus of training data for AI / ML models. A management entity within the network may manage the processes of the example embodiments. The entity may be a core network (CN) entity or function, for example, for positioning AI / ML use cases, it may be a LMF and / or NWDAF (network data analysis function). Under other AI / ML use cases, the management entity may include a RAN node, such as a gNodeB. The management entity may optionally include a trace collection entity (TCE), which may be used, for example, to minimize drive tests (MDT). The management entity may optionally be or be part of OAM (operation, maintenance and management), such as having control over the CN and / or RAN.

[0061] according to Figure 3 In the illustrated embodiment, the management entity 410 is an entity separate from the LMF 420 or gNB 430. Alternatively, a single / centralized management entity / network function for data collection may be responsible for all AI / ML related use cases, which may then communicate with the corresponding entity for each use case (e.g., LMF 420 for positioning). As shown at 412, the management entity determines a policy regarding non-standardized data collection. The policy may be shared with external parties and / or UE 400.

[0062] The policy may include various information, such as allowed / disallowed data content that may be transmitted (e.g., from the UE to an external server), metadata fields that the UE needs to indicate when transmitting data, and / or whether a specific protocol needs to be used when transmitting data. The allowed / disallowed data content that may be transmitted may be defined with respect to the type of data (e.g., positioning measurements, CSI measurements, DL PRS measurements, time / angle / power / phase based measurements, GNSS data, Bluetooth data, sensor data, etc.). The allowed data content may be about the entities / resources involved in the creation of the data (e.g., whether the gNB is used to transmit the signal, their identifiers, etc.) or information associated with the measurement (e.g., allowed configuration information, etc.). The allowed / disallowed (allowed) data may be related to the collected data or the area to which the UE / gNB belongs (e.g., notification area, geographic area, service area, etc.). The allowed / disallowed data may also be related to the vendor / equipment of the UE or gNB involved (e.g., manufacturer, hardware, software information). In some cases, there may be privacy agreements (eg, GDPR or General Data Protection Regulation) with different vendors to collect or share data from the network, which can be used to determine policy.

[0063] The metadata fields that the UE needs to indicate when transmitting data may include the type of data measurement, the vendor / device information of the UE, the region / timestamp information of the data, any session information data (e.g., a specific LPP (LTE Positioning Protocol) session for positioning), or characteristics of the data (e.g., quality, likelihood, estimated confidence level for each sample, each data set, etc.). Policy information on whether a specific protocol (e.g., LPP, RRC (Radio Resource Control), NRPPa (NR Positioning Protocol A), UAI (User Assistance Information), etc.) needs to be used when transmitting data. For example, when transmitting location-related measurements or more generally, non-standardized data, the UE may be required to send it via LPP through the LMF, or alternatively, via the gNB through the LMF with RRC+NRPPa protocol. For CSI or beam management use cases, embodiments may include the UE first sending the non-standardized data to the gNB via a standardized protocol (e.g., RRC or Medium Access Control Control Element (MAC CE)), and the gNB then sending the non-standardized data to the management entity.

[0064] The policy is implementation specific and may be appropriately configured by the OAM or network vendor. As part of the configuration, any identifiers of external servers, such as their IP addresses, may be registered in order to control the data transmitted to the external servers. The management entity provides the policy to the external server / vendor and / or UE, either unsolicited or upon request (from the external server and / or UE), as well as providing notifications about any updates to the policy.

[0065] According to the embodiments described herein, the LMF is a management entity and may provide such policy information to the UE via LPP assistance data or via the gNB using NRPPa+RRC messages. The message may be broadcast, multicast, or unicast. Similarly, communication between the LMF and the gNB may be performed using the NRPPa protocol. According to an embodiment, the order of policy determination based on the propagation of allowed / not allowed content and policies may be different from the illustrated embodiments described below. For example, a request for a policy may first be received from the UE, where the management entity then determines a policy that it may then provide to the manufacturer server.

[0066] Figure 3The policy determination and provision at 414 is shown. In the illustrated embodiment, a policy is determined at 412 for a non-standardized data collection policy. The vendor server 440 sends a request for the policy to the management entity 410. The management entity 410 then provides the policy to the vendor server 440. The UE 400 provides the request for the non-standardized data collection policy to the management entity 410, and the management entity in return provides the policy to the UE. Regardless of the order of operations of the policy determination and provision, the policy determination ensures that all entities are aware of the policy for non-standardized data collection.

[0067] Figure 3 The embodiment of FIG. 4 shows a non-standardized data request from the vendor server 440 to the management entity 410 at operation 1. The request for data collection includes data content corresponding to a previously determined policy. The request includes metadata, a transparent container, and optional physical layer signaling requirements.

[0068] The metadata field indicates any standardized information associated with the non-standardized data collection request to enable network control of data collection as much as possible. Metadata may include the identity of the UE requested for data collection, such as IMEI-TAC (International Mobile Equipment Identity-Type Allocation Code). Metadata may optionally include the type of data requested, such as DL PRS measurement, DL measurement, TRP measurement, time / angle / power / phase-based measurement, etc. Metadata may also include manufacturer / device information, such as the entity involved in the requested data and the manufacturer, hardware, software information of the requesting entity, etc. Metadata may include regional information such as notification area, geographic area, serving cell, etc. of the requested data. Time-related information of the requested data (such as date, time frame, period, on-demand / event trigger information) may be included in the metadata. Metadata may also include the size of the requested data, such as the number of measurements / samples, data volume, etc. Other metadata may be included in the request as needed.

[0069] A transparent container is a data container that is transparent to the network, as the container or the contents of the container are not visible in the network. The transparent container of an embodiment includes actual UE vendor / implementation specific requirements / requests for non-standardized data collection, which is only visible to the UE and not necessarily to the network. An example includes a non-standardized Doppler measurement request.

[0070] Optional physical layer (PHY) signaling requirements indicate standardized configuration information of signals associated with the requested data collection, such as DL PRS bandwidth, number of TRPs, etc. These standardized configuration information are necessary for collecting non-standardized data, and the network can set the standardized configuration information to assist in the collection of non-standardized data. In an exemplary embodiment, QoS (quality of service) requirements for related use cases, such as positioning accuracy, can be indicated, which can be further associated with or optionally sent to the PHY signaling requirements. Physical layer signaling requirements are optional, and the network may not have to set up such required signaling configuration in the network for data collection. The management entity 410 can accept or reject the request. For example, if the request does not comply with the non-standardized data collection policy, the request can be rejected.

[0071] Although Figure 3 Operation 1 of FIG. 4 shows a non-standardized data request sent from the manufacturer server 440 to the management entity 410, but the request from the server can be forwarded via the UE 400, so that the server first sends the request to the UE, which is transparent to the network management entity 410. The UE 400 can then disclose the request to the network by sending the request to the management entity 410. In another embodiment, the request is sent from the manufacturer server 440 to the UE 400 via the management entity 410.

[0072] When a non-standardized data request is received at the management entity 410, the management entity determines the network entities involved in the requested data, such as LMF for positioning and gNB for CSI feedback use cases for AI / ML models, respectively. The management entity 410 may obtain information about the serving LMF and serving neighbors / gNBs of the involved UE(s) from other CN entities such as AMF (Access and Mobility Management Function).

[0073] According to another embodiment, the management entity may select the relevant network entity (e.g., gNB) based on the metadata fields of the request (e.g., depending on the region information, vendor information, etc.). For example, if the request involves data collection from a specific cell / region, the management entity may select the gNB or LMF serving the requested region. In addition, the management entity may accept / reject the request for non-standardized data collection from an external server before forwarding it to other involved entities.

[0074] If the request complies with the non-standardized data collection policy, the management entity 410 may send the request to the LMF 420 as shown in operation 3. Based on the policy, the management entity 410 notifies the involved entities of the request. The requested metadata and optional PHY signaling requirements may be forwarded to the determined network entities, such as the LMF 420 and the gNB 430, and the transparent container may be forwarded to the UE 400 (such as Figure 4 ).

[0075] Figure 3 Also shown is operation 4, an optional process for establishing the required physical layer signaling. The entities involved may configure the required PHY signaling based on the requested information. The LMF may configure the gNB / TRP to send a DL PRS with certain characteristics (e.g., bandwidth, periodicity) to enable the UE 400 to collect the requested non-standardized data. In an example embodiment, the network entities involved may accept or reject the request (e.g., for PHY signaling) from the management entity, for example, based on resource availability. In the event that the network entities involved configure PHY signaling different from the PHY signaling indicated in the request, for example due to resource constraints, the difference may be indicated to the management entity, which may notify the external server (e.g., such as a server) when providing a response. Figure 4 For example, if the server requires 200 MHz DL PRS transmission, but the LMF is only configured with 100 MHz, the resource constraint cannot accommodate the requested PHY signaling.

[0076] Figure 3 The signal diagram is Figure 4 Continue, Figure 4 Operation 5 is shown. Operation 5 depicts UE 400 performing data collection upon receiving a transparent container for a non-standardized data request and any associated configuration for required PHY signaling. If the requested data is not yet available at the UE, the data collection may include measurements. In some embodiments, the request may be for real-time data, current session data, historical session data, a certain period of a session, etc. The request to the UE for data collection may be for a specific UE. However, the request may be non-UE specific, such as if the request is broadly applicable to UEs within a specific geographic area, UEs that meet specific standards, etc. The manufacturer server 440 may set rules for UEs to receive requests. These rules may be found, for example, in metadata and policies.

[0077] exist Figure 4In operation 6, the UE provides a response to the data request with a container (e.g., a transparent container) that is invisible to the network but visible to the external server 440. The container contains the actual collected non-standardized data, as well as mandatory metadata fields that follow the non-standardized data collection policy. The metadata field can contain the information in the data collection request, such as describing the data content with standardized fields, or simply it can consist of the requested identification / session information. The requested data, including the metadata and the transparent container including the non-standardized data, is forwarded from the management entity 410 to the manufacturer server 440.

[0078] exist Figure 5 Another embodiment of a signal flow for non-standardized data collection is shown in FIG. Figure 3 and Figure 4 In the described embodiment, before (or after) operation 1, the management entity 510 may determine a policy for non-standardized data collection and share the policy with the vendor server 540 and / or the UE 500. In addition, the management entity 510 may optionally share the policy internally with network entities such as the LMF 520 and / or (multiple) gNBs 530. These Figure 5 The operation 0 is shown.

[0079] Figure 5 The external vendor server 540 of the embodiment of the present invention sends a non-standardized data collection request directly to the involved (multiple) UEs 500 in a manner transparent to the network and management entity 510. The request may indicate any optional PHY signaling requirements. In operation 2, the UE 500 may request the necessary configuration from the involved network entity (e.g., LMF 520) for positioning-related data collection.

[0080] As in Figure 3 and Figure 4As found in the embodiment of the present invention, the UE collects standardized data and / or non-standardized data including any measurement data in operation 3. Optionally, in operation 4, the UE 500 then requests permission from the management entity 510 to transmit the collected non-standardized data to the external manufacturer server 540 by indicating the metadata field associated with the collected data. The UE 500 may first send the request to the network entities involved, such as to the LMF 520 via LPP in the case of positioning related data, or to the gNB 530 via RRC in the case of CSI related data. These entities may accept / reject the request based on the data collection policy provided to these entities by the management entity in operation 0. In some embodiments, operation 4 is optional. That is, when the policy is provided in operation 0, the framework may trust the UE 500 and the manufacturer server 540, and further requests for each data transmission individually may not be required, which may be indicated as part of the policy and may be confirmed (or not confirmed) by the UE 500 and / or the manufacturer server 540. Based on the permission, UE 500 transmits the non-standardized data to the external server in a manner transparent to the network (eg, management entity 510), such as using a transparent container.

[0081] The embodiments described herein provide significant improvements to the functionality of the computer itself. Specifically, the exemplary embodiments enable third-party devices such as those implemented by a manufacturer's server to identify and collect non-standardized data from UE devices. UE devices are a rich source of data; however, much of the collected data may be in a non-standardized form that is specific to the device (e.g., manufacturer), software, application, or sensor suite of the device. The exemplary embodiments provided herein comply with policies established at a network management entity to request and collect non-standardized data in a manner that can process non-standardized data to increase the amount of data available to third parties. According to an exemplary embodiment, the data is used to build and train AI / ML models. AI / ML models benefit from larger amounts of training data, so that the ability to use non-standardized data substantially increases the amount of training data available. Therefore, the exemplary embodiments described herein improve the construction and training of AI / ML models, which improves the functionality of such models and computers on which they are used to generate accurate and useful outputs.

[0082] The embodiments described herein address the network-centric challenge of collecting data over wireless communication channels to build and train AI / ML models. The challenge addressed by the embodiments is to enable vendor servers to access previously unavailable non-standardized data by means of non-standardized data request policies that allow access to non-standardized data while shielding data collected from network management entities. This enables vendors or external servers to request and obtain non-standardized data in a manner that was previously unavailable based on non-standardized data request policies.

[0083] Notwithstanding the foregoing, the embodiments described herein are implemented in real-world applications that support AI / ML model creation and training that use amounts of data that were previously unavailable to vendors or external servers. This increases the speed at which accurate and useful AI / ML models can be built, as the models do not need to rely on standardized data, and can request non-standardized data that is specifically requested to meet the needs of the AI / ML model in ways that were not previously possible.

[0084] Figure 6 A flowchart of an example embodiment of a method for collecting non-standardized data that can be used to train artificial intelligence and machine learning models via a network is shown. At 710, a non-standardized data collection strategy is determined. The strategy can be determined, for example, by a management entity in the network, which can be determined by Figure 2 The apparatus 300 of the embodiment is implemented using a component such as a processor 302. As shown at 720, a non-standardized data request can be received based on a non-standardized data collection policy, for example, by a component, such as a network interface 306 of the device and / or at the processor 302. It is then determined at 730 whether the data request complies with the non-standardized data collection policy, for example, by the processor 302 of the apparatus 300. At 740, the non-standardized data request is provided to the UE device, for example, by means of the network interface 306 indicated by the processor 302 of the apparatus 300. At 750, data is received from the UE device in response to the standardized data request, such as data in a transparent container. This can be received, for example, by a device such as the network interface 306 and / or the processor 302. The transparent container makes the data transparent, that is, the network is not visible / available when the data is sent. The data (such as in a transparent container) is then provided to an external server at 760, which can be performed by a component such as the network interface 306 and / or the processor 302.

[0085] Figure 6A flowchart depicting the operation according to an example embodiment of the present disclosure is shown. It should be understood that each block of the flowchart and the combination of blocks in the flowchart can be implemented by various means, such as hardware, firmware, processor, circuit system and / or other communication devices associated with the execution of software including one or more computer program instructions. For example, one or more of the above processes or operations can be implemented by computer program instructions. In this regard, the computer program instructions embodying the above processes or operations can be stored by the memory 304 of the device (e.g., device 300, UE 110) using an embodiment of the present invention and executed by the processor 302. It is understood that any such computer program instructions can be loaded onto a computer or other programmable device (e.g., hardware) to produce a machine so that the resulting computer or other programmable device implements the functions specified in the flowchart box. These computer program instructions can also be stored in a computer-readable memory, which can instruct a computer or other programmable device to work in a specific manner so that the instructions stored in the computer-readable memory produce a product, and the execution of the product implements the functions specified in the flowchart box. The computer program instructions may also be loaded onto a computer or other programmable device to cause a series of operations to be performed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide operations for implementing the functions specified in the flowchart block.

[0086] Therefore, the blocks of the flowchart support a combination of means for performing the specified functions and a combination of operations for performing the specified functions, for performing the specified functions. It will also be understood that one or more blocks of the flowchart and a combination of blocks in the flowchart can be implemented by a computer system based on dedicated hardware that performs the specified functions or a combination of dedicated hardware and computer instructions.

[0087] Many modifications and other embodiments of the invention set forth herein will occur to those skilled in the art with the benefit of the teachings presented in the above description and the associated drawings. Therefore, it should be understood that the invention is not limited to the specific embodiments disclosed, and modifications and other embodiments are intended to be included within the scope of the appended claims.

[0088] In addition, although the above description and the associated drawings describe example embodiments in the context of certain example combinations of elements and / or functions, it should be understood that different combinations of elements and / or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, as may be set forth in some of the appended claims, combinations of elements and / or functions different from those explicitly described above are also contemplated. Although specific terms are used herein, they are only used in a general and descriptive sense, not for limiting purposes.

[0089] Example 1. An example of an apparatus, comprising: at least one processor; and at least one memory, the at least one memory comprising computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the apparatus to perform at least the following items: determine a non-standardized data collection policy; based on the non-standardized data collection policy, receive a non-standardized data request; determine whether the non-standardized data request complies with the non-standardized data collection policy; provide the non-standardized data request to a user equipment (UE) device; receive data from the UE device in response to the non-standardized data request; and provide the data in a transparent container to an external server.

[0090] Example 2. The apparatus of Example 1, wherein the non-standardized data request based on the non-standardized data collection policy is received from the external server.

[0091] Example 3. An apparatus according to Example 1 or 2, wherein the data received from the UE device is received in a transparent container, wherein the data is not decodable by the apparatus.

[0092] Example 4. An apparatus according to any one of Examples 1 to 3, wherein the apparatus is further configured to provide the non-standardized data collection policy to the external server.

[0093] Example 5. An apparatus according to any one of Examples 1 to 4, wherein the non-standardized data collection policy includes: an indication of data content that is allowed to be transmitted from the UE device to the external server.

[0094] Example 6. An apparatus according to Example 5, wherein the content of data allowed to be transmitted is based on one or more of the following items: the type of data, configuration information, radio access network RAN ​​area, network coverage area, g NodeB gNB service area, location management function LMF service area, and the geographical area of ​​data collection.

[0095] Example 7. The apparatus of Example 6, wherein the data content that is allowed to be transferred is further based on one or more of: a server identifier or a device identifier.

[0096] Example 8. An apparatus according to any one of Examples 1 to 7, wherein the non-standardized data request for the UE device is provided in a transparent container.

[0097] Example 9. An apparatus according to any one of Examples 1 to 8, wherein the data includes location-related data, and wherein the external server uses the location-related data for artificial intelligence / machine learning model training.

[0098] Example 10. An apparatus according to any one of Examples 1 to 9, wherein the non-standardized data request includes: a metadata field that describes the data to be collected in response to the non-standardized data request.

[0099] Example 11. An apparatus according to Example 10, wherein the data responsive to the non-standardized data request includes: metadata in the metadata field, wherein the metadata field is not in the transparent container.

[0100] Example 12. An apparatus according to Example 11, wherein the metadata includes one or more of the following items: the type of measurement data, vendor or device information associated with the UE device, the geographic area of ​​data collection, the timestamp of data collection, session information of the collected data, quality information of the collected data, or the amount of data collected, or the number of collected data samples.

[0101] Example 13. An apparatus according to any one of Examples 1 to 12, wherein the non-standardized data collection strategy includes: a protocol in which the non-standardized data request should be sent using a signal, and an indication of a protocol required to carry the data collected in response to the non-standardized data request.

[0102] Example 14. An apparatus according to any one of Examples 1 to 13, wherein the non-standardized data request includes: a physical layer signaling requirement, wherein the physical layer signaling requirement includes: standardized configuration information of a signal associated with the non-standardized data request.

[0103] Example 15. The apparatus of Example 14, wherein the physical layer signaling requirements include one or more of the following: downlink positioning reference signal (DL PRS) bandwidth, the number of transmission and reception points (TRP), or quality of service (QoS).

[0104] Example 16. An apparatus according to any one of Examples 1 to 15, wherein the apparatus is further caused to perform the following items: providing a request to at least one of the following items to establish the signaling required for the non-standardized data request: a location management function LMF, or a g NodeB gNB.

[0105] Example 17. An apparatus according to Example 16, wherein the device is also caused to: receive a response from the LMF or at least one of the gNB associated with the actual setting of at least one of the LMF or the gNB.

[0106] Example 18. An apparatus according to any one of Examples 1 to 17, wherein the data in response to the non-standardized data request includes: non-standardized data sent via a standardized data protocol.

[0107] Example 19. The apparatus of Example 18, wherein the standardized data protocol comprises one or more of: Long Term Evolution (LTE) Positioning Protocol (LPP), or Radio Resource Control (RRC).

[0108] Example 20. An example of a computer program product, comprising at least one non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium having the computer executable program code instructions stored on the non-transitory computer-readable storage medium, the computer executable program code instructions including program code instructions, which are configured when executed to: determine a non-standardized data collection policy; receive a non-standardized data request based on the non-standardized data collection policy; determine whether the non-standardized data request complies with the non-standardized data collection policy; provide the non-standardized data request to a user equipment (UE) device; receive data from the UE device in response to the non-standardized data request; and provide the data in a transparent container to an external server.

[0109] Example 21. The computer program product of Example 20, wherein the non-standardized data request based on the non-standardized data collection policy is received from the external server.

[0110] Example 22. The computer program product of Example 20 or 21, wherein the data received from the UE device is received in a transparent container, wherein the data is not decodable by a network.

[0111] Example 23. The computer program product of any one of Examples 20 to 22, further comprising program code instructions for providing the non-standardized data collection policy to the external server.

[0112] Example 24. A computer program product according to any one of Examples 20 to 23, wherein the non-standardized data collection policy includes: an indication of data content that is allowed to be transmitted from the UE device to the external server.

[0113] Example 25. A computer program product according to Example 24, wherein the content of data allowed to be transmitted is based on one or more of the following items: the type of data, configuration information, radio access network RAN ​​area, network coverage area, gNodeB gNB service area, location management function LMF service area, and the geographical area where the data is collected.

[0114] Example 26. The computer program product of Example 25, wherein the data content that is allowed to be transferred is further based on one or more of: a server identifier or a device identifier.

[0115] Example 27. A computer program product according to any one of Examples 20 to 26, wherein the non-standardized data request for the UE device is provided in a transparent container.

[0116] Example 28. A computer program product according to any one of Examples 20 to 27, wherein the data includes location-related data, and wherein the external server uses the location-related data for artificial intelligence / machine learning model training.

[0117] Example 29. A computer program product according to any one of Examples 20 to 28, wherein the non-standardized data request includes: a metadata field that describes the data to be collected in response to the non-standardized data request.

[0118] Example 30. A computer program product according to Example 29, wherein the data responsive to the non-standardized data request includes: metadata in the metadata field, wherein the metadata field is not in the transparent container.

[0119] Example 31. A computer program product according to Example 30, wherein the metadata includes one or more of the following items: the type of measurement data, vendor or device information associated with the UE device, the geographic area of ​​data collection, the timestamp of data collection, session information of the collected data, quality information of the collected data, or the amount of data collected, or the number of collected data samples.

[0120] Example 32. A computer program product according to any one of Examples 20 to 31, wherein the non-standardized data request includes: physical layer signaling requirements, wherein the physical layer signaling requirements include: standardized configuration information of a signal associated with the non-standardized data request.

[0121] Example 33. A computer program product according to Example 32, wherein the physical layer signaling requirements include one or more of the following items: downlink positioning reference signal DL PRS bandwidth, the number of transmission and reception points TRP, or quality of service QoS.

[0122] Example 34. A computer program product according to any one of Examples 20 to 33, further comprising program code instructions for: providing a request to at least one of the following items to establish the signaling required for the non-standardized data request: a location management function LMF, or a g NodeB gNB.

[0123] Example 35. The computer program product of Example 34, further comprising program code instructions for receiving a response from at least one of the LMF or the gNB associated with an actual setting of at least one of the LMF or the gNB.

[0124] Example 36. A computer program product according to any one of Examples 20 to 35, wherein the data responsive to the non-standardized data request comprises: non-standardized data sent via a standardized data protocol.

[0125] Example 37. The computer program product of Example 36, wherein the standardized data protocol comprises one or more of: Long Term Evolution (LTE) Positioning Protocol (LPP) or Radio Resource Control (RRC).

[0126] Example 38. An example of a method, comprising: determining a non-standardized data collection policy; receiving a non-standardized data request based on the non-standardized data collection policy; determining whether the non-standardized data request complies with the non-standardized data collection policy; providing the non-standardized data request to a user equipment (UE) device; receiving data from the UE device in response to the non-standardized data request, wherein the data is in a transparent container; and providing the data in the transparent container to an external server.

[0127] Example 39. The method of Example 38, wherein the non-standardized data request based on the non-standardized data collection policy is received from the external server.

[0128] Example 40. The method of Example 38 or 39, wherein the data received from the UE device is received in a transparent container, wherein the data is not decodable by a network.

[0129] Example 41. The method according to any one of Examples 37 to 39 further includes: providing the non-standardized data collection policy to the external server.

[0130] Example 42. A method according to any one of Examples 38 to 41, wherein the non-standardized data collection policy includes: an indication of data content that is allowed to be transmitted from the UE device to the external server.

[0131] Example 43. A method according to Example 42, wherein the content of data allowed to be transmitted is based on one of the following items: the type of data, configuration information, radio access network RAN ​​area, network coverage area, g NodeB gNB service area, location management function LMF service area, and the geographical area of ​​data collection.

[0132] Example 44. The method of any one of Examples 38 to 43, wherein the non-standardized data request for the UE device is provided in a transparent container.

[0133] Example 45. A method according to any one of Examples 38 to 44, wherein the data includes location-related data, and wherein the external server uses the location-related data for artificial intelligence / machine learning model training.

[0134] Example 46. A method according to any one of Examples 38 to 45, wherein the non-standardized data request includes: a metadata field, which describes the data to be collected in response to the non-standardized data request.

[0135] Example 47. A method according to Example 46, wherein the data in response to the non-standardized data request includes: metadata in the metadata field, wherein the metadata field is not in the transparent container.

[0136] Example 48. A method according to Example 47, wherein the metadata includes one or more of the following items: the type of measurement data, the vendor or device information associated with the UE device, the geographic area of ​​data collection, the timestamp of data collection, the session information of the collected data, the quality information of the collected data, or the amount of data collected, or the number of collected data samples.

[0137] Example 49. A method according to any one of Examples 38 to 48, wherein the non-standardized data request includes: a physical layer signaling requirement, wherein the physical layer signaling requirement includes: standardized configuration information of a signal associated with the non-standardized data request.

[0138] Example 50. The method of Example 49, wherein the physical layer signaling requirements include one or more of the following: downlink positioning reference signal DL PRS bandwidth, the number of transmission and reception points TRP, or quality of service QoS.

[0139] Example 51. A method according to any one of Examples 38 to 50, wherein the device is also caused to perform the following items: providing a request to at least one of the following items to establish the signaling required for the non-standardized data request: location management function LMF, or g NodeB gNB.

[0140] Example 52. A method according to Example 51, wherein the device is also caused to perform the following items: receiving a response from the LMF or at least one of the gNB associated with the actual setting of at least one of the LMF or the gNB.

[0141] Example 53. A method according to any one of Examples 38 to 52, wherein the data in response to the non-standardized data request includes: non-standardized data sent via a standardized data protocol.

[0142] Example 54. The method of Example 53, wherein the standardized data protocol comprises one or more of: Long Term Evolution LTE Positioning Protocol LPP, or Radio Resource Control RRC.

[0143] Example 55. An example of an apparatus comprising: at least one processor; and at least one memory, the at least one memory comprising computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the apparatus to perform at least the following: receiving a non-standardized data request having a non-standardized data collection strategy; collecting measurements and non-standardized data according to the non-standardized data collection strategy; and transmitting the non-standardized data in a transparent container together with metadata according to the non-standardized data collection strategy.

[0144] Example 56. The apparatus of Example 55, wherein the apparatus is further caused to request a physical layer signaling requirement, wherein the physical layer signaling requirement comprises: standardized configuration information of a signal associated with the non-standardized data request.

[0145] Example 57. An apparatus according to Example 56, wherein the physical layer signaling requirements include one or more of the following items: downlink positioning reference signal DL PRS bandwidth, the number of transmission and reception points TRP, or quality of service QoS.

[0146] Example 58. An apparatus according to any one of Examples 55 to 57, wherein the apparatus is further caused to request approval for transmitting the non-standardized data in the transparent container together with the metadata field before sending the non-standardized data in the transparent container together with the metadata.

[0147] Example 59. An example of a computer program product, comprising at least one non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium having the computer executable program code instructions stored on the non-transitory computer-readable storage medium, the computer executable program code instructions including program code instructions, which are configured when executed to: receive a non-standardized data request with a non-standardized data collection strategy; collect measurement values ​​and non-standardized data according to the non-standardized data collection strategy; and transmit the non-standardized data in a transparent container together with metadata according to the non-standardized data collection strategy.

[0148] Example 60. The computer program product of Example 59, further comprising program code instructions for: requesting a physical layer signaling requirement, wherein the physical layer signaling requirement comprises: standardized configuration information for a signal associated with the non-standardized data request.

[0149] Example 61. A computer program product according to Example 60, wherein the physical layer signaling requirements include one or more of the following items: downlink positioning reference signal DL PRS bandwidth, the number of transmission and reception points TRP, or quality of service QoS.

[0150] Example 62. A computer program product according to any one of Examples 59 to 61, further comprising program code instructions for: requesting approval to transmit the non-standardized data in the transparent container together with the metadata fields before sending the non-standardized data in the transparent container together with the metadata.

[0151] Example 63. An example of a method, comprising: receiving a non-standardized data request having a non-standardized data collection policy; collecting measurements and non-standardized data according to the non-standardized data collection policy; and transmitting the non-standardized data in a transparent container together with metadata according to the non-standardized data collection policy.

[0152] Example 64. The method of Example 63 further includes requesting a physical layer signaling requirement, wherein the physical layer signaling requirement includes: standardized configuration information of a signal associated with the non-standardized data request.

[0153] Example 65. A method according to Example 64, wherein the physical layer signaling requirements include one or more of the following items: downlink positioning reference signal DL PRS bandwidth, the number of transmission and reception points TRP, or quality of service QoS.

[0154] Example 66. The method of any one of Examples 63 to 65, further comprising requesting approval to transmit the non-standardized data in the transparent container together with the metadata field before sending the non-standardized data in the transparent container together with the metadata.

Claims

1. A device for communication, comprising: at least one processor; as well as at least one memory, the at least one memory comprising computer program code, The at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to at least perform the following: receiving non-standardized data requests with non-standardized data collection policies; collecting measurements and non-standardized data according to the non-standardized data collection strategy; as well as According to the non-standardized data collection strategy, the non-standardized data in the transparent container is transmitted together with the metadata.

2. The apparatus of claim 1 , further causing the apparatus to request a physical layer signaling requirement, wherein the physical layer signaling requirement comprises: Standardized configuration information of a signal associated with the non-standardized data request.

3. The apparatus according to claim 2, wherein the physical layer signaling requirements include one or more of the following items: downlink positioning reference signal DL PRS bandwidth, the number of transmission and reception points TRP, or quality of service QoS.

4. The apparatus according to any one of claims 1 to 3, wherein the apparatus is further caused to request approval to transmit the non-standardized data together with the metadata field before sending the non-standardized data in the transparent container together with the metadata.

5. A method for communication, comprising: receiving non-standardized data requests with non-standardized data collection policies; collecting measurements and non-standardized data according to the non-standardized data collection strategy; as well as According to the non-standardized data collection strategy, the non-standardized data is transmitted together with the metadata into a transparent container.

6. The method according to claim 5, further comprising requesting a physical layer signaling requirement, wherein the physical layer signaling requirement comprises: Standardized configuration information of a signal associated with the non-standardized data request.

7. The method of claim 6, wherein the physical layer signaling requirements include one or more of the following: downlink positioning reference signal (DL PRS) bandwidth, the number of transmission and reception points (TRP), or quality of service (QoS).

8. The method according to any one of claims 5 to 7, further comprising requesting approval to transmit the non-standardized data with metadata fields before sending the non-standardized data in the transparent container with the metadata.

9. An apparatus for communication, comprising: at least one processor; as well as at least one memory, the at least one memory comprising computer program code, The at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to at least perform the following: Identify non-standardized data collection strategies; Based on the non-standardized data collection strategy, receiving a non-standardized data request; determining whether the non-standardized data request complies with the non-standardized data collection policy; Providing the non-standardized data request to a user equipment UE device; Receiving data from the UE device in response to the non-standardized data request; as well as The data in the transparent container is provided to an external server.

10. A method for communication, comprising: Identify non-standardized data collection strategies; Based on the non-standardized data collection strategy, receiving a non-standardized data request; determining whether the non-standardized data request complies with the non-standardized data collection policy; Providing the non-standardized data request to a user equipment UE device; In response to the non-standardized data request, receiving data from the UE device, wherein the data is in a transparent container; as well as The data in the transparent container is provided to an external server.

Images