Data collection enabled service

Abstract

Methods, devices, and systems for data collection enabled services are described herein. In one aspect, a method may include receiving, by a data collection enable service (DCES), a data collection request; determining, by the DCES, one or more data sources based at least on the discovered data source profiles; receiving data from one or more data sources and by the DCES according to the received request; generating, by the DCES, a data set from the received data; storing the generated data set in a repository in communication with the DCES; and transmitting, by the DCES, a response to the data collection request, the response indicating a storage location of the generated data set.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 339,692, filed on May 9, 2022, entitled “Data Collection Enablement Service,” the contents of which are hereby incorporated by reference. Background Art

[0003] Application Layer and Service Enablement Layer Data analytics requires the collection of input data from various entities at different layers, such as vertical specific servers / clients, third-party servers, Service Enabler Architecture Layer (SEAL), Edge Application Servers (EAS), etc. In order to support analytics enablement services, it will be necessary to specify how this data can be collected and how data can be received from different data sources / producers to prepare the data for use in exporting analytics.

[0004] Currently, the network data analysis function (NWDAF) and application data analysis enablement (ADAE) have defined the input data required by different types of analysis. However, in the case where the same type of data is available at multiple entities, it is not specified from which exact entity the input data can be collected. For example, in order to perform edge enabler server (EES) load analysis, data on the number of EAS registered with EES is required. This information is available at several different entities in the EEL. In addition to the EES itself, the edge configuration server (ECS) to which the EES is registered can also provide this information because it is included in the EES registration (and update) message. During service provisioning, the ECS will also provide this information to the edge enabler client (EEC). Therefore, determining which entity (e.g., EES, ECS, or EEC) can be selected as the data source for providing EES load data can depend on the requirements of the data and / or the preferences / restrictions of the data producer. It can be specified how to select the best entity to provide the required data, how to collect data from the selected entity, and whether / how the existing service enablement layer process can be used to enable data collection.

[0005] Moreover, analytical data can be collected from different layers / levels in the network, with different granularity or confidence levels. For example, to support analysis related to application QoS, data can be collected from: operations, administration, and management (OAM), monitoring of network quality of service (QoS) through 5GC, subscription and reception of QoS and network analysis from NWDAF, performance data from application servers, QoS data from enabling layer client-server sessions. In another example, UE location information can be obtained from the application layer (e.g., application client (AC) profile), service enabling layer (e.g., location information report, EEC context), and core network (e.g., NWDAF, access and mobility management function (AMF)). It is not specified how data collection is performed in these scenarios, such as which level / layer can be selected to collect data, whether / how to combine data collected from different levels / layers, etc.

[0006] Furthermore, the collected data required by one analysis request may be reused by other requests for the same / similar data. In order to avoid duplicate data collection and optimize the efficiency of the data collection process, it may be necessary to define how to manage the collected data and how to coordinate data collection requests. Summary of the invention

[0007] The disclosure provided herein describes a method for enabling a data collection service to support analysis services at the 3GPP service enablement layer. The data collection enablement service (DCES) is either standalone or a capability of ADAE, SEAL or EEL that can receive data collection requests and create data collection instances. The request can be implicit in a data analysis request received by an ADAE server / client, or an explicit request for data collection generated by a service consumer in the application layer or service enablement layer.

[0008] The request may specify what data is required to be collected, the required data source, the required data format, the required data collection period, time requirements (sampling or update rate, data freshness), quantity requirements (number of data samples required, required data set size), quality requirements (granularity, accuracy, confidence level), storage requirements, required processing operations, data reporting objectives and methods, etc.

[0009] Information for a data collection instance may be recorded in a data collection profile that includes information in a data collection request and information identified / determined by the DCES when processing the request.

[0010] The DCES may receive a data source profile associated with an entity that may generate / provide data for a data collection request, wherein the data source profile specifies what may be supported by the entity for data collection. The data source profile may be received via a pre-provisioning or discovery process. The data source profile may be received before or after receiving the data collection request. The data source may be a vertical application layer entity, a service enablement layer entity (e.g., SEAL, SEALDD, EEL, NSCALE entity), a data collection enabling service (DCES) server / client, or a core network service / function (e.g., 8GC, OAM, NWDAF, data collection coordination function (DCCF)).

[0011] A data source profile may specify: supported data types (types of data that can be generated / provided), data generation schedule, data generation rate, supported data collection rates and methods, data update rate, data freshness, accessibility of data (for a specific requester or request), original data source, capabilities of the data source entity (e.g., storage, data processing, communication, anonymization, distributed data collection, supported data formats), etc. A data service profile may be defined for a specific entity or entity type.

[0012] DCES can check the dataset profile of existing datasets that can meet or partially meet the requirements in the data collection request. The dataset profile can specify: the type of data, the address of the dataset, the data source, the data collection scope (the layer / level from which the data is collected), the data generation time, the data collection time, the dataset creation time, the validity period (expiration time), the operations applied, the confidence level, the accessibility (for a specific requester or request), the dynamicity (whether the dataset is static / closed or dynamic / open), the requests associated with the dataset, etc. If an existing dataset that fully meets the requirements is found, DCES can consolidate the data collection request. If one or more existing datasets that partially meet the requirements are found, DCES can also identify additional actions to be taken (e.g., requiring additional data collection, requiring processing operations to modify the dataset, combining multiple datasets, etc.).

