Unified data collection architecture for various radio access technologies

Abstract

Various aspects of the present disclosure relate to a network entity comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network entity to: receive a request for data collection associated with a network topic; identify one or more parameters for the data collection associated with the network topic; identify a server for publishing collected data associated with the network topic; and transmit the collected data associated with the network topic to the server for publishing via a network interface.

Description

[0001] UNIFIED DATA COLLECTION ARCHITECTURE FOR VARIOUS RADIO ACCESS TECHNOLOGIES

[0002] TECHNICAL FIELD

[0003] [1] The present disclosure relates to wireless communications, and more specifically to a data collection architecture.

[0004] BACKGROUND

[0005] [2] A wireless communications system may include one or multiple network communication devices, which may be otherwise known as network equipment (NE), supporting wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).

[0006] SUMMARY

[0007] [3] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be constmed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0008] [4] A network entity for wireless communication is described. The network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the network entity may comprise: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network entity to: receive a request for data collection associated with a network topic; identify one or more parameters for the data collection associated with the network topic ; identify a server for publishing collected data associated with the network topic; and transmit the collected data associated with the network topic to the server for publishing via a network interface.

[0009] [5] A processor for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may comprise at least one controller coupled with at least one memory and configured to cause the processor to receive a request for data collection associated with a network topic; identify one or more parameters for the data collection associated with the network topic; identify a server for publishing collected data associated with the network topic; and transmit the collected data associated with the network topic to the server for publishing via a network interface.

[0010] [6] A method performed or performable by a network entity is described. The method may comprise receiving a request for data collection associated with a network topic; identifying one or more parameters for the data collection associated with the network topic; identifying a server for publishing collected data associated with the network topic; and transmitting the collected data associated with the network topic to the server for publishing via a network interface.

[0011] [7] In some implementations of the network entity, processor, and method described herein, the request may indicate an identifier of the network topic, or an identifier of the server, or both. [8] In some implementations of the network entity, processor, and method described herein, the identifier of the server may be at least one of a network function identifier or a fully qualified domain name (FQDN).

[0012] [9] Some implementations of the network entity, processor, and method described herein, the network entity, processor, and method may be capable of, operable, or configured to communicate with the server via a network interface using at least one of a service-based interface protocol or a data-based interface protocol.

[0013]

[0010] In some implementations of the network entity, processor, and method described herein, the collected data associated with the network topic may be included in a container including an identifier that associates the collected data to the network topic.

[0014]

[0011] In some implementations of the network entity, processor, and method described herein, the network entity may comprise at least one of a network function of a core network, a Radio Access Network (RAN) node (e.g., a base station), or a UE.

[0015]

[0012] In some implementations of the network entity, processor, and method described herein, the network topic may comprise one or more of: throughput, packet loss rate, downlink packet delay, uplink packet delay, radio resource utilization, mobility events, protocol data unit (PDU) session-related events, a number of registered UEs, a number of established PDU sessions, a number of registered UEs for a network slice, or a number of established PDU sessions for the network slice.

[0016]

[0013] A network entity for wireless communication is described. The network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the network entity may comprise: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network entity to : receive a request for data associated with a network topic from a data consumer via a network interface, wherein the network topic is associated with one or more data producing network entities;; and configure the server for data collection and reporting associated with the network topic, wherein the server is configured to collect the data via a same network interface for each of the one or more data producing network entities associated with the network topic.

[0017]

[0014] A processor for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may comprise at least one controller coupled with at least one memory and configured to cause the processor to receive a request for data associated with a network topic from a data consumer via a network interface, wherein the network topic is associated with one or more data producing network entities; and configure a server for data collection and reporting associated with the network topic, wherein the server is configured to collect the data via a same network interface for each of the one or more data producing network entities associated with the network topic.

[0018]

[0015] A method performed or performable by a network entity is described. The method may comprise receiving a request for data associated with a network topic from a data consumer via a network interface, wherein the network topic is associated with one or more data producing network entities; identifying a server with available data associated with the network topic; and configuring the server for data collection and reporting associated with the network topic, wherein the server is configured to collect the data via a same network interface for each of the one or more data producing network entities associated with the network topic.

[0019]

[0016] In some implementations of the network entity, processor, and method described herein, the network interface may comprise at least one of a service-based interface or a data-based interface. The network interface may be a messaging interface.

[0020]

[0017] In some implementations of the network entity, processor, and method described herein, the at least one processor may be configured to cause the network equipment to receive the request from at least one of a Network Function supporting data collection or an Operations and Maintenance node (OAM).

[0021]

[0018] In some implementations of the network entity, processor, and method described herein, the one or more data producing network entities includes one or more of an Application Function (AF), a Radio Access Network (RAN) node, or a User Equipment (UE).

[0019] In some implementations of the network entity, processor, and method described herein, the at least one processor may be further configured to cause the network equipment to: determine if the data consumer has authorization to access the network topic, wherein the server is identified in response to the determination that the data consumer has authorization to access the network topic.

[0022]

[0020] In some implementations of the network entity, processor, and method described herein, the request may include a data collection profile including at least one of: an event identifier (ID); a topic ID; a type of data producing network entity; a type of data consumer; a service for requesting data; vendor information; an application function service identifier; validity information; and an authorization access token.

[0023]

[0021] In some implementations of the network entity, processor, and method described herein, wherein the request indicates at least one of: store or forward information; a periodicity for reporting the data; anonymization of data information; whether the data is to be transmitted to an external server; whether the data is to be stored locally; or whether the data is to be transmitted to an external address.

[0024]

[0022] In some implementations of the network entity, processor, and method described herein, the network equipment may comprise a data collection network function (DCNF).

[0025]

[0023] In some implementations of the network entity, processor, and method described herein, the network equipment may comprise the server.

[0026]

[0024] In some implementations of the network entity, processor, and method described herein, the server may be a DCNF server.

[0027]

[0025] In some implementations of the network entity, processor, and method described herein the network topic may comprise one or more of: throughput, packet loss rate, downlink packet delay, uplink packet delay, radio resource utilization, mobility events, protocol data unit (PDU) session-related events, a number of registered UEs, a number of established PDU sessions, a number of registered UEs for a network slice, or a number of established PDU sessions for the network slice.

[0028] BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0029]

[0027] Figure 2 is a flow diagram showing a method for data collection.

[0030]

[0028] Figure 3 illustrates an architecture for data collection for artificial intelligence / machine learning related services using a network data analytics function.

[0031]

[0029] Figure 4 illustrates an architecture for data collection for artificial intelligence / machine learning related services using a data collection coordination and delivery function control plane.

[0032]

[0030] Figure 5 illustrates an architecture for data collection for artificial intelligence / machine learning related services using a data collection coordination and delivery function messaging framework.

[0033]

[0031] Figure 6 illustrates an architecture for data collection for positioning.

[0034]

[0032] Figure 7 illustrates a framework for data collection from a User Equipment.

[0035]

[0033] Figure 8 is a flow diagram showing a method of acquiring pull service experience information from a UE.

[0036]

[0034] Figure 9 illustrates an application data analytics enablement internal functional architecture.

[0037]

[0035] Figure 10 is a flow diagram showing a method for data collection over an Application Layer Data Collection and Coordination Function.

[0038]

[0036] Figure 11 illustrates an architecture for a publish / subscribe communication model.

[0039]

[0037] Figure 12 illustrates a data plane architecture for a 6G network.

[0040]

[0038] Figure 13 illustrates a data bus based unified data collection architecture.

[0041]

[0039] Figure 14 illustrates an architecture for data collection via data-based protocols.

[0042]

[0040] Figure 15 illustrates an architecture for data collection which allows for configuration via a control plane.

[0041] Figure 16 illustrates an architecture for data collection for providing data reporting to third party servers.

[0043]

[0042] Figure 17 illustrates an architecture for configuring data producers via an Operations and Maintenance function.

[0044]

[0043] Figure 18 illustrates an architecture for configuring data producers via an Operations and Maintenance function using a messaging framework.

[0045]

[0044] Figure 19 is a flow diagram illustrating a procedure for enabling support of dynamic Quality of Service for applications with dynamic traffic characteristics.

[0046]

[0045] Figure 20 illustrates an example of a UE in accordance with aspects of the present disclosure.

[0047]

