INTERNET OF THINGS BASED AIR POLLUTION PREVENTION IN 5TH GENERATION NETWORKS

A network node can be configured to determine analytics associated with a communication device. The network node can determine an identifier associated with a communication device using a characteristic of the communication device. The network node can further transmit a message requesting that the communication device gather and report data. The network node can further, responsive to transmitting the message, receive the data. The network node can further generate the analytics based on the data.

TECHNICAL FIELD

The present disclosure relates generally to communications, and more particularly to communication methods and related devices and nodes supporting wireless communications.

BACKGROUND

FIG.1illustrates an example of a new radio (“NR”) network (e.g., a 5th Generation (“5G”) network) including a 5G core (“5GC”) network130, network node120(e.g., a 5G base station (“gNB”)), multiple communication devices110(also referred to as user equipment (“UE”)).

FIG.2illustrates an example of a reference architecture of a 5GC network130as defined by the 3rd generation partnership project (“3GPP”). In this example, the 5GC network includes a unified data repository (“UDR”)232, a network exposure function (“NEF”)234, a network data analytics function (“NWDAF”)236, an application function (“AF”)238, a policy control function (“PCF”)242, a charging function (“CHF”)244, an access and mobility management function (“AMF”)246, and a session management function (“SMF”)248all communicatively coupled to each other. The 5GC network further includes a user plane function (“UPF”)250communicatively coupled to the SMF248.

The NWDAF236represents an operator managed network analytics logical function. The NWDAF236is part of the 5GC architecture and uses the mechanisms and interfaces specified for 5GC and operations, administration, and maintenance (“OAM”). The NWDAF236interacts with different entities for different purposes including: data collection based on event subscription, provided by the AMF246, the SMF248, the PCF242, a unified data management (“UDM”), the AF238(directly or via the NEF234), and OAM; retrieval of information from data repositories (e.g., UDR232via UDM for subscriber-related information); retrieval of information about network functions (“NFs”) (e.g., NRF for NF-related information, and network slice selection function (“NSSF”) for slice-related information); and on demand provision of analytics to consumers.

The UDR232stores data grouped into distinct collections of subscription-related information: subscription data; policy data; structured data for exposure; and application data.

The PCF242supports a unified policy framework to govern the network behavior. Specifically, the PCF242provides policy and charging control (“PCC”) rules to the policy and charging enforcement function (“PCEF”) (e.g., the SMF/UPF that enforces policy and charging decisions according to provisioned PCC rules).

The AMF246manages UE access (e.g., when UE is connected through different access networks) and UE mobility aspects.

The SMF248supports different functionalities (e.g., SMF248receives PCC rules from the PCF242and configures the UPF250accordingly).

The UPF250supports handling of user plane traffic based on the rules received from the SMF248(e.g., packet inspection and different enforcement actions such as quality of service (“QoS”) handling).

Air pollution in cities is a serious environmental problem, especially in developing countries. The air pollution path of an urban atmosphere includes emission and transmission of air pollutants resulting in ambient air pollution. Each part of the path is influenced by different factors. In some examples, emissions from motor traffic are a significant source group throughout the world. During transmission, air pollutants are dispersed, diluted, and subjected to photochemical reactions.

Some of the major pollutants from motor vehicles include: particulate matter (“PM”); volatile organic compounds (“VOCs”); nitrogen oxide (“NOx”); carbon monoxide (“CO”); sulfur dioxide (“SO2”); and other greenhouse gasses.

One type of particulate matter is the soot seen in vehicle exhaust. Fine particles (e.g., less than one-tenth the diameter of a human hair) pose a serious threat to human health, as they can penetrate deep into the lungs. PM can be a primary pollutant or a secondary pollutant from hydrocarbons, nitrogen oxides, and sulfur dioxides. In some examples, diesel exhaust is a major contributor to PM pollution.

These pollutants react with nitrogen oxides in the presence of sunlight to form ground level ozone, a main ingredient in smog. Though beneficial in the upper atmosphere, at the ground level this gas irritates the respiratory system, causing coughing, choking, and reduced lung capacity. VOCs emitted from cars, trucks and buses, which include the toxic air pollutants benzene, acetaldehyde, and 1,3-butadiene, are linked to different types of cancer.

NOx pollutants form ground level ozone and particulate matter (secondary). Also harmful as a primary pollutant, NOx can cause lung irritation and weaken the body's defenses against respiratory infections such as pneumonia and influenza.

CO is an odorless, colorless, and poisonous gas formed by the combustion of fossil fuels such as gasoline and is emitted primarily from cars and trucks. When inhaled, CO blocks oxygen from the brain, heart, and other vital organs.

Power plants and motor vehicles create SO2 by burning sulfur-containing fuels, especially diesel and coal. Sulfur dioxide can react in the atmosphere to form fine particles and, as other air pollutants, poses the largest health risk to young children and asthmatics.

Motor vehicles also emit greenhouse gasses, predominantly carbon dioxide, that contribute to global climate change. In fact, tailpipe emissions from cars, trucks and buses account for over one-fifth of the United States' total global warming pollution; transportation, which includes and airplanes, trains, and ships accounts for around thirty percent of all heat-trapping gas emissions.

SUMMARY

According to some embodiments, a method performed by a network node for determining analytics associated with a communication device is provided. The method includes determining an identifier associated with a communication device using a characteristic of the communication device. The method further includes transmitting a message requesting that the communication device gather and report data. The method further includes, responsive to transmitting the message, receiving the data. The method further includes generating the analytics based on the data.

Additional embodiments herein describe network nodes, computer programs, and computer program products for performing the operations in the above method embodiments.

Various embodiments described herein allow a network operator to get real-time data and analytics related to vehicle pollution and permit governments and local administrations to make more effective decisions to reduce air pollution.

DETAILED DESCRIPTION

There currently exist certain challenge(s). For example, air pollution in cities is a serious environmental problem and the biggest contributing factor is related to the vehicles' emissions. Governments and local administrations are introducing driving restrictions in large cities. However, air pollution has a big temporal and spatial variability and the current measurements are mostly based on local meteorological stations.

Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

Various embodiments described herein propose a mechanism which solves the above problems and is based on an internet of things (“IoT”) cloud platform (such as the Ericsson IoT platform), hosting an IoT Analytics entity running analytics based on the collected data from one or more of: IoT devices; connected vehicles; 5GC entities; and external entities.

IoT devices include connected vehicles and connected meteorological stations. connected vehicles can provide data, for example, global positioning system (“GPS”) position, vehicle speed, and engine status (e.g., on or off). Connected meteorological stations can provide data, for example, geographical coordinates, air pollution data like levels of PM, VOC, NOx, CO, SO2, and other greenhouse gases.

5GC entities (e.g., an AMF, a UDM/UDR, a NWDAF, and a NEF) can provide network related parameters and analytics.

External entities (e.g., institutions) can provide weather measurements and/or forecasts.

In some embodiments, a type of analytic relative to vehicle pollution is proposed, which allows an external entity (e.g., a government or local administration) to obtain useful data to plan and prevent air pollution in cities.