[0013] DCES can determine the data source entities from which data can be collected based on the requirements in the data collection request, the data service profile, and other information associated with the data source entity. DCES can determine the scope of data collection, what type of entity can serve as a data source, and the exact entity for data collection. This determination can take into account factors such as: combining data collected from different layers / levels to increase the confidence level, selecting a data source entity based on its data freshness, selecting a data source entity based on communication overhead, server load, location, efficiency, etc.

[0014] DCES can collect the requested data from the selected data source entity based on the determination. Data collection can be accomplished through on-demand data retrieval, subscription and notification processes, configuration data reporting processes, etc. When performing data collection in the EEL, DCES can leverage existing EEL functions such as EES capability exposure, EAS discovery, EEC context information, AC information exposure, etc.

[0015] DCES may send a distributed data collection request to enable distributed data collection, where data source entities may communicate directly with each other and provide data in a collaborative manner. The distributed data collection request may specify: applicable data source entities that may support distributed and collaborative data collection, redistribution configuration, collaborative operations, data reporting configuration, etc. The data source entities in distributed data collection may be hosted on devices that are not continuously online / on the network, or non-3GPP devices or devices without 3GPP connectivity.

[0016] The DCES may perform processing operations on the collected data or on an existing data set. The operation may be determined based on the data collection request. The operation may be to modify an existing data set. The operation may be to merge newly collected data with existing data. The operation may be a validation process performed on data collected from different data sources to improve the accuracy / confidence level.

[0017] The DCES may also manage the collected data. The collected data may be stored in a repository (eg, SEALDD storage service) by creating a new data set or updating an existing data set (and corresponding data set profile).

[0018] This summary is provided to introduce some concepts in a simplified form, which are further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter nor to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 Describes the vertical service enabler architecture layer (SEAL) in the 3GPP SA6 working group;

[0020] Figure 2 Describes the architecture for enabling edge applications in 3GPP SA6 working group;

[0021] Figure 3-Figure 6 depicts examples of processing for data collection-enabled services;

[0022] Figure 7A graphical user interface (GUI) of a UE that may be used for data collection enabled services is depicted.

[0023] Fig. 8A An example communication system is depicted in which the methods and apparatus described and claimed herein may be an aspect thereof;

[0024] Figure 8B depicts a block diagram of an example apparatus or device configured for wireless communication;

[0025] Figure 8C A system diagram depicting an example radio access network (RAN) and core network;

[0026] Fig.8D depicts another example RAN and core network system diagram;

[0027] Fig. 8E depicts another example RAN and core network system diagram;

[0028] Figure 8F depicts a block diagram of an example computing system; and

[0029] Figure 8G A block diagram of another example communication system is depicted. DETAILED DESCRIPTION

[0030] 3GPP SA2 defines a Data Collection Coordination Function (DCCF) to coordinate the collection of data requested by NF consumers (TS23.288). This prevents data sources from having to handle multiple subscriptions to the same data and send multiple notifications containing the same information due to uncoordinated requests from data consumers. DCCF is applicable to NWDAFs that request data from data sources, NF consumers that request analysis from NWDAF data sources, NF consumers that request data from ADRF data sources, and ADARFs that receive data from NF data sources.

[0031] Data consumers can use NRF to perform NF discovery and selection to find a DCCF that can coordinate data collection. Data consumers send requests for data to the DCCF instead of directly to the NF data source. Whether the data consumer contacts the NF data source directly or uses the DCCF is based on the data consumer's configuration. For each notification endpoint and data consumer in the data request, the data consumer can specify formatting and processing instructions that determine how the data is to be provided. Upon receiving a request from a data consumer, if the data source is not indicated in the data consumer's request, the selected DCCF determines the NF instance that may be the data source. The DCCF can also select the ADRF if the data is to be stored in the ADRF and the ADRF endpoint is not indicated in the data consumer's request.

[0032] The following functions / services are supported in DCCF: data formatting and processing; historical data disposal; data collection from NF, OAM; association between network data and service data; time coordination across multiple NWDAF instances; data collection with event muting mechanism; data collection from UE applications; and user consent for analysis.

[0033] 3GPP SA6 (TS23.434) defines the Service Enabler Architecture Layer (SEAL) to support vertical applications on 3GPP systems, including group management, configuration management, location management, identity management, key management, and network resource management. In particular, the SEAL client provides client-side functions corresponding to specific SEAL services. The SEAL client supports interaction with the Vertical Application Layer (VAL) client. The SEAL server provides server-side functions corresponding to specific SEAL services and supports interaction with the VAL server.

[0034] The following SEAL services are supported for the vertical application layer: location management; group management; configuration management; identity management; key management; and network resource management.