[0046] Figure 21 illustrates an example of a processor in accordance with aspects of the present disclosure.

[0048]

[0047] Figure 22 illustrates an example of a NE in accordance with aspects of the present disclosure.

[0049]

[0048] Figure 23 illustrates a flowchart of a method performed by a UE in accordance with aspects of the present disclosure.

[0050]

[0049] Figure 24 illustrates a flowchart of a method performed by a NE in accordance with aspects of the present disclosure.

[0051] DETAILED DESCRIPTION

[0052]

[0050] Some wireless communication systems, such as 5G systems (5GS) support a data collection framework (also referred to as data collection architecture), which includes (e.g., involved) various functions and procedures for supporting data collection.

[0053] Specifically, the data collection framework supported by these wireless communication systems was established to support specific requirements, such as collecting positioning data or data for machine learning (ML) model training. Thereby, it was not established for other purposes, such as retrieving general types of data from general entities, such as an Application Function, a Radio Access Network, or a User Equipment, within these wireless communication systems.

[0054]

[0051] The present disclosure introduces a unified data collection framework (also referred to as a unified data collection architecture) to address the above shortcomings. The unified data collection framework defines a common interface (e.g., data bus) for Data Consumers to request data and Data Producers to provide (e.g., transmit, report) the requested data. Additionally, the unified data collection framework is based on a Publish / Subscribe type of methodology in which Data Producers publish data to a repository and Data Consumers retrieve data directly from the repository. The present disclosure provides technical benefits over known methods in that it allows a single DCNF to provide data collection capability, thus improving the efficiency and reducing the complexity of the system. The use of the same network interface in requesting and collecting data provides a more efficient data collection method. Requesting and collecting data based on a network topic allows for more targeted and relevant data collection. Aspects of the present disclosure are described in the context of a wireless communications system.

[0055]

[0052] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system

[0056] 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LIE- A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0057]

[0053] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0058]

[0054] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0059]

[0055] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of- Things (loT) device, an Intemet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0060]

[0056] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0061]

[0057] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0062]

[0058] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0063]

[0059] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0064]

[0060] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5 G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0065]

[0061] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., / r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., / r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0066]

[0062] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0067]

[0063] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., / r=0, jU=l , / r=2, jU=3, / r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0068]

[0064] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5

[0069] (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0070]

[0065] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / r=3), which includes 120 kHz subcarrier spacing.

[0071]

[0066] Comparative examples of data collection methods are described.

[0072]

[0067] According to one comparative example, an Operations and Maintenance (0AM) node supports data collection from UEs regarding radio conditions using Minimization of Drive Tests (MDT) as defined in 3GPP TS 32.422, 3GPP TS 37.320. Data that can be collected include radio measurements, performance metrics (PM), and key performance indicators (KPI)s. A procedure to collect data from a UE using MDT is shown in Figure 2. Figure 2 is a flow diagram showing a communication flow between a management system 201, an AMF 203, a gNB 205, a UE 207, and a TCE(Trace Control Entity) 209. An initial context setup request is sent from the AMF 203 to the gNB 205, including a management based MDT PLMN list. The gNB 205 stores within a UE context that management based MDT is allowed. The management system 201 activates MDT in the gNB 205. The gNB 205 starts a trace session and / or stores MDT parameters. The gNB 205 selects a UE 207 based on the received MDT parameters. The gNB 205 then activates MDT in the UE 207. The UE 207 provides MDT reporting to the gNB 205 via radio resource control (RRC) protocol. The gNB 205 saves the UE 207 measurements to MDT records. An anonymization level is then determined at the gNB 205, and the gnB determines whether or not data is to be sent. A cell traffic trace is then sent to the AMF 203, and the AMF sends a tracking area code (TAC), trace reference (TR), and trace recording session reference (TRSR) to the TCE 209, and the gNB 205 sends MDT reporting to the TCE 209. The TCE 209 then combines the MDT records with the TAC based on the TR and the TRSR.

[0068] OAM can support MDT data collection using trace jobs as well as the collection of PMs and KPIs via the performance metric production jobs defined in TS 28.622.

[0073]

[0069] The OAM defines three management service (MnS) components as per TS 28.533 related to data collection: i) type A that defines CRUD operations (create, read, update and delete) related to a data collection, (ii) type B that related to the Network Resource Model (NRM) that specifies the interface used to retrieve data, and (iii) type C that focuses on the data reporting, which can be in a form of a file, data streaming, or a notification.

[0074]

[0070] When using these data collection capabilities, the consumer needs to have knowledge of the exact data that is to be collected and from which data source. However, this information may not always be available to the consumer. To resolve this issue, a Management Data Collection Control and Discovery (MDACOL) framework is introduced to create an application programming interface (API) that allows the consumer to request data providing certain filtering information without necessarily knowing the source of the desired data or the specific type of data, i.e., if the data is MDT, performance measurement data, or a KPI. Instead, the MDACOL framework decides based on the consumer data requirements.

[0075]

[0071] Figure 3 shows an architecture for data collection for artificial intelligence / machine learning (AI / ML) according to a comparative example. The architecture comprises NFs as data producers 301 including a UE 315, an application function 313, a 5 G network function 317, an administrative data research facility (ADRF) 319, and an OAM 321. The architecture further comprises NFs as analytics consumers. These include an AF 311, a 5GNF 307, and an OAM 309. Further included a two Network Data Analytics Functions (NWDAF)s 303, and a Data Collection Coordination Function (DCCF) 305. The NWDAF 303s or the DCCF 305s may retrieve data from data producers, such as the network function (NF) 317, OAM 321, application function (AF) 313, or a UE 315, via triggering of a relevant event exposure service based interface request. This procedure may for example be performed as set out in 3GPP TS 23.288.

[0076]

[0072] The DCCF 305 is defined as a means to simplify data collection and avoid the NWDAF 303 managing multiple SBI requests to retrieve data as well as having several subscriptions from different NFs for the same data of a specific NF. Two variants have been defined: (1) using control plane procedures to retrieve data shown in Figure 4; and, (2) using a messaging framework (similar to the pubsub type of data collections) as shown in Figure 5.

[0077]

[0073] Figure 4 depicts a control plane architecture according to a comparative example. In this architecture, a consumer NF 401 requests data to be collected by the DCCF 405 using a specific Ndccf data collection service. The consumer NF 401 requests data by including one or more "Event IDs", where the Event ID denotes the type of data (e.g. UE mobility data) and optionally a type of NF where data is requested. The DCCF 405 determines a Data Source NF 407 from which to retrieve the data and triggers a specific NF service supported by the Data Source NF 407 to retrieve the data. The Data Source NF 407 provides data using the specific Data Source NF 405 service. Another option is for the Data Consumer NF 401 in the request to the DCCF 405 to include multiple notification endpoints (e.g. also include data provided to a Data Repository Function (ADRF) / Network Repository Function (NRF) 403). The Data Consumer NF 405 may also include formatting and / or processing instructions which provide information on when to provide data to the consumer NF 401 (for example as described in clause 5A.4 of 3GPP TS 23.288).

[0078]

[0074] Figure 5 depicts a data collection architecture using a messaging framework according to a comparative example. In the messaging framework alternative as shown in Figure 5, a consumer NF 401 requests data to be collected by the DCCF 405 using a specific Ndccf data collection service, and the DCCF 405 determines the Data Source NF 407 to retrieve data and triggers a specific NF service supported by the Data Source NF 407 to retrieve the data. The DCCF 405 configures a messaging framework 501 via a messaging framework adapter function (MFAF) to forward data retrieved from a data source NF 407 to the correct consumer NF 401. The Data Source NF 407 provides data using the specific messaging framework protocol. The protocol used is implementation specific and not defined in 3 GPP.

[0079]

[0075] The NWDAF 303 and DCCF 305 may collect data from NFs, AFs (and UEs) for the purpose of using the data for Machine Learning Model Training and Inference. (Data collection from a RAN is not supported). The NWDAF 303 and DCCF 305 are required to support multiple SBI services, as shown in Figure 3, in order to retrieve data from each NF type. The data that can be collected may for example be as defined in 3 GPP TS 23.288.

[0080]