FIGS.3-4illustrate examples of a 5G network architecture for air pollution prevention.FIG.3illustrates a 5G network including a network node120coupled to a core network130, which is coupled to a data producer380and a consumer390. A roadway having IoT devices (vehicles)314(e.g., cars314a-band trucks314c-d) and an IoT device (meteorological station)312can be within a coverage area of the network node120. In some examples, the vehicles314can each provide information (e.g., vehicle speed) to the core network130via the network node120. In additional or alternative examples, the meteorological station312can measure vehicle pollutants and provide the data to the core network130via the network node120. In additional or alternative examples, the data producer380(e.g., a weather forecaster) can provide additional data (e.g., a weather forecast) to the core network130. The core network130can perform data analytics on the collected data and provide a recommendation for how to handle air pollution to the consumer390.

FIG.4is a block diagram illustrating an example of a 5G network for analyzing or preventing air pollution according to some embodiments. The 5G network can include a pair of IoT devices312,314associated with a meteorological station and a vehicle, respectively. The 5G network can further include a IoT Cloud platform330a,a 5G core network330b,a data producer380, and a consumer390. The IoT devices312,314can each include an application client412,414communicatively coupled to respective application servers462,464in the IoT Cloud platform330athat are each able to communicate data from the IoT devices312,314to the IoT Analytics Entity470. Thereby, IoT devices312,314are examples for communication devices as described herein. The IoT Analytics Entity470can also be coupled to a NEF234, NWDAF236, and/or AMF246in the 5GC330b,which can be coupled to the vehicle314for communicating mobility data from the vehicle314to the IoT Analytics Entity470. The IoT Analytics Entity470can also be communicatively coupled to a UDR232of the 5GC, which can store identifiers associated with the different IoT devices312,314.

In some embodiments, as part of the subscriber data, IoT device subscription parameters are stored in the UDR232. In some examples, the IoT device subscriptions are for vehicles and include a parameter indicating if the IoT device is a vehicle, e.g. for the exemplary IoT device314. If the IoT device is a vehicle, or is associated with a vehicle, it can include parameters including: VehicleType (e.g., Car, Truck, or Bus); VehicleBrand (e.g., Volvo or Toyota); VehicleFuelType (e.g., Diesel, Biodiesel, Gasoline, Hybrid, or Electric); VehicleManufacturingYear (e.g., 2002).

In additional or alternative examples, the IoT device subscriptions are for meteorological stations and include a parameter indicating if the IoT device is a meteorological station (with the capability of measuring vehicle pollutants), e.g. for the exemplary IoT device312. If the IoT device is a meteorological station, the IoT device subscription can include a parameter indicating a location of the IoT device.

A consumer390(e.g., an AF as a government or a local administration) can subscribe to an IoT Analytics entity470related to a new analytic (Analytic-ID=VehiclePollution), by triggering a AnalyticsSubscription_Subscribe Request message including the following parameters. In some examples, the parameters include an Analytic-ID=VehiclePollution. In additional or alternative examples, the parameters include an Analytic-Type=Statistical/Predictive/Both. It requests vehicle pollution analytics based on the analysis of existing data (Statistical) and/or the request is about predictions about the vehicle pollution in the future, based on the analysis of existing data and projections into a target date (Predictive). In additional or alternative examples, the parameters include a list of locations (e.g. a single location like a city: Madrid; or a list of locations within a city: Madrid and the different districts within Madrid: Latina, Moratalaz, Centro, etc). The latter requests to calculate the Analytic-ID for each location (e.g. district). In additional or alternative examples, the parameters include Time-Parameters (e.g., start analytic immediately and report the analytic result periodically on a per daily basis). In additional or alternative examples, the parameters include a list of UE (UE-ID e.g., to track a certain vehicle, UE-Group-ID, e.g. devices from a certain IoT provider). In additional or alternative examples, the parameters include a Vehicle Type (eg., Any, Car, Truck, Bus, etc). In additional or alternative examples, the parameters include a VehicleBrand (e.g., Any, Volvo, Toyota). In additional or alternative examples, the parameters include a VehicleFuelType (e.g., Any, Diesel, Biodiesel, Gasoline, Hybrid, Electric). In additional or alternative examples, the parameters include a VehicleManufacturingYearPeriod (e.g., before 2005). In additional or alternative examples, the parameters include driving restrictions parameters (e.g., on a certain date, there will be a driving restriction for vehicles of certain type).

As an example, an AF (for example associated with local administration) might subscribe to bus pollution for each of the different districts of a certain city, e.g. Madrid.

Based on the above analytic subscription, the IoT Analytics entity470can trigger data collection as follows. In some examples, the IoT Analytics entity470can trigger data collection from UDR/UDM, to retrieve the following data: a list of vehicles matching the requested conditions (VehicleType, VehicleBrand, VehicleFuelType, VehicleManufacturingYearPeriod and inside the requested location); and a list of meteorological stations inside the requested location (e.g., Madrid).

Based on the above, the IoT Analytics entity470can discover any active PDU sessions for the vehicles matching the above conditions (VehicleType, VehicleBrand, VehicleFuelType, VehicleManufacturingYearPeriod and inside the requested location). It is assumed the meteorological stations have always on (active) PDU sessions (in case this is not true, their PDU sessions will also need to be discovered).

In additional or alternative examples, the IoT Analytics entity470can trigger data collection from an AMF, to retrieve the following data for the vehicles matching the above conditions (and passing as input the requested location to filter out vehicles outside the requested location): Mobility and trajectory.

In additional or alternative examples, the IoT Analytics entity470can trigger data collection from the IoT (communication) device (either from an application client or from an application server) to retrieve the following data. From the vehicles matching the above conditions (e.g. VehicleType, VehicleBrand, VehicleFuelType, VehicleManufacturingYearPeriod, within the requested location and with active PDU sessions), vehicle statistics like GPS positions and timestamps, Vehicle speed, and Engine ON/OFF can be retrieved. From the meteorological stations inside the requested location, Meteorological station data (e.g., Geographical coordinates, air pollution data like levels of PM (Particulate matter), VOC (Volatile Organic Compounds), NOx (Nitrogen oxides), CO (Carbon monoxide), SO2 (Sulfur dioxide), Greenhouse gases) can be retrieved.

In additional or alternative examples, the IoT Analytics entity470can trigger data collection from external entities (e.g., to collect the weather forecast) in order to improve analytics result and optionally send a recommendation (e.g., if the weather forecast for the following days is rainy, the vehicle restrictions to be planned for those days might be relaxed).