[0035] 3GPP SA6 (TS23.558[3]) defines EEC and EES to provide edge application enablement functions to the AC in the UE and the EAS in the edge network. The EEC provides the support functions required by the AC, including the retrieval and provision of configuration information to enable the exchange of application data traffic with the EAS, and the discovery of EAS available in the EDN.

[0036] EES provides support functions required by EAS and EEC, including: supplying configuration information to EEC to enable the exchange of application data traffic with EAS; supporting API exposure functions and API caller functions; interacting with the 3GPP core network for the ability to access network functions either directly or indirectly; supporting application context transfer functions; supporting exposure of 3GPP network and service capabilities to the outside of EAS; supporting registration functions for EEC and EAS (i.e., registration, update, and deregistration); and supporting on-demand triggering of EAS instantiation.

[0037] DCES supports and coordinates the collection of analytical data from the application layer and the service enablement layer. This service can be implemented either as a standalone capability or as a function provided by ADAES, SEAL, or EEL.

[0038] DCES can be implemented as a server hosted in the central network (DCES Central Server), which can collect data from vertical application servers, service enablement layer servers, and core network functions. DCES can also be implemented as a server on the edge (DCES Edge Server), which can collect data from EEL entities (such as EES, EAS, and EEC). DCES can also be implemented as a client-side function (DCES Client) hosted on the UE, which can collect data from vertical application clients, service enablement layer clients, and other UE-related information available locally.

[0039] A data collection request may be an explicit request to collect data from the application layer and / or the service enablement layer. A data collection request may be initiated by a consumer of the data collection service, or triggered by a predefined event. A data collection request may also be implied by a data analysis request sent to ADAES, where ADAES may identify the input data required by the analysis request and generate a data collection request accordingly. A data collection request may include one or more of the following information elements:

[0040] Table 1. Data collection request information elements

[0041]

[0042]

[0043]

[0044] A data collection request may specify all the information needed by the DCES to determine where and how to collect data. Alternatively, the request may not specify all the information, in which case the DCES can help determine where and how to collect the data. A data collection request may also be defined as a list of criteria based on parameters present in a data source profile.

[0045] A data collection profile may be generated by a DCES based on a received data collection request, which specifies what data needs to be collected and how the data may be collected in a corresponding data collection task / instance. A data collection profile may include information elements defined in a data collection request, as well as new information identified / determined by a DCES when processing a data collection request (Section 5.2.1). In addition to the information elements in Table 1, a data collection profile may also include one or more of the following information elements:

[0046] Table 2. Data Collection Profile Information Elements

[0047]

[0048]

[0049] A data source (e.g., a data producer) is an entity that can generate or provide data required by a data collection service for a data collection request. A data source entity may be a vertical application layer entity, such as a VAL server or client. The data provided by the VAL entity may include application-related data, such as VAL user information, performance indicators and measurements, application server status and load, application session status and load, etc. A data source entity may be a service enablement layer entity, such as a SEAL server / client, a SEALDD server / client, an EES / EEC, an NSCALE server / client, a CAPIF entity. As a data source, a service enablement layer entity may provide data related to service enablement layer event information, service availability and performance, enablement layer server status, etc. A DCES entity may also act as a data source to support hierarchical or distributed data collection and assist in data collection processing from an original data source. For example, a DCES edge server co-located with an EES may assist in data collection processing at the edge and act as a data source to send the collected data back to a DCES central server. A DCES client hosted on a UE may assist in local data collection and collaborate in distributed data collection. The data source entity may be a core network service / function such as OAM, DCCF, NWDAF. Hierarchical data collection may be supported, where DCCF or NWDAF may collect data from other entities and then expose the collected data (or analysis) as a data source to the DCES in the enabling layer.

[0050] A data source profile (e.g., a data producer profile) can be defined for a data source entity to specify what data can be provided and what data collection can be supported, such as the availability and accessibility of data generated / produced by the entity. If a data source entity can provide multiple types of data, the entity can choose to define a general data source profile for all types of data, or define a specific profile for each type of data. In a data source profile, the following information can be specified:

[0051] Table 3. Data source profiles

[0052]

[0053]

[0054]

[0055]

[0056] Data source profiles can be defined for specific entities or specific types of entities. For example, an EAS can define a data source profile to support data collection from that EAS. A data source profile can be independent or part of an EAS profile. If multiple EASs registered with the same EES share the same features for supporting data collection, a common data source profile for all of these EASs can be defined and maintained at the EES.

[0057] A data source profile may include information specific to data collection purposes. General information about an entity not included in a data source profile may also be used by the DCES for data collection purposes. For example, an EAS may not specify a data generation schedule in a data source profile, but the schedule information in its EAS profile may indicate when the EAS is available to generate data. The DCES may also use the EAS service area information in the EAS profile when determining whether data should be collected from a particular EAS for a location-based data collection request.

[0058] The collected data may be stored in a data repository, which may be a storage service provided by the DCES itself, or other service enablement layer functions (e.g., SEALDD storage services or ADRF). The collected data may be managed as datasets, where the characteristics of the dataset are described by a dataset profile. The following information may be specified in a dataset profile:

[0059] Table 5. Dataset profile

[0060]

[0061]