[0076] Figure 6 depicts a data collection architecture for positioning services, such as using a location management function (LMF) 607, according to a comparative example. As part of the location services (LCS) architecture defined in 3GPP TS 23.271, the LMF 607 collects positioning related data from a UE 601 and a RAN 603. The LMF 607 retrieves the data from the UE 601 and the RAN 603 via the AMF 605, using LTE positioning protocol (LPP) and NR positioning protocol (NRPP) respectively. The data is provided via the control plane (via a non-access stratum (NAS) for the UE 601 and a N2 reference point for the RAN 603). It is also possible for the UE 601 to provide data using the LPP protocol via the user plane to the LMF 607 by the UE establishing an IP connection directly with the LMF.

[0081]

[0077] Figure 7 depicts another data collection architecture according to a comparative example. The comparative example in Figure 7 shows data from a UE 701 for media- related parameters using a data collection application function (DCAF) 707.

[0082]

[0078] This architecture was specifically designed to collect data from UEs 701 for media-related parameters and is also discussed as part of Release 19 work in 3 GPP for collecting data from UEs for training AI / ML related models for improving radio performance. The current procedures allow data collection and data collection management operations (i.e., CRUD) for applications running in the UE 703. The data collection request from a NWDAF 711 or another NF (i.e., predominantly Application Service Provider (ASP) Event Consumers AFs, or alternatively Data Consumers AFs) may trigger a Data Collection AF (DCAF) 707 to configure a data collection session accordingly and collect data from the UE Application 703. The procedure for data collection from UE applications may be performed as set out in 3GPP TS 26.531 and corresponding protocols (i.e., HTTP) and formats are defined in 3GPP TS 26.532. The framework supports direct data collection from the UE 701 by means of a Data Collection Client (DCC) 705 wherein the DCC 705 in the UE 701 collects data from one or more Applications 703 running in the UE 701 and reports the data to the DCAF 707 which then forwards the data to the consumer. A second approach is indirect data collection where the data collection client is located in the cloud (i.e., as an Indirect Data Collection Client (IDCC)) 721 and collects data indirectly, from the application in the cloud. The DCAF 707 may be deployed inside a trusted domain, such as the NWDAF, or outside a trusted domain such as an Event consumer AF 723. It is responsible for managing the provisioning state for data collection and reporting. When its provisioning state changes, the DCAF 707 updates the set of available NF profile(s) in an NRF 709. The DCAF 707 may be deployed outside of the trusted domain, in which case the services it exposes to API invokers are mediated by an NEF 713. Depending on provisioning information provided by a provisioning AF 719 of an application service provider 717, the DCAF may provide a data collection and reporting configuration to an application server (AS) 715.

[0083]

[0079] Figure 8 is a flow chart showing a method of providing data collection in an application data analytics enablement (ADAE) layer according to a comparative example.

[0084]

[0080] Data / analytics collection is provided for an application server and session performance analytics (as in clause 8.2 of 3GPP TS 23.436). In this capability, the analytics request from an external application is translated to a data collection event based on the analytics ID and, based on the Data Producers’ profiles, an ADAE service determines the Data Producers. Such Data Producers can be at the DN side (servers, enabler servers, platforms) and / or at the UE side (UE apps) and / or an Application layer - Analytics and Data Repository Function (A-ADRF) which provides historical data / stats. Such data can be about the round trip time (RTT), average / peak throughput, jitter, QoE measurements (MOS, stalling events, stalling ratios, etc), QoS profile load, vertical application layer (VAL) server load, etc. The selection of the data producers can be based on criteria provided by the consumer and the analytics task. In this solution, an ADAE client also determines the data producers using the analytics event ID, target data producer profile and optional preconfigured policies.

[0085]

[0081] For the above application performance analytics, for UE application data there can be different ways specified to acquire this data. For example, when an Application server (such as a VAL server) is not available to provide analytics data due to overload or any other reasons or the application server is not providing the required quality of service experience at the UE side, the ADAE server may need to rely on alternate information sources like the application clients (like VAL clients) that provide the visibility on an application service status. The ADAE server can use this information from the clients alone, for the predictions and share with the consumer of the analytics. In this solution, if a Direct Data Connection Client DDCC client is available in the UE, the ADAE server uses data collection and reporting mechanisms as defined in 3GPP TS 26.531, where the ADAE client acts as a UE application and ADAE server acts as an AF from an Application service provider. The indirect reporting procedure (between the ADAE client and the ADAE server over an ADAE-UU interface) may be used when a Direct Data Collection Client is not available in the UE. In Rel-18, such indirect reporting procedure is implementation specific.

[0086]

[0082] There are different ways for the ADAE client to send service experience reports to the ADAE server. The ADAE server, upon receiving the service experience information from the UE side entities, can use it for predictions of application performance analytics.

[0087]

[0083] One such example is for Push service experience information. In this example, the ADAE client determines service experience information based on information received from the VAL client. The service experience information includes application specific performance measurements like end-to-end response time, connection bandwidth, request rate, server availability time, etc. On request from the VAL client, or any other trigger conditions, the ADAE client sends the service experience report about a VAL server to the ADAE server using the mechanism defined in 3 GPP TS 26.531.

[0088]

[0084] For direct reporting, if a data reporting session is not available, the ADAE client creates a data reporting session as specified in clause 5.4 of 3GPP TS 26.531. Once a data reporting session is available, the ADAE client (acting as a UE client) sends reports to the ADAE server using a direct reporting method as specified in clause 5.5 of 3GPP TS 26.531.

[0089]

[0085] The ADAE server may take further actions based on the analysis of the report as shared by the ADAE client. A service experience information from certain UEs can trigger the ADAE server to fetch further service experience information from other UEs, and use the service experience information report from other UEs to determine / predict analytics.

[0090] If most of the UE side entities report a similar service experience, then it could be the application server problem is global.

[0091] If only some UEs report a bad service experience, the problem could be localized among a group of UEs. If the bad service experience from only one UE, the problem is localized to the one UE.

[0092]

[0086] Another such example is data collection for Pull service experience information. In this example, the procedure can be initiated by the ADAE server upon receiving a service experience request from an ADAE client, to fetch service experience information from other ADAE clients, or upon receiving a VAL server performance analytics request from an application service provider (application server) or any other event that requires the ADAE server to determine the service experience data. The following steps are performed:

[0093] 1. The ADAE server sends a Pull service experience request to the ADAE client. The request contains an identity of the specific VAL server and VAL service ID, for which the service experience report is required, as mentioned in Table 8.9.3.3-1 of TS 23.436.

[0094] 2. Upon receiving the Pull service experience request from the ADAE server, the ADAE client may request user consent to send the report if the user consent is not available already.

[0095] 3. The ADAE client sends the Pull service experience response to the ADAE server. The ADAE client instructs the Direct Data Collection Client to prioritise immediate delivery of a UE data report to the Data Collection AF as specified in clause 5.5 of 3GPP TS 26.531. The service experience contains parameters as specified in Table 8.9.3.4-1 of TS 23.436.

[0096] 4. The ADAE server uses the service experience report for derivation of VAL server performance analytics.

[0097]

[0087] Another such example is providing service experience information based on triggers. In this example, The ADAE server configures triggers for the ADAE client to send the service experience report using the mechanism defined in clause 5.4 of 3GPP TS 26.531. The procedure can be initiated by the ADAE server upon receiving a VAL server performance analytics request from the application service provider (application server). The information elements as defined in clause 8.9.3.5 of TS 23.436 are used by the ADAE server to send the request and those defined in clause 8.9.3.6 are used by the ADAE client to send the response.

[0088] Another example of a data collection process is a data collection coordination in an enablement layer.

[0098]

[0089] In an ADAE framework, A-DCCF and A-ADRF can be defined as functionalities within the internal ADAE architecture and can offer the following functionalities:

[0099] The Application layer - Data Collection and Coordination Function (A- DCCF) coordinates the collection and distribution of data requested by the consumer (ADAE server). Data Collection Coordination is supported by an A-DCCF. The ADAE server can send requests for data to the A-DCCF rather than directly to the Data Sources. The A-DCCF may also perform data processing / abstraction and data preparation based on the VAL server requirements.