Based on the data collected above, the IoT Analytics entity runs analytic processes (e.g., by using Machine Learning, by identifying patterns or behaviors among the vehicles of certain characteristics and/or by correlating data from the vehicles and the meteorological stations, etc) and generates the Analytic-Result, including the following information: Analytic-ID=VehiclePollution; PollutionMap (which includes at each geographical coordinate, an intensity level (e.g. from white to black in grey scales) which will be based on 1) number of target vehicles passing through that geographical coordinate, 2) time spent by target vehicles at that geographical coordinate (e.g., vehicle stopped due to traffic light or traffic jam), having into account vehicle data like Engine ON/OFF (e.g. in case a vehicle turns off the engine while stopped at a traffic light or traffic jam), and 3) vehicle speed when passing through that geographical coordinate (as emissions depend on the vehicle speed); prediction on vehicle pollution (e.g., based on historical data from previous analytic results) showing the future projection; List of locations with higher vehicle pollution; List of vehicles (UE-IDs) or vehicle types which contribute the most to the Vehicle pollution; statistics (on a per time period, e.g., weekdays vs weekend) on percentage of vehicles of a certain type (e.g. Car, Truck, Bus), brand (e.g., Volvo, Toyota), fuel type (Diesel, Biodiesel, Gasoline, Hybrid, Electric), manufacturing year (e.g., before 2005), etc; and recommendation actions (e.g., possible vehicle restrictions to apply by the consumer).

Based on the Analytic-Result, the Consumer (e.g., AF as a government or local administration) applies the corresponding actions (e.g., planning relative to vehicle restrictions on a per district basis). Such actions may relate to imposing restrictions to pollution sources, for example to restrict access to certain areas or particular streets for vehicles of a certain type (e.g. trucks, vehicles with Diesel engines, all motor vehicles except electric-driven vehicles, and/or vehicles assigned to a certain emission class), to impose speed limits in certain areas or streets, to certain types of vehicles or the like. This may also include restrictions to non-mobile pollution sources like power plants or manufacturing sites. Further, such actions may relate to reducing exposure of persons to polluting agents, like guiding pedestrian streams around areas of higher pollution, or perform protective measures on buildings, like closing of windows, activation of filter appliances or the like. The type and extent of actions can be based on parameters used or created in the analytic process, like type of pollutant(s), pollution map or location etc.

Various embodiments described herein propose a mechanism which allows the network operator to support government and administrations to prevent pollution in cities, based on IoT and Analytics in 5G networks.

Certain embodiments may provide one or more of the following technical advantage(s). The most relevant advantages of the proposed innovation include that some embodiments allow the network operator to get real time data and analytics related to vehicle pollution in cities, as a powerful tool allowing governments and local administrations to take the best decisions to fight against air pollution.

Various embodiments herein include determining an analytic relative to vehicle pollution, which allows an external entity acting as consumer (e.g., a government or a local administration) to obtain useful data to plan and prevent air pollution in cities.

In some embodiments, an IoT Analytics entity470(e.g., hosted in the IoT Cloud Platform330aofFIG.4) produces the analytic. In additional or alternative embodiments, a NWDAF produces the analytic.

Not shown in the sequence diagram ofFIG.5, but it is also possible that the IoT Analytics entity470also triggers data collection from external entities (e.g. to collect the weather forecast) in order to improve analytics result and optionally send a recommendation (e.g. if the weather forecast for the following days is rainy, the vehicle restrictions to be planned for those days might be relaxed).

Finally, the analytic result (e.g., as a pollution heat map) is based on the UEs resp. communication devices camping on operator's mobile network (with respect to the UEs camping on other mobile networks in the same location, or with respect to UEs not connected to any mobile network, e.g. not IoT enabled). In any case, the data is assumed to be statistically relevant and it might be further sampled (i.e. the IoT Analytics entity does not need to collect data from all the mobile network connected vehicles in the target location).

Operations of a NWDAF236are illustrated inFIG.5and described below. In these embodiments, the NWDAF236is the entity producing the analytic. As a precondition, as part of the subscriber data, the following parameters are stored in the UDR232: IoT device subscriptions (Vehicles); and IoT device subscriptions (Meteorological stations). The IoT device subscriptions can indicate whether the IoT device is a vehicle. If yes, the IoT device subscription may further indicate a VehicleType (e.g., Car, Truck, Bus, etc), a VehicleBrand (e.g., Volvo, Toyota), a VehicleFuelType (e.g., Diesel, Biodiesel, Gasoline, Hybrid, Electric), and a VehicleManufacturingYear (e.g., 2002). The IoT device subscriptions (can indicate whether the IoT is a meteorological station (with the capability of measuring vehicle pollutants). If yes, the IoT device subscription may further indicate a location of the meteorological station.

At block505, consumer390(e.g., an AF associated with a government or a local administration) subscribes to the NWDAF236related to a new analytic (Analytic-ID=VehiclePollution), by, at block510, transmitting a Nnwdaf_AnalyticsSubscription_Subscribe Request message including the following parameters. In some examples, the parameters include an Analytic-ID=VehiclePollution. In additional or alternative examples, the parameters include an Analytic-Type=Statistical/Predictive/Both. It requests vehicle pollution analytics based on the analysis of existing data (Statistical) and/or the request is about predictions about the vehicle pollution in the future, based on the analysis of existing data and projections into a target date (Predictive). In additional or alternative examples, the parameters include a list of locations (e.g. a single location like a city: Madrid; or a list of locations within a city: Madrid and the different districts within Madrid: Latina, Moratalaz, Centro, etc). The latter requests to calculate the Analytic-ID for each location (e.g. district). In additional or alternative examples, the parameters include Time-Parameters (e.g., start analytic immediately and report the analytic result periodically on a per daily basis). In additional or alternative examples, the parameters include a list of UE (UE-ID e.g., to track a certain vehicle, UE-Group-ID, e.g. devices from a certain IoT provider). In additional or alternative examples, the parameters include a VehicleType (eg., Any, Car, Truck, Bus, etc). In additional or alternative examples, the parameters include a VehicleBrand (e.g., Any, Volvo, Toyota). In additional or alternative examples, the parameters include a VehicleFuelType (e.g., Any, Diesel, Biodiesel, Gasoline, Hybrid, Electric). In additional or alternative examples, the parameters include a VehicleManufacturingYearPeriod (e.g., before 2005). In additional or alternative examples, the parameters include driving restrictions parameters (e.g., on a certain date, there will be a driving restriction for vehicles of certain type).

In the example shown in the sequence diagram ofFIG.5, the AF (local administration) can subscribe to truck pollution for the city of Madrid.

At block515, the NWDAF236answers the request message (from block510) with a successful response (accepting the request).

At block520, the NWDAF236triggers data collection from the UDR232/UDM. In the sequence diagram ofFIG.5, data collection from the232UDR is shown. In this example, the NWDAF236requests from the UDR232a list of UE-IDs for both the target vehicles and target meteorological stations (UE110) in the target location.

Although not shown in the sequence diagram ofFIG.5, it is also possible to collect data from a UDM (which stores data for active PDU sessions).

At block525, the NWDAF236transmits a Nudr_Query request message referring to the UE110. In some examples, the Nudr_Query request message indicates a VehicleType=Truck, and Location=Madrid as input parameters. In other examples, the Nudr_Query request message indicates MeteoStations and Location=Madrid as input parameters.

At block530, the UDR232finds the UE-IDs matching the input parameters in the request and transmits a Nudr_Query response including the list of UE-IDs. (e.g., Trucks in Madrid or MeteoStations in Madrid).

At blocks535, for each of the UE-IDs in the list retrieved above, the NWDAF236discovers the AMF246serving the PDU session and triggers data collection from the AMF236(for the target vehicles and/or target meteorological station). In order to do this, at block540, the NWDAF236transmits a Namf_Event Exposure Subscribe Request including as parameters: Event-ID=Mobility, Trajectory (e.g. as a single event for simplicity in this example, but in general these are two separate events); UE-ID; and Location=Madrid.

At block545, if the UE-ID is in the target location, the AMF246tracks its mobility and trajectory, and reports it in a Namf_Event Exposure Notification Request including as parameters: Event-ID=Mobility, Trajectory; UE-ID; and MobilityTrajectoryInfo.

At blocks550and555, for each of the UE-IDs (vehicles and/or meteorological stations) in the list retrieved above (the ones inside the target location), the NWDAF236triggers data collection from the UE110. In order to do this for vehicle data, the NWDAF236triggers a Nue_EventExposure_Subscribe request message including the following parameters: Event-ID=VehicleData; UE-ID. In order to do this for meteorological station data, the NWDAF236triggers a Nue_EventExposure_Subscribe request message including the following parameters: Event-ID=MeteoStationData; and UE-ID.

At blocks560and565, the UE110starts gathering data (e.g. a vehicle may gather data for Event-ID=VehicleData) and answers the request message in block555with a successful response (accepting the request).

At blocks570and575, the UE110sends (e.g., periodically) data. In some examples, a vehicle may transmit data for Event-ID=VehicleData by triggering a Nue_EventExposure_Notify request including the following parameters: Event-ID=VehicleData; UE-ID; and VehicleData (e.g., GPS positions and timestamps, Vehicle speed, Engine ON/OFF, etc). In some examples, a Meteo Station sends (e.g. periodically) data for Event-ID=MeteoStationData by triggering a Nue_EventExposure_Notify request including the following parameters: Event-ID=MeteoStationData; UE-ID; and MeteostationData, e.g. Geographical coordinates, air pollution data like levels of PM (Particulate matter), VOC (Volatile Organic Compounds), NOx (Nitrogen oxides), CO (Carbon monoxide), SO2 (Sulfur dioxide), Greenhouse gases, etc.

At block585, the NWDAF236produces analytics based on the data collected from the UDR232/UDM, the AMF246, and the UE110. Specifically, the NWDAF236runs analytic processes (e.g., by using Machine Learning, by identifying patterns or behaviors among the vehicles of certain characteristics and/or by correlating data from the vehicles and the meteorological stations, etc) and generates the information. The information can include an Analytic-ID=VehiclePollution and an Analytic-Result. The Analytic-Result can include a PollutionMap (of the target location, e.g. Madrid), which includes at each geographical coordinate, an intensity level (e.g. from white to black in grey scales) which will be based on: 1) a number of target vehicles (trucks) passing through that geographical coordinate, 2) a time spent by target vehicles (trucks) at that geographical coordinate (e.g. vehicle stopped due to traffic light or traffic jam), having into account vehicle data like Engine ON/OFF (e.g. in case a vehicle turns off the engine while stopped at a traffic light or traffic jam), and 3) a vehicle speed when passing through that geographical coordinate (as emissions depend on the vehicle speed). The Analytic-Result can further include a prediction on vehicle pollution (e.g. based on historical data from previous analytic results) showing the future projection. Optionally, a confidence level (e.g. a percentage from 0% to 100%). The Analytic-Result can further include a list of locations with higher vehicle pollution, a list of vehicles (UE-IDs) or vehicle types which contribute the most to the Vehicle pollution, and statistics (on a per time period, e.g. weekdays vs weekend) on percentage of vehicles of a certain type (e.g. Car, Truck, Bus), brand (e.g. Volvo, Toyota), fuel type (Diesel, Biodiesel, Gasoline, Hybrid, Electric), manufacturing year (e.g. before 2005), etc.