[0062] Figure 3 The common process of the data collection service is shown. These steps can be performed in the order shown, or in the same order as shown. Figure 3 The order shown in the figure is different from the order in which it is executed.

[0063] Step 1: DCES may receive a data collection request. The request may be implied by a data analysis request sent to ADAES. The request may also be an explicit request to collect data from the application layer and / or service enablement layer. DCES may create a data collection instance for the received request and generate a data collection profile to record information for the instance.

[0064] Step 2: The DCES may discover (or be supplied with) data source profiles (e.g., data producer profiles) associated with entities (e.g., data producers) that may potentially provide the required data. This step may be performed before or after receiving the data collection request (step 1). The DCES may store the discovered data source profiles for use in determining and selecting data sources for the data collection request. If the data collection request identifies a data source whose profile is not available at the DCES, the DCES may send a request to the corresponding entity to retrieve the data source profile.

[0065] Step 3: DCES may check the data repository or data sources with the "repository" role to find existing datasets that may satisfy or partially satisfy the requirements of the data collection request. The identified datasets may be added to the "Associated datasets" entry in the data collection profile.

[0066] If a static data set that meets the requirements is found, DCES may not perform further data collection (eg, proceed to step 8).

[0067] If a dynamic dataset that meets the requirements is found, the DCES may integrate the data collection request with the existing request associated with the dataset by updating the "associated request" parameter in the dataset profile (eg, proceed to step 7).

[0068] If a data set is found that partially meets the requirements, DCES can take action regarding the unmet requirements. For example, if the data collection request requires both EAS and EES data, and the existing data set only contains EAS data, DCES can further perform data collection from EES. If the request requires high confidence level data, and the existing data set contains data collected from the core network with a confidence level lower than the required level, DCES can further perform application layer and / or service enablement layer data collection to increase the confidence level. If a data set is found that contains data collected within a time window longer than the required collection time period defined in the request, DCES can process the data set (e.g., by segmentation) to obtain the required data segments.

[0069] If multiple data sets are found that partially meet the requirements, the DCES can aggregate / integrate the separate data sets to meet the data collection requirements. If the aggregated / integrated data set still may not fully meet the requirements, the DCES can take action on the unmet requirements, as described above.

[0070] Step 4: The DCES may determine the data source for data collection and may add the information to the "Data Source" and "Data Source Characteristics" entries in the data collection profile. The selection of the data source may be based on matching the data source profile with the requirements defined in the request, including the following:

[0071] Determine the scope of data collection. Determine whether to collect data from the application layer, service enablement layer, core network, or jointly across multiple layers based on which data is required and the required accuracy, granularity, or confidence level. When high accuracy is required, data can be collected from multiple sources located at different layers to increase the confidence level. For example, data related to application QoS can be collected from OAM, 8GC (monitoring of network QoS), NWDAF (subscription and reception QoS and network analysis), application servers, service enablement layer sessions, etc. In another example, UE location information can be obtained from the application layer (e.g., AC profile), service enablement layer (e.g., location information report, EEC context), and core network (e.g., NWDAF, AMF). Collecting data from multiple sources in different scopes / layers can provide higher accuracy or confidence levels.

[0072] Determine the type of entity that can be a data source. The type of entity from which data is collected can be determined based on the specific requirements in the data collection request. For example, if the required data is related to a specific application server, the corresponding application server and / or service enablement layer server that provides services to the application server can be identified as the data source. If the required data is related to the EDN state, the ECS and EES in the EDN can be identified as the data collection source.

[0073] Determine a specific entity as a data source. If the data collection request specifies an identifier of the target data source, such as a specific VAL user ID or an identifier of a specific server / client, the data source entity can be determined. In the absence of a specified data source entity or the presence of multiple entities that can provide the required data, the DCES can select the data source entity based on the data source profile and other information associated with the entity. For example, EES load data (e.g., the number of EAS registered with EES) can be obtained at EES (in the EES profile), ECS registered with EES (registered and updated by EES), and EEC registered with EES (provided to EEC by ECS during service provision). Although different entities can provide the same data, the freshness of the data may be different (e.g., the EES load data at the EES itself may be the latest). If data freshness or real-time performance is required, EES can be selected as the data source. Otherwise, ECS can be selected as the data source to avoid introducing additional load to EES, or if the data collection request is generated locally at the UE, EEC can be selected as the data source.

[0074] Step 5: DCES can collect data from the identified data source. Depending on the capabilities of the data source entity (as defined in the data source profile), DCES can determine the collection method and can add to the "Collection Method" entry in the data collection profile. Collection can be done through a data retrieval request, a subscription request, or a configured data reporting process, and the request can include information as indicated in Table 1.

[0075] On-demand data retrieval: DCES can send retrieval requests to data source entities to collect the requested data. In the retrieval request, DCES can specify which data is requested and other requirements for the data.

[0076] Subscription and Notification: DCES can send subscription request to data source to receive notification as collected data. In subscription request, DCES can specify notification criteria based on requested data and requirements.

[0077] Data reporting: DCES can configure the data source entity for reporting data. The configuration can specify which data to request, when the data source entity should send data to DCES (trigger criteria), the frequency of data reporting, etc.