[0100] The Application layer - Analytics and Data Repository Function (A-ADRF) stores historical data and / or analytics, i.e., data and / or analytics related to a past time period that has been obtained by the consumer (e.g. the ADAE server). After the consumer obtains data and / or analytics, a consumer may store historical data and / or analytics in an A-ADRF. Whether the consumer directly contacts the A-ADRF or goes via the A-DCCF is based on a provided configuration.

[0101]

[0090] Figure 9 illustrates a generic functional model for the ADAE when re-using the 3 GPP network data analytics model according to a comparative example. In this model, an A-DCCF 905 is used to fetch data or put data into an application-level entity (e.g. A-ADRF 901, or a Data Source 907). The A-DCCF 905 coordinates the collection and distribution of data requested by an ADAE server 903 (over ADCCF-1, ADAE-X). The ADAE server 903 can also directly interact with the Data Sources 907 via ADAE-Y.

[0102]

[0091] Also, the A-ADRF 901 can be used to store historical data and / or analytics, i.e., data and / or analytics related to a past time period that has been obtained by the ADAE server 903 (via AADRF-1) or other NFs / NWDAF. The ADAE server 903 can also fetch historical data from the A-ADRF 901. Whether the ADAE server 903 directly contacts the A-ADRF 901 or goes via the A-DCCF 905 is based on configuration.

[0103]

[0092] The Data Sources 907 can be 5GS data sources (5GC, 0AM) or enablement layer data sources (Service Enabler Layer Architecture (SEAL), Edge Enablement Layer (EEL)) or external data sources at the DN side (VAL server 909 / EAS) and VAL UEs. The A-DCCF 905 and the A-ADRF 901 can be used only for interacting with certain data sources 907 (e.g., 5GC, 0AM) based on the provided configuration, and can be hidden from the VAL layer.

[0104]

[0093] In Rel-19 there are new procedures in 8.12 covering both subscribe-notify models and request-response models for supporting data collection at an A-DCCF.

[0105]

[0094] Figure 10 depicts a procedure for a subscribe-notify model. This procedure may be performed as specified in 23.436 clause 8.12.2.1. The procedure includes the following steps:

[0106] 1. The consumer (ADAE server) 1001 sends a data collection subscription request to the A-DCCF 1003 for collecting data / analytics. The request message includes an identifier of the consumer (ADAE server ID), a Data Collection Event ID, and Data Collection Requirements. The request message may include the identifier of a Data Producer 1005, an Analytics ID, a target data producer profile criteria, process requirements, an Area of Interest, a Time validity, storage requirements, and notification endpoints. The consumer opts to proceed via A-DCCF based on an internal configuration.

[0107] 2. If the data producer 1005 is not identified by the consumer, the A-DCCF 1003 determines a data procedure that can provide data / analytics. If the consumer 1001 requested storage of data / analytics in an A-ADRF but the A-ADRF ID is not provided by the consumer 1001, or the collected data / analytics is to be stored in an A-ADRF according to configuration on the A-DCCF 1003 , the A-DCCF 1003 selects an A-ADRF to store the collected data / analytics.

[0108] 3. The A-DCCF 1003 determines whether the data / analytics requested in step 1 are already being collected. If the requested data / analytics are already being collected by a consumer 1001, the A-DCCF 1003 adds the new consumer 1001 to the list of consumers that are subscribed for these data / analytics.

[0109] 4. If the data / analytics subscribed in step 1 is not being collected by the A- DCCF 1003, the A-DCCF 1003 subscribes to the data producer 1005 for data / analytics. If the data / analytics subscribed in step 1 partially matches the data / analytics that is already being collected by the A-DCCF 1003, a modification of this subscription to the data producer 1005 would satisfy both the existing data / analytics subscriptions as well as the newly requested data / analytics, the A-DCCF 1003 requests an update of the previous subscription to the data producer 1005. The A-DCCF 1003 adds the consumer 1001 to the list of consumers that are subscribed for these data / analytics.

[0110] 5. Upon receiving the data / analytics subscription request from the A-DCCF 1003, the data producer 1005 determines whether the required data / analytics can be provided and sends data / analytics subscription response to the A-DCCF 1003.

[0111] 6. The A-DCCF 1003 sends a data / analytics subscription response to the consumer 1001.

[0112] 7. When the required data / analytics are available, the data producer 1005 notifies the data / analytics to the A-DCCF 1003.