At blocks590and595, the NWDAF236can provide the Analytic-Result to the consumer390. At block598, the consumer390(e.g., an AF as a government or local administration) applies the corresponding actions (e.g., planning relative to vehicle restrictions).

An IoT Analytics based innovation is described below.

A new IoT Analytics entity (hosted in the IoT Cloud Platform) is the one producing the analytic.FIG.6illustrates a sequence diagram describing the proposed mechanism. As a precondition, as part of the subscriber data, the following parameters are stored in the UDR232: IoT device subscriptions (Vehicles); and IoT device subscriptions (Meteorological stations). The IoT device subscriptions can indicate whether the IoT device is a vehicle. If yes, the IoT device subscription may further indicate a VehicleType (e.g., Car, Truck, Bus, etc), a VehicleBrand (e.g., Volvo, Toyota), a VehicleFuelType (e.g., Diesel, Biodiesel, Gasoline, Hybrid, Electric), and a VehicleManufacturingYear (e.g., 2002). The IoT device subscriptions (can indicate whether the IoT is a meteorological station (with the capability of measuring vehicle pollutants). If yes, the IoT device subscription may further indicate a location of the meteorological station.

FIG.6illustrates an example of a signal flow diagram including an IoT Analytics entity470that determines vehicle pollution analytics based on information from multiple UEs (e.g., UE314associated with a vehicle and UE312associated with a meteorological station).

At block602and604, consumer390(e.g., an AF associated with a government or a local administration) subscribes to IoT analytics entity470(hosted in the IoT Cloud Platform) related to a new analytic (Analytic-ID=VehiclePollution), by transmitting an AnalyticsSubscription_Subscribe Request message to the IoT analytics entity470. In some examples, the AnalyticsSubscription_Subscribe Request message can include one or more of the following parameters: an analytic ID; an analytic type; a location; a time parameter; a list of UEs; a vehicle type; a vehicle brand; a vehicle fuel type; a vehicle manufacturing year/period; and driving restriction parameters.

The analytic ID (which can be referred to as an Analytic-ID) can be “VehiclePollution.”

The analytic type (which can be referred to as Analytic-Type) can be set to statistical, predictive, or both. A statistical analytic type can refer to a request for vehicle pollution analytics based on the analysis of existing data. A predictive analytic type can refer to a request for predictions about the vehicle pollution in the future based on the analysis of existing data and projections into a target date.

The list of locations can include, for example, a single location like a city: Madrid; or a list of locations within a city: Madrid and the different districts within Madrid: Latina, Moratalaz, Centro. The latter requests to calculate the Analytic-ID for each location (e.g. district). In the example shown in the sequence diagram ofFIG.6, Location=Madrid.

The Time-Parameters can indicate to start analytic immediately and to report the analytic result periodically on a per daily basis.

A list of UE can include, for example, a UE-ID to track a certain vehicle or UE-Group-ID to track devices from a certain IoT provider. In the example shown in the sequence diagram ofFIG.6, this parameter is not present.

The VehicleType can include, for example, Any, Car, Truck, Bus, etc. In the example shown in the sequence diagram ofFIG.6, VehicleType=Truck.

The VehicleBrand can include, for example, Any, Volvo, Toyota. In the example shown in the sequence diagram ofFIG.6, this parameter is not present.

The VehicleFuelType can include, for example, Any, Diesel, Biodiesel, Gasoline, Hybrid, Electric. In the example shown in the sequence diagram ofFIG.6, this parameter is not present.

The VehicleManufacturingYearPeriod can include, for example, before 2005. In the example shown in the sequence diagram ofFIG.6, this parameter is not present.

The driving restrictions parameters can include, for example, on a certain date, there will be a driving restriction for vehicles of certain type. In the example shown in the sequence diagram ofFIG.6, this parameter is not present.

In the example shown in the sequence diagram ofFIG.6, AF (local administration) subscribes to truck pollution for the city of Madrid.

At block606, the IoT Analytics entity470answers the request message from block604with a successful response (accepting the request).

At block608, the IoT Analytics entity470triggers data collection from the UDR232/UDM. In the sequence diagram ofFIG.6, data collection from the UDR232is shown. In this case, IoT Analytics entity470requests the UDR232for the list of UE-IDs for both the target vehicles314and target meteorological stations312in the target location. In this example, it is assumed the IoT Analytics entity470is trusted, so it does not need to interact with the 5GC entities (e.g., the UDR232) through NEF.

Not shown in the sequence diagram ofFIG.6, but it is also possible to collect data from a UDM (which stores data for active PDU sessions).

At block612, the IoT Analytics entity470triggers a Nudr_Query request message indicating VehicleType=Truck, and Location=Madrid as input parameters.

At block614, the UDR232finds the UE-IDs matching the input parameters in the request and transmits a Nudr_Query response including the list of UE-IDs (Trucks in Madrid).

At block616, the IoT Analytics entity470triggers a Nudr_Query request message indicating MeteoStations and Location=Madrid as input parameters.

At block618, the UDR232finds the UE-IDs matching the input parameters in the request and transmits a Nudr_Query response including the list of UE-IDs (MeteoStations in Madrid).

At block622, for each of the UE-IDs in the list retrieved, the IoT Analytics entity470discovers the AMF246serving the PDU session and, at block628, triggers data collection from the AMF246(for the target vehicles314). In order to do this, at block624, the IoT Analytics entity470triggers a Namf_Event Exposure Subscribe Request including as parameters: Event-ID=Mobility, Trajectory (e.g. as a single event for simplicity in this example, but in general these are two separate events); UE-ID; and Location=Madrid.

At block626, if the UE-ID is in the target location, AMF tracks its mobility and trajectory, and reports it in a Namf_Event Exposure Notification Request including as parameters: Event-ID=Mobility, Trajectory; UE-ID; and MobilityTrajectoryInfo.

At blocks628, for each of the UE-IDs (vehicles) in the list retrieved (the ones inside the target location), IoT Analytics entity470triggers data collection from Vehicle AS464, specifically to retrieve Vehicle data. In order to do this, IoT Analytics entity470transmits, at block632, a Naf_EventExposure_Subscribe request message including the following parameters: Event-ID=VehicleData; and UE-ID.

At block634the AS (vehicle)464instruct the UE (Vehicle)314to start gathering data for Event-ID=VehicleData and, at block636, answers the request message with a successful response (accepting the request).

At block638, for each of the UE-IDs (Meteorological Stations) in the list retrieved (the ones inside the target location), IoT Analytics entity470triggers data collection from Meteo Station AS462, specifically to retrieve Meteorological Station data. In order to do this, IoT Analytics entity470transmits, at block642, a Naf_EventExposure_Subscribe request message including the following parameters: Event-ID=MeteoStationData; and UE-ID.

At block644, the AS (Meteo)462instructs the UE (Meteo)312to start

gathering data for Event-ID=MeteoStationData and, at block646, answers the request message with a successful response (accepting the request).

At blocks648and652, the AS (Vehicle)464sends (e.g. periodically) data for Event-ID=VehicleData, previously obtained from Application client at UE (Vehicle)314, by triggering a Naf_EventExposure_Notify request including the following parameters: Event-ID=VehicleData; UE-ID; and VehicleData (e.g. GPS positions and timestamps, Vehicle speed, Engine ON/OFF, etc). At block654, the IoT Analytics entity470transmits a response acknowledging the data.

At blocks656and658, the AS (Meteo Station)462sends (e.g., periodically) data for Event-ID=MeteoStationData, previously obtained from Application client at UE (Meteo Station)312, by triggering a Naf_EventExposure_Notify request including the following parameters: Event-ID=MeteoStationData; UE-ID; and MeteostationData, e.g. Geographical coordinates, air pollution data like levels of PM (Particulate matter), VOC (Volatile Organic Compounds), NOx (Nitrogen oxides), CO (Carbon monoxide), SO2 (Sulfur dioxide), Greenhouse gases, etc. At block662, the IoT Analytics entity470transmits a response acknowledging the data.

At blocks664, the IoT Analytics entity470produces analytics based on the data collected from UDR232/UDM, AMF246and AS462,464/AF (Vehicle and Meteo Station). Specifically, the NWDAF236runs analytic processes (e.g., by using Machine Learning, by identifying patterns or behaviors among the vehicles of certain characteristics and/or by correlating data from the vehicles and the meteorological stations, etc) and generates the information. The information can include an Analytic-ID=VehiclePollution and an Analytic-Result. The Analytic-Result can include a PollutionMap (of the target location, e.g. Madrid), which includes at each geographical coordinate, an intensity level (e.g. from white to black in grey scales) which will be based on: 1) a number of target vehicles (trucks) passing through that geographical coordinate, 2) a time spent by target vehicles (trucks) at that geographical coordinate (e.g. vehicle stopped due to traffic light or traffic jam), having into account vehicle data like Engine ON/OFF (e.g. in case a vehicle turns off the engine while stopped at a traffic light or traffic jam), and 3) a vehicle speed when passing through that geographical coordinate (as emissions depend on the vehicle speed). The Analytic-Result can further include a prediction on vehicle pollution (e.g. based on historical data from previous analytic results) showing the future projection. Optionally, a confidence level (e.g. a percentage from 0% to 100%). The Analytic-Result can further include a list of locations with higher vehicle pollution, a list of vehicles (UE-IDs) or vehicle types which contribute the most to the Vehicle pollution, and statistics (on a per time period, e.g. weekdays vs weekend) on percentage of vehicles of a certain type (e.g. Car, Truck, Bus), brand (e.g. Volvo, Toyota), fuel type (Diesel, Biodiesel, Gasoline, Hybrid, Electric), manufacturing year (e.g. before 2005), etc.