[0078] Step 6: DCES may process the collected data or the existing data set identified in step 3, and may add the processing operation to the "Processing Operation" entry in the data collection profile. Processing may include one or more of the following.

[0079] Data processing may be applied based on the “processing action” defined in the data collection request.

[0080] Where an existing dataset is found that partially meets the requirements, DCES may modify / customize that dataset to fully meet the requirements.

[0081] In the event that an existing data set is found that partially meets the requirements and DCES performs further data collection to fully meet the requirements, DCES can combine the newly collected data with the existing data and apply operations such as aligning data samples based on timestamps, converting or transforming data to the same format or granularity, upsampling or downsampling, normalization, etc.

[0082] In the case where the same data is collected from multiple sources (across multiple layers), validation / calibration can be applied. For example, DCES can remove data samples that are inconsistent across different sources and retain data samples that are consistent across all sources to ensure a high confidence level.

[0083] Step 7: DCES may store the data in a repository (eg, SEALDD storage server) as indicated in the data collection request by creating a new dataset or updating an existing dataset, and create / update a corresponding dataset profile.

[0084] Step 8: DCES may send a response to the reporting target or requester specified in the data collection request. The response may include the address of the dataset in the repository and / or the profile of the dataset.

[0085] When collecting data from the EEL, the DCES can interact with the EEL entities by utilizing the reference points defined in the EEL. The DCES can be implemented as an entity in a centralized manner in the cloud, in a distributed manner at the edge, or a combination thereof.

[0086] If DCES is deployed in a central server (DCES Central Server), DCES can interact with ECS to collect data from EEL / EDN, such as Figure 4 as shown in .

[0087] Step 0: The DCES central server may discover the ECS associated with the EDN of interest.

[0088] Step 1a: EES may register with ECS. During registration, EES may provide its EES profile and data source profile to ECS, indicating whether / what data collection is supported.

[0089] Step 1b: EAS may register with EES. During registration, EAS may provide its EAS profile and data source profile to EES, indicating whether / what data collection is supported. EES may also provide the data source profile of the registered EAS to ECS in the following ways: either sending the EAS data source profile separately to ECS, or integrating the EAS data source profile into the EES data source profile and sending it to ECS.

[0090] Step 2: The DCES central server can discover the EES / EAS of interest from the ECS, which can include the discovery of the data source profile. Since the ECS maintains the registration information (EES profile) of the EES in the network, and the EES registration information can further contain a list of EAS registered with the EES, the DCES central server can be able to identify the EES / EAS required for data collection based on this information. The DCES central server can also discover the data source profile of the EES / EAS.

[0091] Step 3: Once the EES / EAS for data collection has been identified, the DCES central server can request data from the target EES / EAS either directly or through the ECS. For example, the DCES can send a subscription request to the ECS, which is then forwarded to the corresponding EES / EAS. Alternatively, the DCES central can collect EES / EAS data (e.g., EES / EAS profiles) that the ECS maintains for the EES / EAS.

[0092] Step 4: The requested data may be provided to the DCES central server either directly or through the ECS. For example, a notification message containing the data to be collected may be sent to the ECS and then forwarded to the DCES.

[0093] DCES can also be deployed at the edge (DCES edge server), for example, as a standalone function in the EDN, as an EAS, or as a function embedded in an existing EDN function (such as EES). The DCES edge server can interact with the EES through processes defined between the EES and EAS to collect data locally. The DCES edge server can also send the collected data to the DCES central server, which can integrate the data collected by multiple DCES edge servers, such as Figure 5 as shown in .

[0094] Step 1: The DCES edge server can register with the EES through a registration process. Alternatively, the DCES edge server can communicate with the EES through a message of a different type than registration (for example, the DCES edge server can subscribe to the EES or send a discovery request to the EES). The DCES edge server can send information about the EES to the DCES central server.

[0095] Step 2a: The EAS may register with the EES. During registration, the EAS may provide its EAS profile and data source profile to the EES, indicating whether / what data collection is supported.

[0096] Step 2b: EEC can register with EES. During registration, EEC can provide its EEC profile and data source profile to EES, indicating whether / what data collection is supported. EEC can also provide the data source profile of the registered AC to EES in the following ways: either send the AC data source profile separately to EES, or integrate the AC data source profile into the EEC data source profile and send it to EES.

[0097] Step 3: The DCES central server may distribute the data collection request to one or more DCES edge servers. The DCES central server may distribute the request based on the information about the EES obtained from the DCES edge servers in step 1.

[0098] Step 4: DCES can collect data from interested entities. In some cases, EES can be the data source. Data collection from EES can utilize EES capability exposure API, where EES information can be provided to EAS / DCES edge server.

[0099] In some cases, EAS can be the data source. Data collection from EAS can utilize the EAS discovery API provided by EES, which enables the DCES edge server to obtain information about EAS (EAS profile), such as EAS status, performance indicators, etc. In the discovery request, the DCES edge server can specify the discovery filter according to the requirements defined in the data collection request. Alternatively, the DCES edge server can communicate with EES through different types of messages (e.g., the DCES edge server can subscribe to EES).