[0113] 8. The A-DCCF 1003 notifies the data / analytics to all notification endpoints indicated in step 1. Data / analytics sent to notification endpoints may be processed by the A- DCCF (1003) upon to the request in step 1. The A-DCCF (1003) may store the data / analytics in the A-ADRF if requested by the consumer or if required by A-DCCF (1003 Configuration.

[0114]

[0095] Figure 11 depicts a data collection architecture for a data collection method that utilises Publish / Subscribe (PubSub) models, according to a comparative example.. Pubsub servers collect information from servers that publish data (1103, 1105) and provide the data to servers that subscribe to this information (1107, 1109) via a PubSub data storage (1101).

[0115]

[0096] In such a pubsub communication model, publishers provide data to a data collection server corresponding to a Topic. Servers that are interested to this Topic subscribe from the data collection server to retrieve data corresponding to this topic.

[0116]

[0097] There are a number of shortcomings of existent data collection frameworks.

[0117]

[0098] Each of the different frameworks for data collection described in section above has disadvantages. In general, in 5GS a data collection framework is designed to support specific requirements (e.g. collecting positioning data or collecting specific data for ML model training) and is not designed as a means to retrieve any type of data from any entity in the 5G system.

[0118]

[0099] Specific limitations of each of the data collection frameworks described in 2.1 are as follows:

[0100] OAM framework:

[0119] -0AM measurements concentrate of the management aspects considering

[0120] MDT data, PMs and KPIs (as per 28.552 and 28.554)

[0121] -OAM measurements are usually not real time and averaged over time

[0122] NWDAF framework:

[0123] -The granularity of reporting data is per Event ID. Event IDs are network based identifiers and cannot be used to report radio specific data

[0124] -NWDAF or DCCF is required to support multiple service based interface protocol to retrieve data from each NF type

[0125] -Data collection from a RAN or a UE is not defined

[0126] LCS framework:

[0127] -Designed to only retrieve radio-related positioning data from UE and RAN nodes

[0128] DCAF framework:

[0129] -Designed to retrieve only application-related data from a UE. (using an application layer to send UE modem related information).

[0130]

[0101] It is an object of the present application to address the following issues:

[0131] -To define a data collection framework that can be re-used for multiple purposes.

[0132] -To define a data collection framework that can be easily extended for new data collection use cases.

[0133] -To provide unified data collection from any entity in the 6G system including core functions, OAM, RAN nodes and potentially UEs.

[0134] -To reduce the number of NFs required to route and coordinate data collection from a data source to a data consumer.

[0135]

[0102] Figure 12 illustrates an example of a data plane architecture in accordance with aspects of the present disclosure.

[0136]

[0103] Figure 12 illustrates a Data Plane architecture according to embodiments of the present disclosure. The present disclosure provides a “Data Plane” architecture (supporting configuration, data reporting and data collection) offering a unified way of configuring “Data Producers” to collect and report data, as well as a unified way of delivering data to a “Data Consumer”. Data Producers or Data Consumers may be a RAN node, a UE, any Network Function in the core network or any Application Function (either third party of part of the operator realm in the core), or OAM. The architecture may include an LMF 1201, AF 1203, PCF 1205, UDR 1207, NRF 1209, RAN 1211, 6GNF 1213, NWDAF 1215, DCNF 1217, AMF 1219, SMF 1221, NEF 1223, OAM 1225, UPF 1227, and a UE 1229.

[0137]

[0104] According to a method of the present disclosure, all functions in the core and radio plane, and UEs, are able to support one common method of configuring, requesting and delivering data between Data Producers (the entities that collect and provide the data) and Data Consumers (the entities that require the data). The mechanism to collect and retrieve data is based on the principle of a publish / subscribe type of data architecture, where a Data Producer publishes data as a Topic and a Data Consumer requests a specific Topic in order to retrieve specific data.

[0138]

[0105] Figure 13 shows a unified data bus architecture according to embodiments of the present disclosure. According to embodiments of the present disclosure, provided is a common method in the 6G network for a Data Consumer to request and receive data from data Producers, and a common method for configuring Data Producers to Publish Data by introducing the unified “data bus” architecture for data collection. In Figure 13, a node in the network, a Data Collection Network Function (DNCF) 1301, receives and stores data (network data) from one or more Data Producers 1313, 1315, 1317 and provides the data to one or more Data Consumers 1309. According to some embodiments, this may be upon authorization of the Data Consumer 1309 to access the data.

[0139]

[0106] According to an embodiment, the existing Data Collection Coordination Function defined in 3GPP TS 23.288 can be enhanced to support a unified architecture for data collection.

[0140]

[0107] The Data Collection Network Function 1301 is composed of different logical functions with the following responsibilities as shown in Figure 13:

[0141] Controller 1305: Responsible for receiving data collection requests from Data Consumers and providing configuration information to Data Producers. Server 1303: Responsible for Data Collection from multiple Data Producers and Data transfer to Data Consumers.

[0142] Data Repository Register 1307: Contains information of Data Collected and Data types that can be provided via different Data Producers.

[0143]

[0108] All the functions listed above may be separate functions of a data collection architecture within the 6G network. The functions may be implemented at a single network node or may be implemented across a plurality of network nodes.

[0144]

[0109] Several architecture embodiments are provided below describing different methods for supporting a unified data collection architecture in the 6G system.

[0145]

[0110] According to some embodiments, a Data Consumer may be an NF, AF, 0AM, RAN or UE, and a Data Producer may be an NF, AF, 0 AM, RAN or UE. The UE and RAN may also interface with a Data Repository Register 1311 or a network repository function (NRF).

[0146] First Embodiment - Data Bus supporting a common SBI service

[0147]

[0111] According to a First Embodiment, RAN, Core and UE elements use a common SBI service for data collection, as shown in Figure 13.

[0148]

[0112] According to the first embodiment, a data consumer requests a topic or topics from a DCNF controller using a standardised SBI service for data collection. The request may include one or more of the following:

[0149] A Data Collection Profile which may include one or more of the following information: information on the network data required, for example, a list of Topic(s). The Topics may be mapped to a specific Event ID. In one embodiment, the Topic may correspond to a set of standardised data provided by an NF-type / RAN / OAM or UE.

[0150] The type of Data Producer from which data related to the Topic is to be retrieved (e.g. UE, RAN or NF-Type). the type of data consumer (e.g. UE, RAN or NF-Type) the service for which the data is requested (e.g. ML model training, data analytics), vendor information an AF service identifier (if the data consumer is an AF) Validity information including an Area of Interest / Time Window an authorisation access token (which is used by the DCNF to verify whether the Data Consumer is authorised to access the data).

[0151] Data Processing Instructions which may include one or more of the following information:

[0152] Information on how often the data are to be reported (e.g. periodically, by size, by number of samples, by averaging of data)

[0153] Anonymisation of data (e.g. data with UE identifiers removed) whether the data needs to be provided to an external server (as per the fourth embodiment) an indication that data is to be re-used / stored locally an indication that data are not to be re-used and reported to an external address.

[0154]

[0113] The Data Consumer may be aware of how the data are translated to a list of Topics. For example, if a policy control function (PCF) requires data to train an AI / ML model for deriving an appropriate QoS profile, the data required by the PCF may be, e.g., data rate performance from a UPF, QoS flow establishment information from an SMF, service experience info from an AF, and data that will assist the PCF (or any model training function that trains an ML model for the PCF) to train the AI / ML model.

[0155]

[0114] Before a Data Consumer subscribes to the DCNF, the Data Consumer may check via the NRF, or via a new Data Repository Register function, the available Topics and / or the Topics that can be retrieved at the DCNF.

[0156]

[0115] The DCNF (controller) authorises the Data Consumer request and checks whether the Data Consumer is authorised to retrieve the data requested. The following may be taken into account for authorising data to be provided to a data consumer:

[0157] Taking into account user consent information (if the data contains user related information). The DCNF checks internally or verifies with a unified data management (UDM) or Data Producers. Whether Data Producers have provided authorisation to provide data to the Data Consumer. This may be based on an access token, a Vendor Allowed List, an AF service identifier, and / or a type of service requested. The authorisation information may be registered in an NRF, UDM a 6G related NF or at the Data Producer.

[0158]

[0116] If the Data consumer is authorized, the DCNF (controller) identifies whether the Topics are available at a DCNF (server) by interfacing with the Data Repository Register or the NR, if the DCNF identifies a DCNF server where Topic(s) are locally available.

[0159]

[0117] If the data requested are not locally available, the DCNF identifies one or more Data Producers that can provide the Topics and triggers the Data Producers to publish the data.

[0160] If the Topic corresponds to data from multiple Data Producers, the DCNF (controller) is responsible for triggering the Data Producer to publish Topics, unless the Data Producer is already configured to publish topics as per an OAM configuration.

[0161] If the Topic corresponds to data provided by a specific type of Data Producer (e.g. AMF type) the DCNF (controller) is responsible for triggering the Data Producer to report the Topics required by each NF -type (unless the Data Producer already publishes data, e.g., as per OAM configuration or the topics are already available at the DCNF server).

[0162]

[0118] An alternative approach for requesting data from a Data Producer is by the Data Producer first establishing a session using a common SBI service with the controller entity in the DCNF and the DCNF responding (e.g. with a POST) with a configuration. For the latter case, each Data Producer is configured with the DCNF address to establish a session. Each Data Producer is configured to discover the DCNF based on a DNS query, a specific configuration via an OAM, or by discovering the DCNF via the NRF (if the Data Producer is configured to publish a specific type of data).

[0163]

[0119] The DCNF (Controller entity) subscribes for data from the relevant Data Producer, including in the request one or more of the following:

[0164] The Topics or data related to Topic that need to be published by the Data

[0165] Producer. The address of the DCNF server (e.g. external server address or a server in the operator realm) taking into account the Data Consumer request.

[0166]

[0120] The DCNF (controller) also configures the DCNF (server) with a configuration to provide the data (available locally at the DCNF server, or provided by the Data Producer to the DCNF server) to the consumer according to the Data Collection Profile and Data Processing Instructions. The configuration includes

[0167] The Topic(s) that need to be processed and reported to the Data Consumer The data that need to be retrieved and be combined to a Topic (if a Topic requires data from multiple Data Producers)

[0168] The Address of the Data Consumer to which the data is to be reported (e.g. if the DCNF controller and server are separate functions)

[0169] Whether the Topic(s) are to be stored locally.

[0170]

[0121] The Server in the DCNF processes the data according to the configuration received from the DCNF controller and reports the data to the Data Consumer using a dedicated data SBI service. The Server may also store the data to a local repository (e.g. 6G ADRF) if data are to be re-used.

[0171]

[0122] Each Data Producer may register in the NRF or a new Data Repository Register function the Topics that it is able to Publish.

[0172]

[0123] The DCNF may also register in the NRF or a new Data Repository Register function the available Topics.

[0173]

[0124] For better management (port reuse for multiple sessions / connections, flow control and prioritization) of traffic, the SBI service for reporting data is based on Quick UDP Internet connection (QUIC) allowing a user datagram protocol (UDP) type of connection.

[0174]

[0125] An example encoding of a combined Topic that is provided by the DCNF to the Data Consumer is shown in the Table below.

[0175] Topic "Data related to ML Model training for QoS decisions"

[0176]

[0126] An example encoding of a Topic that is provided by a Data Producer is shown in the Table below. The DCNF may provide the Topic provided by the Data Producer to the Data Consumer without further processing (i.e. without combining data from different topics to a single topic):

[0177] Topic "Data Rate Performance"

[0178] Second Embodiment: Data bus based on proprietary messaging protocols

[0179]

[0127] A data collection architecture according to the second embodiment is shown in Figure 14.

[0180]

[0128] The second embodiment has a variation in the method where the Data Producer publishes data to a DCNF 1301 as follows:

[0181] A Data Consumer 1309 requests data related to a Topic from the DCNF 1301 as in the first embodiment.

[0182] The DCNF 1301 determines whether the Data Consumer 1309 is authorised for the requested Topic(s) as in the first embodiment.

[0183] The DCNF 1301 checks if Topics are available at the Server 1303 and configures the Server 1303 to report the Data as in the first embodiment.

[0184] If the Topic(s) are not available the DCNF 1301 triggers the Data

[0185] Producers to Publish data related to a topic as follows: The DCNF 1301 triggers the Data Producers to Publish data either using a common SBI service as in the first embodiment or via a proprietary messaging protocol, such as Kafka. The proprietary protocol to use is based on network operator and vendor preference. The controller also supports an adaptor function that is responsible to configure the server as follows:.

[0186] The DCNF controller / adaptor 1305 also provides processing instructions to the Server on how to manage the data provided by the Data Producer which include:

[0187] Instructions on how to translate the data provided by each Data Producer to a set of Topic(s) or combine the data to one type of topic. a List of Topics to retrieve the address of the Data Consumer 1309 to report the data. The adaptor sends the report via SBI.

[0188] Data Producer(s) publish the requested Topic via a data based protocol (e.g. Kafka protocol) to the DCNF (based on the address of the DCNF provided in the configuration).

[0189] In Figure 14, the UE 1307 and RAN 1315 may also interface with Data Repository Register or NRF 1311.

[0190] Third Embodiment: Configuration of Data Producers via a Control Plane

[0191]

[0129] An architecture according to the third embodiment is shown in Figure 15.

[0192]

[0130] The third embodiment follows the principles of the first and second embodiments, where the following are alternatives for configuring Data Producer(s) on the Topics to publish:

[0193]

[0131] According to the third embodiment, the Data Producers (RAN and UEs) are configured regarding the data to collect and publish. The configuration is carried out via a control plane as shown in Figure 15. In one embodiment, the controller sends the configuration via an SBI service to a 6G AMF 1501 and the 6G AMF 1501 in turn provides the configuration via an NAS to the UE 1317 and via 6G N2 reference point to the RAN 1315. The configuration is sent within a dedicated container for RAN configuration and dedicated container for UE configuration.

[0194]

[0132] Fourth Embodiment: Exposure to external servers

[0195]

[0133] An architecture of according to the fourth embodiment is shown in Figure 16.

[0196]

[0134] The fourth embodiment follows the principles of embodiment 1 or 2 where the following are alternatives:

[0197]

[0135] According to the fourth embodiment, there is an alternative procedure to publish data to an external server in the case that a data consumer 1603 provides an indication to provide data related to Topics to an external server 1605. The controller either configures the local server with an identifier of a server (such as an address of the external server, a domain name, etc.) or configures the Data Producers with the identifier of the server to which to publish the data. The configuration of the Data Producers follow the principles of the first, second, and third embodiments. The exposure to third party servers 1605 may be carried out via a Network Exposure Function.

[0198]

[0136] The data producers publish the network data based on the alternatives described in the first and second embodiments.

[0199]

[0137]

[0200]

[0138] Fifth Embodiment - Configuration of Data Producers via QAM

[0201]

[0139] Figures 17 and 18 show data collection architectures according to a fifth embodiment. The fifth embodiment follows the principles of all previous embodiments, with the additional feature that the Data Producers are configured with the Topic(s) to publish from an 0AM.

[0202]

[0140] Figure 17 shows a data collection architecture a first example according to i the fifth embodiment. In the first example, each Data Producer may be configured directly from an 0AM 1701 with Topics to publish. Data Producers are configured with the DCNF address to establish a session and publish Topics.

[0141] Figure 18 shows a data collection architecture for a second example according to the fifth embodiment. In the second example, the OAM 1701 configures the DCNF 1301 with the topics to subscribe to per Data Producer type (e.g. NF -type). The OAM configuration may be based on SLA agreements between the vendor and the network operator. Based on the OAM configuration, the DCNF 1301 configures Data Producers with the topics to publish based on alternative procedures defined in previous embodiments.

[0203]

[0142] Each Data Producer is configured with the DCNF address to establish a session. Each Data Producer discovers the DCNF based on a DNS query, specific configuration via OAM, or by discovering the DCNF via the NRF.

[0204]

[0143] Data Producers publish data to the DCNF based on alternative procedures defined in the first and second embodiments.

[0205]

[0144] The following information is common to all embodiments and clarifies additional procedures and parameters during messages exchanged between the Data Consumer 1309, the DCNF 1301, and the Data Producers 1313, 1315, 1317.

[0206]

[0145] The example of such a procedure is shown in Figure 19. Figure 19 depicts a communication flow between data producers 1901, a DCNF 1301 including a DCNF server 1303 and a DCNF control 1305, a data repository register 1307, an NRF 1903 and data consumers 1905. Some of these steps may be omitted, and any of the steps may be performed in a different order to the description below.

[0207]

[0146] In step 0, the Data Producer 1901 may advertise the Topics capable to Publish in the Data Repository Register 1307 (step 0a) or the NRF 1903 (step 0b). This may take place based on a prior configuration via, e.g. an OAM, to publish specific topics.

[0208]

[0147] In step 1, the DCNF 1301 may advertise the Topic(s) available in the Data Repository Register 1307 or the NRF 1903. This may take place based on prior configuration via, e.g. OAM, to trigger the Data Producer 1901 to publish specific topics.

[0209]

[0148] In step 2, the DCNF 1301 registers its capability at an (6G) NRF 1903. The capability includes Controller 1305 and / or Server 1303 and / or Data Repository Register 1307 functionality. The DCNF 1301 may include the type of data source, i.e., NF, UE or RAN where data can be retrieved, the area of interest and / or the type of data that can be collected, the available Topics.

[0149] In step 3, a Data Consumer 1905 may determine that it requires data collection (e.g. to train an ML model for an AIML related activity).

[0210]

[0150] In step 4, the Data Consumer 1905 sends a request to the NRF 1903 or Data Repository Register 1307 to discover the DCNF 1301. The request may include Topics of interest, a request to collect data via a specific NF type, UE or RAN, spatial validity conditions (e.g. in an indicated area of interest). The NRF responds with a list of DCNF 1301 address(es).

[0211]

[0151] In step 5, the Data Consumer 1905 selects a DCNF 1301 and requests Data from the DCNF 1301 including a Data Collection Profile and Data Processing Instructions as described in the first embodiment.

[0212]

[0152] In step 6, the DCNF 1301 determines the Topics that need to be retrieved based on the requested Data Collection Profile. The DCNF 1301 also determines the Data Producer(s) 1905 that can provide the identified Topics.

[0213]

[0153] In step 7, the DCNF 1301 may check with the Data Register Repository 1307 or NRF 1903 if the Topics are already available.

[0214]

[0154] In step 8, the DCNF 1301 checks whether the Data Consumer 1905 is authorised to retrieve the data. The check may include:

[0215] If the data is related to a UE or user, whether the user has provided consent to expose the data.

[0216] Whether the consumer is authorised to access the data request from the data producers (based on vendor information, AF identifier, type of data, access token, etc.).

[0217]

[0155] In step 9, the DCNF 1301 may check with the data producer (or via the NRF in a case in which it needs to discover the data producer) to obtain authorisation to retrieve data on behalf of the data consumer. The DCNF 1301 may use an access token provided by Data Consumer.

[0218]

[0156] In step 10, if the server is not collocated at the DCNF 1301, the DCNF 1301 discovers and selects a server (either an operator realm or external server) taking into account the Data Consumer 1905 requirements (Data Collection Profile, Data Processing Instructions) provided in step 5.

[0157] In step 11, the DCNF 1301 may allocate an identifier (correlation id) to allow the consumer to identify how to link the request of data in step 5 with data provided by the server (in step 20). This is the case if the Controller and Server are separate functions.

[0219]

[0158] In step 12, the DCNF 1301 acknowledges the request in step 4 and provides the correlation id to the Data Consumer 1905.

[0220]

[0159] In step 13, the DCNF (controller) 1305 configures the DCNF (Server) 1303 with Data Processing Instructions. The configuration may include:

[0221] Instructions to merge data from multiple Topics and provide a report to the Data Consumer

[0222] Indication of using Topics from specific Data Producer(s) / Data Producer Type(s)

[0223] Consumer address to report the data (necessary in case the Controller and Server are separate functions)

[0224]

[0160] In step 14, the DCNF 1301 may configure the Data Producers 1905 to report the data. The configuration may be an SBI request with a Data Collection Profile to report the data. According to the fifth embodiment, step 14 may be carried out before a consumer request, i.e. Data Producers are configured with Topics to publish based on an 0AM configuration or based on SLA agreements.

[0225]

[0161] In step 15, the Data Producer 1901 logs data.

[0226]

[0162] In step 16, the Data Producer 1901 reports the data. The Data report is included in a container which may be provided to the Server in a dedicated data SBI request (as in the first embodiment) or based on an implementation specific protocol (as in the second embodiment). If the server is external, the Data Producer may report the data directly to the external server as in step 16b.

[0227]

[0163] In step 17, the DCNF (Server) 1303 processes the data according to the Data Processing Instructions. If the DCNF (server) 1303 implements a data messaging protocol, the DCNF 1301 identifies how data are included in Topic based on instructions from the adaptor within the DCNF 1301.

[0228]

[0164] In step 18, the DCNF (Server) 1303 locally stores the data or forwards the data according to the Data Processing Instructions.

[0165] In step 19, the DCNF 1301 (Controller or Server) may update the Data Repository Register 1307 or NRF 1903 with the Topics / Features available.

[0229]

[0166] In step 20, the DCNF (Server) 1303 provides the Data to the Data Consumer 1905 in a dedicated data SBI request. The report includes the correlation ID.

[0230]

[0167] In step 21, the Data consumer 1905 correlates the data based on the correlation ID.

[0231]

[0168] According to at least some embodiments, provided is a network entity configured to: receive a request for collecting network or radio related data for a Topic including first requirements; identity one or more data parameters related to a topic that need to be collected / monitored by the network entity; discover a first network function for publishing data related to a Topic; publish the data related to a Topic to the first network function. The DCNF may identify a server with available data associated with the network topic. The first requirement may include a Topic Identifier, an address of a network function to publish data. The address of a network function may correspond to a network function (NF) identifier. The address of a network function may correspond to an FQDN. A Topic may correspond to an Event Identifier in the mobile communication network. The topic identifier may indicate a pre-stored topic that is provided in a look-up table. The topic identifier may comprise a list of data to be included in the topic. A first network function for publishing data may be discovered from the NRF. A first network function for publishing data may be discovered using a DNS query to the FQDN included in first requirements. Data may be published to the first network function in a service based interface protocol. Data may published to the first network function in a data based protocol (e.g. kafka). Data for a topic may be included in a container. The network entity may be a network function in the 6G core network, a RAN node or a UE. The first request may be sent from an 0AM. The first request may be sent from a Network Function responsible for data collection.

[0232]

[0169] According to at least some embodiments, also provided is a network entity configured to: receive a request for data for a Topic (or list of topics) from a Data Consumer wherein the request includes a Data Collection Profile and Data Processing Instructions; identify the network or radio data related to topics that need to be reported; determine if a Data Consumer has authorisation to access the Topics; discover a “DCNF server” entity where data related to a topic are available; configure the DCNF server to collect the local data related to a topic and report them the consumer.

[0233]

[0170] The Data Collection Profile may include: Event ID / Topic ID, type of Data Producer where data related to the Topic are to be be retrieved (e.g. UE, RAN or NF-Type), the type of consumer, the service for requesting data (e.g. ML model training), vendor information, AF service identifier (if the data consumer is an AF), Validity information including Area of Inter est / Time Window, Authorisation access token (which is used by the DCNF to verify whether Data Consumer is authorised to retrieve data).

[0234]

[0171] The Data Processing Instructions may include: store or forward information, Information on how often the data are to be reported (e.g. periodic, size, number of samples, averaging of data), Anonymisation of data (e.g. remove UE identifiers), whether the data needs to be provided to an external server (as per embodiment 4), indication that data is to be re-used / stored locally, an indication that data are not to be re-used and Reported to an external address,

[0235]

[0172] Figure 20 illustrates an example of a UE 2000 in accordance with aspects of the present disclosure. The following paragraphs refer to a UE. However, the disclosure is not limited to the network entity being a UE, and it could be any other type of network entity. The UE 2000 may include a processor 2002, a memory 2004, a controller 2006, and a transceiver 2008. The processor 2002, the memory 2004, the controller 2006, or the transceiver 2008, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0236]