At blocks666and668, the IoT analytics entity470can provide the Analytic-Result to the consumer390. At block698, the consumer390(e.g., an AF as a government or local administration) applies the corresponding actions (e.g., planning relative to vehicle restrictions).

FIG.7is a block diagram illustrating elements of a communication device700(also referred to as a mobile terminal, a mobile communication terminal, a wireless device, a wireless communication device, a wireless terminal, mobile device, a wireless communication terminal, user equipment (“UE”), a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of inventive concepts. Communication device700may be provided, for example, as discussed below with respect to wireless devices UE1112A, UE1112B, and wired or wireless devices UE1112C, UE1112D ofFIG.11, UE1200ofFIG.12, virtualization hardware1504and virtual machines1508A,1508B ofFIG.15, and UE1606ofFIG.16, all of which should be considered interchangeable in the examples and embodiments described herein and be within the intended scope of this disclosure, unless otherwise noted. As shown, communication device UE may include an antenna707(e.g., corresponding to antenna1222ofFIG.12), and transceiver circuitry701(also referred to as a transceiver, e.g., corresponding to interface1212ofFIG.12having transmitter1218and receiver1220) including a transmitter and a receiver configured to provide uplink and downlink radio communications with a base station(s) (e.g., corresponding to network node1110A,1110B ofFIG.11, network node1300ofFIG.13, and network node1604ofFIG.16also referred to as a RAN node) of a radio access network. Communication device700may also include processing circuitry703(also referred to as a processor, e.g., corresponding to processing circuitry1202ofFIG.12, and control system1512ofFIG.15) coupled to the transceiver circuitry, and memory circuitry705(also referred to as memory, e.g., corresponding to memory1210ofFIG.11) coupled to the processing circuitry703. The memory circuitry705may include computer readable program code that when executed by the processing circuitry703causes the processing circuitry703to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry703may be defined to include memory so that separate memory circuitry is not required. Communication device700may also include an interface (such as a user interface) coupled with processing circuitry703, and/or communication device700may be incorporated in a vehicle.

As discussed herein, operations of communication device700may be performed by processing circuitry703and/or transceiver circuitry701. For example, processing circuitry703may control transceiver circuitry701to transmit communications through transceiver circuitry701over a radio interface to a radio access network node (also referred to as a base station) and/or to receive communications through transceiver circuitry701from a RAN node over a radio interface. Moreover, modules may be stored in memory circuitry705, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry703, processing circuitry703performs respective operations. According to some embodiments, a communication device700and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines.

FIG.8is a block diagram illustrating elements of a radio access network (“RAN”) node800(also referred to as a network node, base station, eNodeB/eNB, gNodeB/gNB, etc.) of a RAN configured to provide cellular communication according to embodiments of inventive concepts. (RAN node800may be provided, for example, as discussed below with respect to network node1110A,1110B ofFIG.11, network node1300ofFIG.13, hardware1504or virtual machine1508A,1508B ofFIG.15, and/or base station1604ofFIG.16, all of which should be considered interchangeable in the examples and embodiments described herein and be within the intended scope of this disclosure, unless otherwise noted.) As shown, the RAN node may include transceiver circuitry801(also referred to as a transceiver, e.g., corresponding to portions of RF transceiver circuitry1312and radio front end circuitry1318ofFIG.13) including a transmitter and a receiver configured to provide uplink and downlink radio communications with mobile terminals. The RAN node may include network interface circuitry807(also referred to as a network interface, e.g., corresponding to portions of communication interface1306ofFIG.13) configured to provide communications with other nodes (e.g., with other base stations) of the RAN and/or core network CN. The RAN node800may also include processing circuitry803(also referred to as a processor, e.g., corresponding to processing circuitry1302ofFIG.13) coupled to the transceiver circuitry, and memory circuitry805(also referred to as memory, e.g., corresponding to memory1304ofFIG.13) coupled to the processing circuitry803. The memory circuitry805may include computer readable program code that when executed by the processing circuitry803causes the processing circuitry803to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry803may be defined to include memory so that a separate memory circuitry is not required.

As discussed herein, operations of the RAN node800may be performed by processing circuitry803, network interface807, and/or transceiver801. For example, processing circuitry803may control transceiver801to transmit downlink communications through transceiver801over a radio interface to one or more mobile terminals UEs and/or to receive uplink communications through transceiver801from one or more mobile terminals UEs over a radio interface. Similarly, processing circuitry803may control network interface807to transmit communications through network interface807to one or more other network nodes and/or to receive communications through network interface from one or more other network nodes. Moreover, modules may be stored in memory805, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry803, processing circuitry803performs respective operations. According to some embodiments, RAN node800and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines.

According to some other embodiments, a network node may be implemented as a core network CN node without a transceiver. In such embodiments, transmission to a wireless communication device may be initiated by the network node so that transmission to the wireless communication device is provided through a network node including a transceiver (e.g., through a base station or RAN node). According to embodiments where the network node is a RAN node including a transceiver, initiating transmission may include transmitting through the transceiver.

FIG.9is a block diagram illustrating elements of a core network (“CN”) node900(e.g., an SMF (session management function) node, an AMF (access and mobility management function) node, etc.) of a communication network configured to provide cellular communication according to embodiments of inventive concepts. (CN node900may be provided, for example, as discussed below with respect to core network node1108ofFIG.11, hardware1504or virtual machine1508A,1508B ofFIG.15, all of which should be considered interchangeable in the examples and embodiments described herein and be within the intended scope of this disclosure, unless otherwise noted). As shown, the CN node900may include network interface circuitry907configured to provide communications with other nodes of the core network and/or the RAN. The CN node900may also include a processing circuitry903(also referred to as a processor,) coupled to the network interface circuitry, and memory circuitry905(also referred to as memory) coupled to the processing circuitry903. The memory circuitry905may include computer readable program code that when executed by the processing circuitry903causes the processing circuitry903to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry903may be defined to include memory so that a separate memory circuitry is not required.

As discussed herein, operations of the CN node900may be performed by processing circuitry903and/or network interface circuitry907. For example, processing circuitry903may control network interface circuitry907to transmit communications through network interface circuitry907to one or more other network nodes and/or to receive communications through network interface circuitry from one or more other network nodes. Moreover, modules may be stored in memory905, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry903, processing circuitry903performs respective operations. According to some embodiments, CN node900and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines.

In the description that follows, while the network node may be any of the CN node900, core network node1108, hardware1504, or virtual machine1508A,1508B, the CN node900shall be used to describe the functionality of the operations of the network node. Operations of the CN node900(implemented using the structure ofFIG.9) will now be discussed with reference to the flow chart ofFIGS.10-11according to some embodiments of inventive concepts. For example, modules may be stored in memory905ofFIG.9, and these modules may provide instructions so that when the instructions of a module are executed by respective CN node processing circuitry903, processing circuitry903performs respective operations of the flow chart.

FIG.10illustrates operations performed by a network node for determining analytics associated with a communication device. In some embodiments, the network node includes an internet of things, IoT, analytics entity. In additional or alternative embodiments, the network node includes a node configured to perform a network data analytics function, NWDAF.

At block1010, processing circuitry903receives, via network interface907, a request for the analytics associated with an issue from a device associated with a consumer.

At block1020, processing circuitry903determines an identifier associated with a communication device using a characteristic of the communication device. In some embodiments, determining the identifier associated with the communication device includes transmitting a request for the identifier to a unified data repository, UDR, the request including an indication of the characteristic; and responsive to transmitting the request for the identifier to the UDR, receiving the identifier. In additional or alternative embodiments, the characteristic includes at least one of: whether the communication device is associated with a vehicle, whether the communication device is associated with an information gathering station, a location of the communication device, a vehicle type, a vehicle brand, a vehicle fuel type, and vehicle manufacturing year, a time spent by the vehicle at the location, and a vehicle speed.

At block1030, processing circuitry903transmits, via network interface907, an indication of the identifier to an AMF.

At block1040, processing circuitry903receives, via network interface907, mobility information and trajectory information associated with the communication device from the AMF.

At block1050, processing circuitry903transmits, via network interface907, a message requesting that the communication device gather and report data. In some embodiments, transmitting the message requesting that the communication device gather and report data includes, responsive to determining the identifier, transmitting the message directly to the communication device. In additional or alternative embodiments, transmitting the message requesting that the communication device gather and report data includes responsive to determining the identifier, transmitting the message to the communication device via an application server, AS, associated with the communication device.

In additional or alternative embodiments, transmitting the message requesting that the communication device gather and report data includes transmitting a subscription message requesting that the communication device periodically report the data.

At block1060, processing circuitry903receives, via network interface907, the data. In some embodiments, receiving the data includes receiving the data directly from the communication device. In additional or alternative embodiments, receiving the data includes receiving the data from the AS

At block1070, processing circuitry903generates the analytics. In some embodiments, generating the analytics includes generating the analytics based on the data, the mobility information, and the trajectory information. In additional or alternative embodiments, generating the analytics includes generating at least one of: statistical analytics; and predictive analytics. In additional or alternative embodiments, generating the analytics includes generating the analytics using a machine learning algorithm.

At block1080, processing circuitry903transmits, via network interface907, the analytics to the device.

In some embodiments, the issue includes vehicle pollution. The communication device includes a first communication device and a second communication device, the first communication device associated with a vehicle and the second communication device associated with a meteorological station. The data includes first data from the first communication device indicating a location of the vehicle and second data from the second communication device indicating an amount of air pollution at the location.

In additional or alternative embodiments, generating the analytics includes generating statistical information associating the air pollution with the vehicle.

In additional or alternative embodiments, generating the analytics includes generating predictive information estimating air pollution at the location at a future time in response to a potential restriction on vehicles.

Various operations from the flow chart ofFIG.10may be optional with respect to some embodiments of CN nodes and related methods. For example, operations of blocks1010,1030,1040,1060, and1080ofFIG.10may be optional.

FIG.11shows an example of a communication system1100in accordance with some embodiments.

In the example, the communication system1100includes a telecommunication network1102that includes an access network1104, such as a radio access network (RAN), and a core network1106, which includes one or more core network nodes1108. The access network1104includes one or more access network nodes, such as network nodes1110aand1110b(one or more of which may be generally referred to as network nodes1110), or any other similar 3rdGeneration Partnership Project (3GPP) access node or non-3GPP access point. The network nodes1110facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs1112a,1112b,1112c,and1112d(one or more of which may be generally referred to as UEs1112) to the core network1106over one or more wireless connections.

The UEs1112may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes1110and other communication devices. Similarly, the network nodes1110are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs1112and/or with other network nodes or equipment in the telecommunication network1102to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network1102.

In the context of the analytics functionality described above, the UEs1112may particularly correspond to any of the mentioned IoT devices, like IoT Device (Meteo)/UE (Meteo)312or IoT Device (Vehicle)/UE (Vehicle)314ofFIG.4or6, or UE110ofFIG.5.

In the depicted example, the core network1106connects the network nodes1110to one or more hosts, such as host1116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network1106includes one more core network nodes (e.g., core network node1108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node1108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF). In the context of the analytics functionality described above, core network node1108may particularly correspond to one or more of AMF246, UDR232, NEF234or NWDAF236ofFIG.4,5or6.

The host1116may be under the ownership or control of a service provider other than an operator or provider of the access network1104and/or the telecommunication network1102, and may be operated by the service provider or on behalf of the service provider. The host1116may host a variety of applications to provide one or more service. Examples of such applications include data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. In the context of the analytics functionality described above, host1116may particularly correspond to the IoT Cloud Platform330aofFIG.4or one of its components, like AS (Meteo)462, AS (Vehicle)464or IoT Analytics Entity470ofFIG.4orFIG.6. It may also correspond to Data Producer380ofFIG.4or Consumer390ofFIG.4,5or6.

In some examples, the telecommunication network1102is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network1102may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network1102. For example, the telecommunications network1102may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive IoT services to yet further UEs. In some examples, the UEs1112are configured to transmit and/or receive

In the example, the hub1114communicates with the access network1104to facilitate indirect communication between one or more UEs (e.g., UE1112cand/or1112d) and network nodes (e.g., network node1110b). In some examples, the hub1114may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub1114may be a broadband router enabling access to the core network1106for the UEs. As another example, the hub1114may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes1110, or by executable code, script, process, or other instructions in the hub1114. As another example, the hub1114may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub1114acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices.

The hub1114may have a constant/persistent or intermittent connection to the network node1110b.The hub1114may also allow for a different communication scheme and/or schedule between the hub1114and UEs (e.g., UE1112cand/or1112d), and between the hub1114and the core network1106. In other examples, the hub1114is connected to the core network1106and/or one or more UEs via a wired connection. Moreover, the hub1114may be configured to connect to an M2M service provider over the access network1104and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes1110while still connected via the hub1114via a wired or wireless connection.

The UE1200includes processing circuitry1202that is operatively coupled via a bus1204to an input/output interface1206, a power source1208, a memory1210, a communication interface1212, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown inFIG.12. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

The processing circuitry1202is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory1210. The processing circuitry1202may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry1202may include multiple central processing units (CPUs).

In some embodiments, the power source1208is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source1208may further include power circuitry for delivering power from the power source1208itself, and/or an external power source, to the various parts of the UE1200via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source1208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source1208to make the power suitable for the respective components of the UE1200to which power is supplied.

The memory1210may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory1210includes one or more application programs1214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data1216. The memory1210may store, for use by the UE1200, any of a variety of various operating systems or combinations of operating systems.

The processing circuitry1202may be configured to communicate with an access network or other network using the communication interface1212. The communication interface1212may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna1222. The communication interface1212may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter1218and/or a receiver1220appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter1218and receiver1220may be coupled to one or more antennas (e.g., antenna1222) and may share circuit components, software or firmware, or alternatively be implemented separately.

The network node1300includes a processing circuitry1302, a memory1304, a communication interface1306, and a power source1308. The network node1300may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node1300comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node1300may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory1304for different RATs) and some components may be reused (e.g., a same antenna1310may be shared by different RATs). The network node1300may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node1300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node1300.