[0100] In some cases, the EEC may be the data source. Data collection from the EEC may be achieved by requesting EEC registration information (EEC context) from the EES.

[0101] In some cases, AC can be the data source. Data collection from AC can utilize AC information exposure API to obtain AC information from EES. For example, DCES edge server can subscribe to AC information and specify subscription filters according to data collection requirements.

[0102] Step 5: The DCES edge server can send a response to the DCES central server using the collected data.

[0103] A process for distributed data collection is described herein. In distributed data collection, multiple data source entities can collaborate with each other to complete data collection requests. For example, data can be collected from a data source hosted by a UE that is not continuously online or in a specific area. Off-network entities can still generate data and provide the data to the DCES by forwarding the generated data to another data source entity that is online. To support distributed data collection, the DCES can configure distribution and collaborative operations between data source entities.

[0104] Distributed DCES entities (e.g., DCES clients on UEs) can assist in the data collection process in these scenarios. For example, a DCES client hosted on a UE can assist its co-located original data source in distributed data collection by redistributing / forwarding collection requests and / or relaying data collected at other UEs. Figure 6 An example is shown in FIG, where data source 1 and data source 2 can be associated with two UEs respectively. Each of data sources 1 and 2 can be an original data source entity supporting the distributed data collection function, or a DCES client that helps collect data from the original data source and reports to the DCES server / client in a higher layer as a data source.

[0105] Step 1: DCES may receive a data collection request and a data source profile (e.g., similar to Figure 3 Steps 1 and 2).

[0106] Step 2: DCES may select a data source for the data collection request and determine that distributed data collection is required. This determination may be based on examining the data source profile and other information of the selected data source entity. For example, DCES may identify that data source 1 and data source 2 are co-located, can be connected to each other off-grid, and their data generation schedules complement each other. A group of data sources may be defined as a data collection group, and DCES may determine a separate data collection request for each data source entity in the group. The data collection group may be defined based on the data source profile and other information associated with the data source entity and its hosted UEs, such as UEs located in a specific geographic area at a given time, existing preconfigured group IDs, specific broadcast / multicast groups, UE capabilities, UEs communicating with a specific VAL server, UEs in the EDN, etc.

[0107] Step 3: DCES can distribute data collection requests to data sources in the group by sending distributed data collection requests to some / all entities in the group. The request may include information about the data collection group, for example, the group ID. When distributing the request to the data source entity, DCES can provide authorization to the data source entity to redistribute the request to other data source entities (for example, when off-grid), and provide information about how they can connect to DCES for data reporting. In addition to the information in Table 1, the following information may also be included in the distributed data collection request.

[0108] Applicable Data Source Entity: A description of the applicable data source entity that produces the same data as the collection request.

[0109] Redistribution configuration: can indicate whether the data collection request can be redistributed / forwarded and which entities can be used as redistribution targets. It can also include information required by the forwarding request, such as authorization information, etc.

[0110] Collaboration operation: A description of an operation that requires direct communication between data source entities, which may involve data exchange, as well as data generation control. For example, one data source entity may trigger another data source entity to refresh data, restart data generation processing, etc.

[0111] Report configuration: Description of distributed data reporting configuration, such as whether to enable off-network reporting, reporting method (e.g., forwarding, aggregation, etc.), and how the collected data should be processed when the data source is offline.

[0112] Step 4: Data sources 1 and 2 in the data collection group can be directly connected. For example, data source 1 goes offline and connects with data source 2 off-grid.

[0113] Step 5: Data source 1 may identify that data source 2 is part of the data collection group based on the redistribution configuration received from DCES, and may forward the data collection request to data source 2.

[0114] Step 6: Data sources 1 and 2 may generate the data required by the collection. If the data source is a DCES entity, the data source may collect the required data from the original data source.

[0115] Step 7: Optionally, the data source entity may perform inter-data source communication required by the data collection request based on a "collaborative operation" parameter included in the distributed data collection request.

[0116] Step 8: Data Source 2 may be connected to the DCES and ready to report the collected data. For example, Data Source 2 may be online and may act as a relay for forwarding data collected by Data Source 1. Data Source 2 may check whether Data Source 1 has unreported data to send to the DCES. If so, Data Source 2 may collect data from Data Source 1 and send that data with its report. This functionality may be determined based on a "report configuration" parameter included in the distributed data collection request.

[0117] Step 9: The data source may send the collected data to the DCES. This may include indirect reporting from the data source based on the redistribution configuration and reporting configuration parameters. For example, data source 1 may provide the required data to data source 2 to indirectly report data to the DCES, or wait until it comes online to report data directly to the DCES.

[0118] Step 10: DCES may process the collected data.

[0119] Note that the exemplary scenario is shown as Data Source 2 coming online first, thus collecting data from itself and Data Source 1 and sending the data to the DCES. Many equivalent / alternative embodiments can be envisioned. For example, in some off-network deployments, only certain UEs can act as relays, i.e., only certain UEs can be on-network and off-network. Similarly, the data source entity can be hosted on a non-3GPP device, e.g., a device that can be identified in the network but has no 3GPP connection. Both embodiments will use similar procedures.