[0173] The processor 2002, the memory 2004, the controller 2006, or the transceiver 2008, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0174] The processor 2002 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 2002 may be configured to operate the memory 2004. In some other implementations, the memory 2004 may be integrated into the processor 2002. The processor 2002 may be configured to execute computer-readable instructions stored in the memory 2004 to cause the UE 2000 to perform various functions of the present disclosure.

[0237]

[0175] The memory 2004 may include volatile or non-volatile memory. The memory 2004 may store computer-readable, computer-executable code including instructions when executed by the processor 2002 cause the UE 2000 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 2004 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0238]

[0176] In some implementations, the processor 2002 and the memory 2004 coupled with the processor 2002 may be configured to cause the UE 2000 to perform one or more of the functions described herein (e.g., executing, by the processor 2002, instructions stored in the memory 2004). For example, the processor 2002 may support wireless communication at the UE 2000 in accordance with examples as disclosed herein. The UE 2000 may be configured to support a means for receiving a request for data collection associated with a network topic; identifying one or more parameters for the data collection associated with the network topic; identifying a server for publishing collected data associated with the network topic; and transmitting the collected data associated with the network topic to the server for publishing via a network interface.

[0239]

[0177] The controller 2006 may manage input and output signals for the UE 2000. The controller 2006 may also manage peripherals not integrated into the UE 2000. In some implementations, the controller 2006 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 2006 may be implemented as part of the processor 2002.