The processing circuitry1302may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node1300components, such as the memory1304, to provide network node1300functionality.

In some embodiments, the processing circuitry1302includes a system on a chip (SOC). In some embodiments, the processing circuitry1302includes one or more of radio frequency (RF) transceiver circuitry1312and baseband processing circuitry1314. In some embodiments, the radio frequency (RF) transceiver circuitry1312and the baseband processing circuitry1314may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry1312and baseband processing circuitry1314may be on the same chip or set of chips, boards, or units.

The memory1304may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry1302. The memory1304may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry1302and utilized by the network node1300. The memory1304may be used to store any calculations made by the processing circuitry1302and/or any data received via the communication interface1306. In some embodiments, the processing circuitry1302and memory1304is integrated.

The communication interface1306is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface1306comprises port(s)/terminal(s)1316to send and receive data, for example to and from a network over a wired connection. The communication interface1306also includes radio front-end circuitry1318that may be coupled to, or in certain embodiments a part of, the antenna1310. Radio front-end circuitry1318comprises filters1320and amplifiers1322. The radio front-end circuitry1318may be connected to an antenna1310and processing circuitry1302. The radio front-end circuitry may be configured to condition signals communicated between antenna1310and processing circuitry1302. The radio front-end circuitry1318may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry1318may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters1320and/or amplifiers1322. The radio signal may then be transmitted via the antenna1310. Similarly, when receiving data, the antenna1310may collect radio signals which are then converted into digital data by the radio front-end circuitry1318. The digital data may be passed to the processing circuitry1302. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