[0120] Figure 7 An example GUI for requesting a data collection service and viewing the results (collected data) is shown. A user can request a data collection request by selecting "New Request" and setting the requirements / configuration in the data collection request. A user can also check the results (collected data) of the data collection service by selecting "Existing Request" and entering the request ID, where the user will be able to obtain information about the collected data (data set profile) and other information of the data collection task / instance.

[0121] Example Communication System

[0122] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "8G". Development of the 3GPP NR standards is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include new flexible radio access providing below 7 GHz, and new ultra mobile broadband radio access providing above 7 GHz. Flexible radio access is expected to include new non-backward compatible radio access in new spectrum below 7 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to cope with a wide range of 3GPP NR use case sets with different requirements. Ultra mobile broadband is expected to include centimeter wave (cmWave) and millimeter wave (mmWave) spectrum that will provide opportunities for ultra mobile broadband access for indoor applications and hotspots, for example. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, leveraging design optimizations specific to centimeter-wave and millimeter-wave.

[0123] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which can include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and communications between vehicles and other entities. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, car e-calls (ecalls), disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and others are contemplated herein.

[0124] Fig. 8A An example communication system 100 is illustrated, of which the methods and apparatus described and claimed herein may be an aspect thereof. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (collectively or collectively may be referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 108B, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, although it should be appreciated that the disclosed examples contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 8A-8EAlthough depicted as a handheld wireless communication device, it should be understood that for a wide variety of use cases contemplated for 8G wireless communications, each WTRU may include or be included in any type of device or equipment configured to send and / or receive wireless signals, including (by way of example only) a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop computer, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, truck, train or airplane), etc.

[0125] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0126] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114b may be part of the RAN 103b / 104b / 108B, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a may be configured to send and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to send and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In some cases, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may use multiple transceivers for each sector of the cell.

[0127] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave (cmWave), millimeter wave (mmWave), etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0128] The base station 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b via a wired or air interface 118B / 116b / 117b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave (cmWave), millimeter wave (mmWave), etc.). The air interface 118B / 116b / 117b may be established using any suitable radio access technology (RAT).

[0129] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 118c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave (cmWave), millimeter wave (mmWave), etc.). The air interface 118c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0130] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with one another via an air interface 118D / 116d / 117d (not shown), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave (cmWave), millimeter wave (mmWave), etc.). The air interface 118D / 116d / 117d may be established using any suitable radio access technology (RAT).

[0131] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, TRPs 119a, 119b and RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 108B may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117 or 118c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0132] In some cases, the base station 114a and the WTRU 102a, 102b, 102c, or the RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b and WTRU 102c, 102d in the RAN 103b / 104b / 108B may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish the air interface 115 / 116 / 117 or 118c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communications, etc.). 3GPP NR technology includes NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0133] In some cases, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, the TRPs 119a, 119b and / or the RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 108B may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN) etc.

[0134] For example, Fig. 8AThe base station 114c in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, etc. In some cases, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In some cases, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Fig. 8A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not be required to access the Internet 110 via core network 106 / 107 / 109.

[0135] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions (such as user authentication).

[0136] Although not in Fig. 8A Although not shown in the figure, it will be appreciated that the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0137] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT or a different RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 108B.

[0138] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig. 8A The WTRU 102e shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0139] Figure 8B 1 is a block diagram of an example apparatus or device (such as, for example, WTRU 102) configured for wireless communication in accordance with various aspects described herein. Figure 8B As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the example. Moreover, in some cases, the base stations 114a and 114b and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver station (BTS), a node B, a site controller, an access point (AP), a home node B, an evolved home node B (eNodeB), a home evolved node B (HeNB), a home evolved node B gateway, and a proxy node, etc.) may include Figure 8BSome or all of the elements described in and described herein.

[0140] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 8B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0141] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in some cases, the send / receive element 122 may be an antenna configured to send and / or receive RF signals. In some cases, the send / receive element 122 may be a transmitter / detector configured to, for example, send and / or receive IR, UV or visible light signals. In some cases, the send / receive element 122 may be configured to send and receive both RF and optical signals. It should be appreciated that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0142] In addition, although the transmit / receive element 122 is depicted as a single element in FIG. 22B , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some cases, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0143] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., such as UTRA and IEEE 802.11).

[0144] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In some cases, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0145] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0146] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of receiving signals from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with the present invention.

[0147] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0148] The WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronic devices, wearable devices (such as smart watches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes). The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of the peripheral devices 138).

[0149] Figure 8C 1 is a system diagram of the RAN 103 and the core network 106. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also communicate with the core network 106. Figure 8C As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with aspects of the present disclosure.