[0240]

[0178] In some implementations, the UE 2000 may include at least one transceiver 2008. In some other implementations, the UE 2000 may have more than one transceiver 2008. The transceiver 2008 may represent a wireless transceiver. The transceiver 2008 may include one or more receiver chains 2010, one or more transmitter chains 2012, or a combination thereof.

[0241]

[0179] A receiver chain 2010 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 2010 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 2010 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 2010 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 2010 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0242]

[0180] A transmitter chain 2012 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 2012 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 2012 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 2012 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0243]

[0181] Figure 21 illustrates an example of a processor 2100 in accordance with aspects of the present disclosure. The processor 2100 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 2100 may include a controller 2102 configured to perform various operations in accordance with examples as described herein. The processor 2100 may optionally include at least one memory 2104, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 2100 may optionally include one or more arithmetic-logic units (ALUs) 2106. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0244]

[0182] The processor 2100 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 2100) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).

[0245]

[0183] The controller 2102 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 2100 to cause the processor 2100 to support various operations in accordance with examples as described herein. For example, the controller 2102 may operate as a control unit of the processor 2100, generating control signals that manage the operation of various components of the processor 2100. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0246]

[0184] The controller 2102 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 2104 and determine subsequent instruct! on(s) to be executed to cause the processor 2100 to support various operations in accordance with examples as described herein. The controller 2102 may be configured to track memory address of instructions associated with the memory 2104. The controller 2102 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 2102 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 2100 to cause the processor 2100 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 2102 may be configured to manage flow of data within the processor 2100. The controller 2102 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 2100.

[0247]

[0185] The memory 2104 may include one or more caches (e.g., memory local to or included in the processor 2100 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 2104 may reside within or on a processor chipset (e.g., local to the processor 2100). In some other implementations, the memory 2104 may reside external to the processor chipset (e.g., remote to the processor 2100).

[0248]

[0186] The memory 2104 may store computer-readable, computer-executable code including instructions that, when executed by the processor 2100, cause the processor 2100 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 2102 and / or the processor 2100 may be configured to execute computer-readable instructions stored in the memory 2104 to cause the processor 2100 to perform various functions. For example, the processor 2100 and / or the controller 2102 may be coupled with or to the memory 2104, the processor 2100, the controller 2102, and the memory 2104 may be configured to perform various functions described herein. In some examples, the processor 2100 may include multiple processors and the memory 2104 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0249]

[0187] The one or more ALUs 2106 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 2106 may reside within or on a processor chipset (e.g., the processor 2100). In some other implementations, the one or more ALUs 2106 may reside external to the processor chipset (e.g., the processor 2100). One or more ALUs 2106 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 2106 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 2106 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 2106 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 2106 to handle conditional operations, comparisons, and bitwise operations.

[0250]