In certain alternative embodiments, the network node1300does not include separate radio front-end circuitry1318, instead, the processing circuitry1302includes radio front-end circuitry and is connected to the antenna1310. Similarly, in some embodiments, all or some of the RF transceiver circuitry1312is part of the communication interface1306. In still other embodiments, the communication interface1306includes one or more ports or terminals1316, the radio front-end circuitry1318, and the RF transceiver circuitry1312, as part of a radio unit (not shown), and the communication interface1306communicates with the baseband processing circuitry1314, which is part of a digital unit (not shown).

The antenna1310may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna1310may be coupled to the radio front-end circuitry1318and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna1310is separate from the network node1300and connectable to the network node1300through an interface or port.

The antenna1310, communication interface1306, and/or the processing circuitry1302may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, the antenna1310, the communication interface1306, and/or the processing circuitry1302may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment.

The power source1308provides power to the various components of network node1300in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source1308may further comprise, or be coupled to, power management circuitry to supply the components of the network node1300with power for performing the functionality described herein. For example, the network node1300may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source1308. As a further example, the power source1308may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

Embodiments of the network node1300may include additional components beyond those shown inFIG.13for providing certain aspects of the network node's functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node1300may include user interface equipment to allow input of information into the network node1300and to allow output of information from the network node1300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node1300.