[0150] like Figure 8C As shown in , Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control the corresponding Node B 140a, 140b, 140c connected thereto. In addition, each of RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0151] Figure 8CThe core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0152] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0153] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0154] As described above, core network 106 may also be connected to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0155] Fig.8D 1 is a system diagram of the RAN 104 and the core network 107. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0156] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with aspects of the present disclosure. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some cases, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0157] Each of the eNodeBs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. Fig.8D As shown in FIG. , the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0158] Fig.8D The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0159] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0160] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0161] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0162] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0163] Fig. 8E 1 is a system diagram of the RAN 105 and the core network 109. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be discussed further below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0164] like Fig. 8EAs shown in the figure, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with aspects of the present disclosure. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some cases, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to send wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy implementation, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of user profiles, routing to the core network 109, etc.

[0165] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0166] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handovers and data transfer between the base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0167] like Fig. 8EAs shown in , the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes protocols for facilitating, for example, data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0168] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0169] Although not in Fig. 8E 102a, 102b, 102c between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0170] Described herein and Fig. 8A , Figure 8C , Fig.8D and Fig. 8EThe core network entities shown in are identified by the names given to those entities in certain existing 3GPP specifications, but it should be understood that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Fig. 8A , Figure 8B , Figure 8C , Fig.8D and Fig. 8E The specific network entities and functionality described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or defined in the future.

[0171] Figure 8F is a block diagram of an exemplary computing system 90 in which Fig. 8A , Figure 8C , Fig.8D and Fig. 8E One or more devices of the communication network shown in , such as certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112. The computing system 90 may include a computer or a server, and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where such software is stored or accessed, or stored or accessed in any manner. Such computer-readable instructions may be executed within the processor 91 to enable the computing system 90 to work. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0172] In operation, processor 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computing system's primary data transfer path, system bus 80. Such a system bus connects components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0173] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that may not be easily modified. The data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address to a physical address when executing an instruction. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been established, it may not be able to access memory within the virtual address space of another process.

[0174] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for transmitting instructions from the processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0175] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0176] Additionally, computing system 90 may include communications circuitry such as, for example, network adapter 97, which may be used to connect computing system 90 to an external communications network such as Fig. 8A , Figure 8B , Figure 8C , Fig.8D and Fig. 8EThe RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110 or other networks 112) can be used to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuit can be used alone or in combination with the processor 91 to perform the sending and receiving steps of certain devices, nodes or functional entities described herein.

[0177] Figure 8G An example communication system 111 is illustrated, of which the methods and apparatus described and claimed herein may be an aspect. As shown, the example communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, base stations, V2X servers, and RSUs A and B, but it will be appreciated that the present disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or several or all of the WTRUs A, B, C, D, E may be outside the network range (e.g., outside the cell coverage boundary shown by the dashed lines in the figure). WTRUs A, B, C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members. WTRUs A, B, C, D, E, F may communicate over a Uu interface or a sidelink (PC5) interface.

[0178] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassette, tape, disk storage or other magnetic storage device, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computing system.

[0179] definition

[0180] Definitions of abbreviations found in the text of this disclosure are provided below.

[0181]

[0182]

[0183]

Claims

1. A method performed by a data collection enabling service DCES, comprising: receiving a data producer profile of one or more data producers, wherein the data producer profile includes information associated with data generation or production capabilities of the one or more data producers; receiving a first message indicating a request for a data collection, wherein the message includes one or more requirements associated with the data collection; determining one or more data producers for data collection based at least on the received data producer profile and the one or more requirements in the first message; collecting data from the determined one or more data producers; processing the collected data based on the one or more requirements in the first message, thereby generating a data set including the processed data; and The generated data sets are stored in a repository in communication with the DCES.

2. The method of claim 1, wherein: DCES provides data collection services in cellular / 3GPP networks.

3. The method of claim 1, wherein: The data collection services reside in the 3GPP service layer.

4. The method of claim 1, wherein: Data collection services include data analysis services.

5. The method of claim 1, wherein: Data producer profiles are received via a discovery process.

6. The method of claim 1, wherein: The data producer profile also includes data freshness information of the data provided by the corresponding data producer.

7. The method of claim 1, wherein: The data producer profile also includes the data collection schedule or data generation / collection rate supported by the corresponding data producer.

8. The method of claim 1, wherein: The first message includes a data analysis request.

9. The method of claim 1, wherein: The one or more requirements in the first message include filtering criteria of the data producer.

10. The method of claim 1, wherein: The one or more data producers include a service layer entity.

11. The method of claim 1, wherein: The one or more data producers include a 3GPP service layer entity.

12. The method of claim 1, wherein: The one or more data producers include an edge enabler layer entity.

13. The method of claim 1, wherein: The one or more data producers include a data repository entity.

14. The method of claim 1, further comprising: Previously generated data sets are examined to identify data sets that satisfy the one or more requirements in the first message.

15. The method of claim 1, wherein: The processing of data includes associating data from multiple data producers, wherein the data from the multiple data producers are of the same type but have different data granularities.

16. The method of claim 1, wherein: Processing of data also includes combining or aggregating data from multiple data producers.

17. The method of claim 1, wherein: The processing of the data includes modifying or customizing the data from the previously generated data set to meet the one or more requirements in the first message.

18. The method of claim 1, further comprising sending a second message in response to the first message, wherein: The second message includes an identifier of a repository storing the generated data set.

19. The method of claim 1, further comprising maintaining information associated with the generated data set.

Images