[0188] The processor 2100 may support wireless communication in accordance with examples as disclosed herein. The processor 2100 may be configured to or operable to support a means for receiving a request for collecting network data for a network topic; identifying one or more data parameters related to the network topic to be monitored and collected; identifying a server for publishing data related to the network topic; and publishing the data related to the network topic to the server via a network interface.

[0251]

[0189] Figure 22 illustrates an example of a NE 2200 in accordance with aspects of the present disclosure. The NE 2200 may include a processor 2202, a memory 2204, a controller 2206, and a transceiver 2208. The processor 2202, the memory 2204, the controller 2206, or the transceiver 2208, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0252]

[0190] The processor 2202, the memory 2204, the controller 2206, or the transceiver 2208, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0191] The processor 2202 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 2202 may be configured to operate the memory 2204. In some other implementations, the memory 2204 may be integrated into the processor 2202. The processor 2202 may be configured to execute computer-readable instructions stored in the memory 2204 to cause the NE 2200 to perform various functions of the present disclosure.

[0253]

[0192] The memory 2204 may include volatile or non-volatile memory. The memory 2204 may store computer-readable, computer-executable code including instructions when executed by the processor 2202 cause the NE 2200 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 2204 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0254]

[0193] In some implementations, the processor 2202 and the memory 2204 coupled with the processor 2202 may be configured to cause the NE 2200 to perform one or more of the functions described herein (e.g., executing, by the processor 2202, instructions stored in the memory 2204). For example, the processor 2202 may support wireless communication at the NE 2200 in accordance with examples as disclosed herein. The NE 2200 may be configured to support a means for receiving a request for data associated with a network topic from a data consumer via a network interface, wherein the network topic is associated with one or more data producing network entities; and configuring a sever for data collection and reporting associated with the network topic, wherein the server is configured to collect the data via a same network interface for each of the one or more data producing network entities associated with the network topic.

[0255]

[0194] The controller 2206 may manage input and output signals for the NE 2200. The controller 2206 may also manage peripherals not integrated into the NE 2200. In some implementations, the controller 2206 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 2206 may be implemented as part of the processor 2202.

[0256]

[0195] In some implementations, the NE 2200 may include at least one transceiver 2208. In some other implementations, the NE 2200 may have more than one transceiver 2208. The transceiver 2208 may represent a wireless transceiver. The transceiver 2208 may include one or more receiver chains 2210, one or more transmitter chains 2212, or a combination thereof.

[0257]

[0196] A receiver chain 2210 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 2210 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 2210 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receiver chain 2210 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 2210 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0258]

[0197] A transmitter chain 2212 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 2212 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 2212 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 2212 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0259]

[0198] Figure 23 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a UE as described herein. In some implementations, the UE may execute a set of instructions to control the function elements of the UE to perform the described functions.

[0199] At 2302, the method may include receiving a request for data collection associated with a network topic . The operations of 2302 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2302 may be performed by a UE as described with reference to Figure 20.

[0260]

[0200] At 2304, the method may include identifying one or more parameters for the data collection associated with the network topic . The operations of 2304 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2304 may be performed by a UE as described with reference to Figure 20.

[0261]

[0201] At 2306, the method may include identifying a server for publishing collected data associated with the network topic . The operations of 2306 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2306 may be performed a UE as described with reference to Figure 20.

[0262]

[0202] At 2308, the method may include transmitting the collected data associated with the network topic to the server for publishing via a network interface . The operations of 2308 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2308 may be performed a UE as described with reference to Figure 20.

[0263]

[0203] It should be noted that the method described herein describes A possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0264]

[0204] Figure 24 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions.

[0265]

[0205] At 2402, the method may include receiving a request for data associated with a network topic from a data consumer via a network interface, wherein the network topic is associated with one or more data producing network entities. The operations of 2402 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2402 may be performed by a NE as described with reference to Figure 22.

[0266]

[0206] At 2406, the method may include configuring a server for data collection and reporting associated with the network topic, wherein the server is configured to collect the data via a same network interface for each of the one or more data producing network entities associated with the network topic. The operations of 2406 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2406 may be performed a NE as described with reference to Figure 22.

[0267]

[0207] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0268]

[0208] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

CLAIMSWhat is claimed is:

1. A network entity comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network entity to: receive a request for data collection associated with a network topic; identify one or more parameters for the data collection associated with the network topic ; identify a server for publishing collected data associated with the network topic; and transmit the collected data associated with the network topic to the server for publishing via a network interface.

2. A network entity according to claim 1, wherein the request indicates an identifier of the network topic, or an identifier of the server, or both.

3. A network entity according to claim 2, wherein the identifier of the server comprises at least one of a network function identifier or a fully qualified domain name (FQDN).

4. A network entity according to any preceding claim, wherein, to transmit the collected data to the server for publishing, the at least one processor is configured to cause the network entity to communicate with the server via the network interface using at least one of a service-based interface protocol or a data-based interface protocol.

5. A network entity according to any preceding claim, wherein the collected data associated with the network topic is included in a container including an identifier that associates the collected data to the network topic.

6. A network entity according to any of claims 1 to 5, wherein the network entity comprises at least one of a network function of a core network, a Radio Access Network (RAN) node, or a User Equipment (UE).

7. A network entity according to any of claims 1 to 6, wherein the network topic comprises one or more of: throughput, packet loss rate, downlink packet delay, uplink packet delay, radio resource utilization; mobility events, protocol data unit (PDU) session- related events, a number of registered UEs , a number of established PDU sessions, a number of registered UEs for a network slice, or a number of established PDU sessions for the network slice.

8. A method performed at a network entity, the method comprising: receiving a request for data collection associated with a network topic; identifying one or more parameters for the data collection associated with the network topic; identifying a server for publishing collected data associated with the network topic; and transmitting the collected data associated with the network topic to the server for publishing via a network interface.

9. A network equipment comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network equipment to: receive a request for data associated with a network topic from a data consumer via a network interface, wherein the network topic is associated with one or more data producing network entities; and configure a server for data collection and reporting associated with the network topic, wherein the server is configured to collect the data via a samenetwork interface for each of the one or more data producing network entities associated with the network topic.

10. A network equipment according to claim 9, wherein the network interface comprises at least one of a service-based interface or a data-based interface.

11. A network equipment according to claim 9 or claim 10, wherein the at least one processor is configured to cause the network equipment to receive the request from at least one of a Network Function supporting data collection or an Operations and Maintenance node (0AM).

12. A network equipment according to any of claims 9 to 11, wherein the one or more data producing network entities includes one or more of an Application Function (AF), a Radio Access Network (RAN) node, or a User Equipment (UE).

13. A network equipment according to any of claims 9 to 12, wherein the at least one processor is further configured to cause the network equipment to: determine if the data consumer has authorization to access the network topic, wherein the server is identified in response to the determination that the data consumer has authorization to access the network topic.

14. A network equipment according to any of claims 9 to 13, wherein the request includes a data collection profile including at least one of: an event identifier (ID); a topic ID; a type of data producing network entity; a type of data consumer; a service for requesting data; vendor information; an application function service identifier; validity information; and an authorization access token.

15. A network equipment according any of claims 9 to 14, wherein the request indicates at least one of: store or forward information; a periodicity for reporting the data; anonymization of data information; whether the data is to be transmitted to an external server; whether the data is to be stored locally; or whether the data is to be transmitted to an external address.

16. A network equipment according any of claims 9 to 15, wherein the network equipment comprises a data collection network function.

17. A network equipment according any of claims 9 to 16, wherein the network equipment comprises the server.

18. A network equipment according any of claims 9 to 17, wherein the server is a Data Collection Network Function (DCNF) server.

19. A network equipment according any of claims 9 to 18, wherein the network topic comprises one or more of: throughput, packet loss rate, downlink packet delay, uplink packet delay, radio resource utilization; mobility events, protocol data unit (PDU) session- related events, a number of registered UEs , a number of established PDU sessions, a number of registered UEs for a network slice, or a number of established PDU sessions for the network slice.

20. A method performed by a network equipment, the method comprising: receiving a request for data associated with a network topic from a data consumer via a network interface, wherein the network topic is associated with one or more data producing network entities; configuring a server for data collection and reporting associated with the network topic, wherein the server is configured to collect the data via a same network interface for each of the one or more data producing network entities associated with the network topic

Images