FIG.14is a block diagram of a host1400, which may be an embodiment of the host1116ofFIG.11, in accordance with various aspects described herein. As used herein, the host1400may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host1400may provide one or more services to one or more UEs.

The host1400includes processing circuitry1402that is operatively coupled via a bus1404to an input/output interface1406, a network interface1408, a power source1410, and a memory1412. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such asFIGS.12-13, such that the descriptions thereof are generally applicable to the corresponding components of host1400.

The memory1412may include one or more computer programs including one or more host application programs1414and data1416, which may include user data, e.g., data generated by a UE for the host1400or data generated by the host1400for a UE. Embodiments of the host1400may utilize only a subset or all of the components shown. The host application programs1414may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs1414may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host1400may select and/or indicate a different host for over-the-top services for a UE. The host application programs1414may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

Hardware1504includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers1506(also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs1508aand1508b(one or more of which may be generally referred to as VMs1508), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer1506may present a virtual operating platform that appears like networking hardware to the VMs1508.

The VMs1508comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer1506. Different embodiments of the instance of a virtual appliance1502may be implemented on one or more of VMs1508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, a VM1508may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs1508, and that part of hardware1504that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs1508on top of the hardware1504and corresponds to the application1502.

Hardware1504may be implemented in a standalone network node with generic or specific components. Hardware1504may implement some functions via virtualization. Alternatively, hardware1504may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration1510, which, among others, oversees lifecycle management of applications1502. In some embodiments, hardware1504is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system1512which may alternatively be used for communication between hardware nodes and radio units.

FIG.16shows a communication diagram of a host1602communicating via a network node1604with a UE1606over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE1112aofFIG.11and/or UE1200ofFIG.12), network node (such as network node1110aofFIG.11and/or network node1300ofFIG.13), and host (such as host1116ofFIG.11and/or host1400ofFIG.14) discussed in the preceding paragraphs will now be described with reference toFIG.16.

Like host1400, embodiments of host1602include hardware, such as a communication interface, processing circuitry, and memory. The host1602also includes software, which is stored in or accessible by the host1602and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE1606connecting via an over-the-top (OTT) connection1650extending between the UE1606and host1602. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection1650.

The network node1604includes hardware enabling it to communicate with the host1602and UE1606. The connection1660may be direct or pass through a core network (like core network1106ofFIG.11) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

The UE1606includes hardware and software, which is stored in or accessible by UE1606and executable by the UE's processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE1606with the support of the host1602. In the host1602, an executing host application may communicate with the executing client application via the OTT connection1650terminating at the UE1606and host1602. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection1650may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection1650.

The OTT connection1650may extend via a connection1660between the host1602and the network node1604and via a wireless connection1670between the network node1604and the UE1606to provide the connection between the host1602and the UE1606. The connection1660and wireless connection1670, over which the OTT connection1650may be provided, have been drawn abstractly to illustrate the communication between the host1602and the UE1606via the network node1604, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

As an example of transmitting data via the OTT connection1650, in step1608, the host1602provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE1606. In other embodiments, the user data is associated with a UE1606that shares data with the host1602without explicit human interaction. In step1610, the host1602initiates a transmission carrying the user data towards the UE1606. The host1602may initiate the transmission responsive to a request transmitted by the UE1606. The request may be caused by human interaction with the UE1606or by operation of the client application executing on the UE1606. The transmission may pass via the network node1604, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step1612, the network node1604transmits to the UE1606the user data that was carried in the transmission that the host1602initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step1614, the UE1606receives the user data carried in the transmission, which may be performed by a client application executed on the UE1606associated with the host application executed by the host1602.

In some examples, the UE1606executes a client application which provides user data to the host1602. The user data may be provided in reaction or response to the data received from the host1602. Accordingly, in step1616, the UE1606may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input/output interface of the UE1606. Regardless of the specific manner in which the user data was provided, the UE1606initiates, in step1618, transmission of the user data towards the host1602via the network node1604. In step1620, in accordance with the teachings of the embodiments described throughout this disclosure, the network node1604receives user data from the UE1606and initiates transmission of the received user data towards the host1602. In step1622, the host1602receives the user data carried in the transmission initiated by the UE1606.

One or more of the various embodiments improve the performance of OTT services provided to the UE1606using the OTT connection1650, in which the wireless connection1670forms the last segment. More precisely, the teachings of these embodiments may improve the ability of network operators to get real-time data and analytics (e.g., regarding vehicle pollution) and thereby provide benefits such as allowing governments and local administrations to reduce air pollution through more precise regulations.

In an example scenario, factory status information may be collected and analyzed by the host1602. As another example, the host1602may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host1602may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host1602may store surveillance video uploaded by a UE. As another example, the host1602may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host1602may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and/or transmitting data.

In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection1650between the host1602and UE1606, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host1602and/or UE1606. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection1650passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection1650may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node1604. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host1602. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection1650while monitoring propagation times, errors, etc.