Patent Description:
<CIT> describes a node availability estimation service that can be used at a service layer of an M2M/IoT network. Value-added services can leverage this node availability information to improve the operation intelligence, quality of service, communication overhead as well as energy efficiency for M2M/IoT systems. A Real-time Data Collection (DC) component can collect real-time data from input sources at service layer (e.g., other existing CSFs). A Data Processing for Estimating Node Availability component (DP) can execute data processing for estimating node availability based on the data collected by DC. A Node Availability Service Provisioning component (SP) can store the estimated node availability results from DP and expose them to service clients in terms of "node availability estimation services".

According to an aspect, there is provided a method comprising.

Receiving the first performance management data associated with the network, based on the first indicator, may comprise:
receiving the first performance management data at the first resolution and aggregation from the network.

The first resolution and aggregation data collection may be different than the second resolution and aggregation data collection.

The first resolution and aggregation may include an aggregation time for when data is collected from the network and a resolution time for when measurements are collected from the network.

Receiving the second performance management data associated with the portion of the network, based on the second indicator, may comprise:
receiving the second performance management data at the second resolution and aggregation from the portion of the network.

The second resolution and aggregation may include an aggregation time for when data is collected from the portion of the network and a resolution time for when measurements are collected from the portion of the network.

The second resolution and aggregation data collection may be faster than and may include a greater resolution than the first resolution and aggregation data collection.

According to another aspect, there is provided a device comprising:.

The first performance management data may include one or more of:.

The second performance management data may include one or more of:.

The one or more processors, to perform the one or more actions, may be configured to one or more of:.

Each of the first performance management data and the second performance management data may include data identifying one or more of:.

The key performance indicator may include a key performance indicator identifying one or more of:.

According to a further aspect, there is provided a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising:
one or more instructions that, when executed by one or more processors of a device, cause the device to:.

The first resolution and aggregation may include a first aggregation time for when data is collected from the network and a first resolution time for when measurements are collected from the network. The second resolution and aggregation may include a second aggregation time for when data is collected from the portion of the network and a second resolution time for when measurements are collected from the portion of the network.

The one or more instructions, that cause the device to perform the one or more actions, may cause the device to one or more of:.

Since a configuration of a legacy system is semi-static, a volume of information collected, which is determined by granularity and aggregation, is not responsive to immediate requirements of the network. Consequently, whether a task at hand is to optimize the network by enabling a prescriptive or preemptive determination of optimized parameter settings, to provide a root cause analysis of network faults, or to provide geolocation enrichment information to a subscriber application, a uniform resolution of input data will be collected and processed. Reconfiguring current legacy systems in response to triggers, that require a finer resolution of data collection, is difficult because trigger information is generally available with too great a latency (e.g., due to a large geography, a large quantity of network elements, a large network slice, and/or the like) and because the configuration cannot be controlled finely enough to surgically target a desired data collection rate (e.g., with respect to a specific portion of the network). As a result, a trade-off between the volume of data collected and processed has to be made, as a compromise between performance of a task at hand and limitations of available storage, processing, and transport requirements.

Thus, current legacy systems waste computing resources (e.g., processing resources, memory resources, communication resources, and/or the like), networking resources, and other resources associated with utilizing a sub-optimal network, handling connectivity issues, utilizing sub-optimal applications, handling user complaints associated with the user experience, and/or the like.

Some implementations described herein provide a monitoring system for autonomously scaling resolution and aggregation levels of data used to determine an action associated with a parameter characteristic of a state of a UE, such as a geolocation or geolocation prediction of the UE, responsive to time varying requirements of a network, a subscriber, an application, a network slice, a geographical location, and/or the like. The action may include implementing data filtering, triggering a data collection, changing a format of one or more reports, determining an optimization, implementing an optimization, performing a network assurance option, changing a priority of a data collection, changing a latency of a data collection, changing a granularity of a data collection, providing a data feed to one or more different monitoring or processing entities, and/or the like.

For example, the monitoring system may set a first resolution and aggregation for data collection, and may receive data (e.g., network data, key performance indicators (KPIs), application data, and/or the like) based on the first resolution and aggregation. The monitoring system may determine a parameter characteristic of a state of a UE based on the data and may determine a trigger based on a root cause analysis, based on application data, based on the parameter characteristic and the KPIs, and/or the like. The monitoring system may identify a portion of the network associated with the trigger and may set a second resolution and aggregation for data collection for the portion of the network. The monitoring system may perform an action based on the second resolution and aggregation. For example, the monitoring system may provide a greater resolution and faster available data feed, may display network portion performance on a map (e.g., a two-dimensional map or a three-dimensional map), may change a RAN parameter, and/or the like. In some implementations, trigger conditions for the second data collection may overlap so that multiple second data collections may occur simultaneously with overlapping scope (e.g., overlapping network devices, network slices, UEs, applications, and/or the like).

In this way, the monitoring system autonomously scales resolution and aggregation levels of data collected from a network and utilized to determine an action. For example, the monitoring system may perform an action that optimizes network performance, a user experience, an application performance, and/or the like, which conserves computing resources, networking resources, and/or the like that would otherwise have been consumed utilizing a sub-optimal network, handling connectivity issues, utilizing sub-optimal applications, handling user complaints associated with the user experience, and/or the like.

<FIG> are diagrams of an example <NUM> associated with determining a parameter characteristic of a state of a UE via autonomous scaling of input data resolution and aggregation. As shown in <FIG>, example <NUM> includes UEs associated with radio access networks (RANs), a core network, and a monitoring system. The RANs and the core network together may form what is referred to as a network. Further details of the UEs, the RANs, the core network, and the monitoring system are provided elsewhere herein.

As shown in <FIG>, and by reference number <NUM>, the monitoring system may determine a first resolution and aggregation for data collection from the network. For example, the monitoring system may determine that data collection from the network be made with a first granularity in time and of geographic scope, with a first collection aggregation in time or of geographic scope, and/or the like. In some implementations, the first resolution and aggregation for data collection may include collecting data every minute (e.g., a first aggregation time) with measurements that are provided at one second resolution (e.g., a first resolution) within the data collected every minute. In some implementations, the first resolution and aggregation for data collection may include collecting data at a different first aggregation time with measurements that are provided at a different first resolution.

As further shown in <FIG>, and by reference number <NUM>, the monitoring system may provide, to the network, a first indicator identifying the first resolution and aggregation for data collection. For example, the monitoring system may generate the first indicator identifying the first resolution and aggregation for data collection based on determining the first resolution and aggregation for data collection. The monitoring system may provide the first indicator to the RANs of the network, one or more network devices of the core network, and/or the like. The first indicator may cause the RANs, the one or more network devices of the core network, and/or the like to provide performance management (PM) data to the monitoring system at the first resolution and aggregation.

As further shown in <FIG>, and by reference number <NUM>, the monitoring system may receive, from the network, first PM data associated with the network, based on the first indicator. For example, the first indicator may cause the monitoring system to receive the first PM data from the network at the first resolution and aggregation. In some implementations, the first PM data may include timing data associated with one or more of propagation delay of network signaling, timing advance (TA) aggregated in groups of TA steps for network signaling, instantaneous time offset of uplink signaling of the network, additional TA network signaling for different RANs, and/or the like.

In some implementations, the first PM data may include beam data associated with one or more of vertical or horizontal angle of arrival by a beam associated with the RANs, time to acquire the angle of arrival, uncertainty in the angle of arrival, rate of change or quantities of change related to attached RANs, beams of the RANs, best beams of the RANs, types of beam forming by the RANs, beam failure recoveries by the RANs, beam characteristics on multiple frequencies of operation, probability of line of sight propagation, and/or the like.

In some implementations, the first PM data may include UE identity data that enables data related to a same UE but connected to different RANs or beams to be correlated to enable a unified analysis and determination of a location of the UE, data that enables generation of analyses related to UE identifiers, such as subscribers of key accounts or customers who call to complain about adverse network events, and/or the like. The UE identity data may be available for a particular period of time. For example, an international mobile subscriber identity (IMSI), while allowing unique identification of a UE, may present a security issue or an inappropriate use of personal identification information. Consequently, the UE identity data may be utilized for correlation purposes or for appropriate KPI generation.

In some implementations, the first PM data may include data collected from a service management and orchestration (SMO) network device, where data is available over an operations and maintenance (O1) streaming interface according to an open RAN (O-RAN) architecture.

In some implementations, the first PM data may include data identifying one or more of an angle of arrival of a RAN signal in azimuth or elevation at the UE, a time to determine the angle of arrival or an inability to determine the angle of arrival, a raw time of arrival of the RAN signal, a timing advance associated with the UE, a quantity of beam changes by the UE, a quantity of beam failure recoveries by the UE, and/or the like.

In some implementations, the first PM data may include environmental data identifying an elevation or an atmospheric pressure associated with the UE, a temperature associated with the UE, sounds encountered by the UE, noise levels encountered by the UE, measurements of other radio technologies or magnetic fields proximate to the RANs or the UE, and/or the like.

As shown in <FIG>, and by reference number <NUM>, the monitoring system may calculate a first parameter characteristic of a state of a UE associated with the network based on the first PM data. For example, the monitoring system may process the first PM data, with a model (e.g., a haversine model), to calculate the first parameter characteristic of the state of the UE associated with the network. In some implementations, the monitoring system may utilize knowledge of geolocations of the RANs and the first PM data to calculate distances between the RANs and the UE. The monitoring system may then utilize the geolocations of the RANs and the distances between the RANs and the UE to calculate the first parameter characteristic (e.g., a geolocation) of the UE. In some implementations, the monitoring system may process the first PM data, with a model that conducts a first parameter characteristic (e.g., geolocation) pass to identify one or more parameter characteristic estimates under consideration. The model may conduct at least one additional parameter characteristic pass to refine one or more parameter characteristic estimates under consideration and may determine an approximate parameter characteristic (e.g., the first parameter characteristic) of the UE within an estimated coverage area of a network based on at least the first parameter characteristic pass and the at least one additional parameter characteristic pass.

As shown in <FIG>, and by reference number <NUM>, the monitoring system may determine a trigger based on the first parameter characteristic and based on one or more of a root cause analysis, an application input associated with the UE, or a KPI. For example, the monitoring system may utilize a root cause analysis to identify problems associated with the first parameter characteristic, such as problems associated with an accuracy of the first parameter characteristic, problems associated with the first PM data utilized to calculate to the first parameter characteristic, and/or the like. Accordingly, the monitoring system may determine that data collection associated with the UE needs to be increased in order to determine solutions to the problems associated with the first parameter characteristic. The monitoring system may determine the trigger in order to increase the data collection associated with the UE.

In some implementations, the monitoring system may utilize an application input (e.g., a navigation software application) associated with the UE to identify problems associated with the first parameter characteristic, such as the problems described above. Accordingly, the monitoring system may determine that data collection associated with the UE needs to be increased in order to determine solutions to the problems associated with the first parameter characteristic. The monitoring system may determine the trigger in order to increase the data collection associated with the UE.

The KPI may include a KPI identifying one or more of an error rate associated with a RAN serving the UE, a throughput associated with a RAN serving the UE, a quality of service (QoS) associated with a RAN serving the UE, a quality of experience (QoE) associated with a RAN serving the UE, a mean opinion score associated with a RAN serving the UE, a quantity of power utilized by the UE, whether the UE reached a maximum power, a connection drop associated with the UE, a latency associated with a RAN serving the UE, jitter associated with a RAN serving the UE, a cell load associated with a RAN serving the UE, a velocity associated with the UE, and/or the like. In some implementations, the monitoring system may utilize such KPIs to identify problems associated with the first parameter characteristic, such as the problems described above. Accordingly, the monitoring system may determine that data collection associated with the UE needs to be increased in order to determine solutions to the problems associated with the first parameter characteristic. The monitoring system may determine the trigger in order to increase the data collection associated with the UE.

In some implementations, the trigger may be limited to a geographic scope of the network, such as a coverage area associated with a RAN, a portion of a RAN, a beam or a portion of a beam of a RAN, a set of geographic network devices, and/or the like. The trigger may include a specific geographic scope independent of the network devices, such as, for example, within a geographic polygon, within specific tiles in a grid of tiles, within a building, at a specific outdoor area, and/or the like. The trigger may be valid for a particular duration of time for the particular geographic area.

As shown in <FIG>, and by reference number <NUM>, the monitoring system may identify a portion of the network that is associated with the trigger based on the first PM data. For example, the monitoring system may determine that one or more of the RANs and/or one or more network devices of the core network are associated with the trigger since the one or more of the RANs and/or the one or more network devices of the core network create the problems associated with the first parameter characteristic. In such an example, the one or more of the RANs and/or the one or more network devices of the core network may define the identified portion of the network. In some implementations, the monitoring system may utilize the first PM data and one or more of the root cause analysis, the application input, or the KPI to identify the portion of the network that is associated with the trigger.

As shown in <FIG>, and by reference number <NUM>, the monitoring system may determine a second resolution and aggregation for data collection from the network. For example, the monitoring system may determine that data collection from the portion of the network be made with a second granularity in time and of geographic scope, with a second collection aggregation in time or of geographic scope, and/or the like. In some implementations, the second resolution and aggregation for data collection may include collecting data at a second aggregation time with measurements that are provided at a first resolution within the data collected every minute. In some implementations, the second resolution and aggregation for data collection may include collecting data at a different second aggregation time with measurements that are provided at a different second resolution. In some implementations, the second resolution and aggregation data collection is faster than, and includes a greater resolution than, the first resolution and aggregation data collection.

As further shown in <FIG>, and by reference number <NUM>, the monitoring system may provide, to the network, a second indicator identifying the second resolution and aggregation for data collection. For example, the monitoring system may generate the second indicator identifying the second resolution and aggregation for data collection based on determining the second resolution and aggregation for data collection. The monitoring system may provide the second indicator to the portion of the network (e.g., RANs and/or network devices of the core network associated with the portion of the network). The second indicator may cause the portion of the network to provide PM data to the monitoring system at the second resolution and aggregation.

As further shown in <FIG>, and by reference number <NUM>, the monitoring system may receive, from the portion of the network, second PM data associated with the portion of the network, based on the second indicator. For example, the second indicator may cause the monitoring system to receive the second PM data from the portion of the network at the second resolution and aggregation. In some implementations, the second PM data may include timing data associated with one or more of propagation delay of network signaling, TA aggregated in groups of TA steps for network signaling, instantaneous time offset of uplink signaling of the network, additional TA network signaling for different RANs, and/or the like.

In some implementations, the second PM data may include beam data associated with one or more of vertical or horizontal angle of arrival by a beam associated with the RANs, time to acquire the angle of arrival, uncertainty in the angle of arrival, rate of change or quantities of change related to attached RANs, beams of the RANs, best beams of the RANs, types of beam forming by the RANs, beam failure recoveries by the RANs, beam characteristics on multiple frequencies of operation, probability of line of sight propagation, and/or the like.

In some implementations, the second PM data may include UE identity data that enables data related to a same UE but connected to different RANs or beams to be correlated to enable a unified analysis and determination of a location of the UE, data that enables generation of analyses related to UE identifiers, such as subscribers of key accounts or customers who call to complain about adverse network events, and/or the like. The UE identity data may be available for a particular period of time. For example, an IMSI, while allowing unique identification of a UE, may present a security issue or an inappropriate use of personal identification information. Consequently, the UE identity data may be utilized for correlation purposes or for appropriate KPI generation.

In some implementations, the second PM data may include data collected, at the second resolution and aggregation, from the SMO network device, where data is available over an O1 streaming interface according to the O-RAN architecture. The second PM data may include data collected from a wireless emergency service protocol (E2) interface (e.g., related to a network slice supporting the wireless emergency service over the E2 interface), data collected from the E2 interface that captures call events for one or more UEs, and/or the like. The second PM data may be received from network devices closer to an edge of the portion of the network with lower latency and without backhauling large quantities of data to a central location.

In some implementations, the second PM data may include data identifying one or more of an angle of arrival of a RAN signal in azimuth or elevation at the UE, a time to determine the angle of arrival or an inability to determine the angle of arrival, a raw time of arrival of the RAN signal, a timing advance associated with the UE, a quantity of beam changes by the UE, a quantity of beam failure recoveries by the UE, and/or the like.

In some implementations, the second PM data may include environmental data identifying an elevation or an atmospheric pressure associated with the UE, a temperature associated with the UE, sounds encountered by the UE, noise levels encountered by the UE, measurements of other radio technologies or magnetic fields proximate to the RANs or the UE, and/or the like.

As shown in <FIG>, and by reference number <NUM>, the monitoring system may calculate a second parameter characteristic of a state of the UE associated with the network based on the second PM data. For example, the monitoring system may process the second PM data, with a model (e.g., a haversine model), to calculate the second parameter characteristic of the state of the UE associated with the network. In some implementations, the monitoring system may utilize knowledge of geolocations of the RANs and the second PM data to calculate distances between the RANs and the UE. The monitoring system may then utilize the geolocations of the RANs and the distances between the RANs and the UE to calculate the second parameter characteristic (e.g., the geolocation) of the UE. In some implementations, the monitoring system may process the second PM data, with a model that conducts a second parameter characteristic (e.g., geolocation) pass to identify one or more parameter characteristic estimates under consideration. The model may conduct at least one additional parameter characteristic pass to refine one or more parameter characteristic estimates under consideration and may determine an approximate parameter characteristic (e.g., the second parameter characteristic) of the UE within an estimated coverage area of a network based on at least the second parameter characteristic pass and the at least one additional parameter characteristic pass.

As shown in <FIG>, and by reference number <NUM>, the monitoring system may perform one or more actions based on the second parameter characteristic. In some implementations, the one or more actions include the monitoring system causing a higher resolution faster available data feed to be provided by the portion of the network. For example, the portion of the network may provide the second PM data to the monitoring system at the second resolution and aggregation for data collection, which are greater than the first resolution and aggregation for data collection. Receiving the second PM data at a higher data rate may enable the monitoring system to more quickly resolve problems identified in the portion of the network based on the second PM data. In this way, the monitoring system conserves computing resources, networking resources, and/or the like that would otherwise have been consumed utilizing a sub-optimal portion of the network, handling user complaints associated with the user experience, and/or the like.

In some implementations, the one or more actions include the monitoring system generating and providing for display a two-dimensional or a three-dimensional map of the second PM data. For example, the monitoring system may utilize the second PM data to generate a representation (e.g., a map) of the second PM data that may be utilized by a user of the monitoring system to identify problems in the portion of the network. In this way, the monitoring system conserves computing resources, networking resources, and/or the like that would otherwise have been consumed utilizing a sub-optimal portion of the network, handling connectivity issues, handling user complaints associated with the user experience, and/or the like.

In some implementations, the one or more actions include the monitoring system causing a parameter of a RAN, of the portion of the network, to be modified. For example, the monitoring system may instruct the RAN, of the portion of the network, to modify a parameter (e.g., a beam intensity, a beam angle, and/or the like) associated with the RAN. The modified parameter may address one or more problems identified in the portion of the network (e.g., associated with the RAN). In this way, the monitoring system conserves computing resources, networking resources, and/or the like that would otherwise have been consumed utilizing a sub-optimal network, handling connectivity issues, utilizing sub-optimal applications, and/or the like.

In some implementations, the one or more actions include the monitoring system causing, in the portion of the network, a change in a location of processing the second PM data. For example, the monitoring system may cause the second PM data to be provided by and processed by network devices closer to an edge of the portion of the network with lower latency and without backhauling large quantities of data to a central location. Thus, the second PM data may be received by the monitoring system at a higher data rate, which may enable the monitoring system to more quickly resolve problems identified in the portion of the network based on the second PM data. In this way, the monitoring system conserves computing resources, networking resources, and/or the like that would otherwise have been consumed utilizing a sub-optimal portion of the network, handling user complaints associated with the user experience, and/or the like.

In some implementations, the one or more actions include the monitoring system causing an emergency service to be provided via switching from unicast to multicast operation (e.g., or ad-hoc direct device-to-device operation) in the portion of the network. For example, the monitoring system may cause the portion of the network to switch from unicast to multicast operation so that the emergency service may be provided by the portion of the network. The multicast operation may enable the portion of the network to provide the emergency service more quickly than the unicast operation may provide the emergency service. In this way, the monitoring system conserves computing resources, networking resources, and/or the like that would otherwise have been consumed providing insufficient emergency services, handling legal issues associated with providing insufficient emergency services, and/or the like.

In some implementations, the one or more actions include the monitoring system causing an emergency service to be provided via dispatching an autonomous vehicle with network coverage to the portion of the network (e.g., or preempting services operating on other network slices in the portion of the network). For example, if the portion of the network needs additional network coverage for the emergency service, the monitoring system may dispatch the autonomous vehicle (e.g., a drone, a robot, and/or the like) to a location of the portion of the network to provide the additional network coverage. The autonomous vehicle may provide the additional network coverage necessary to provide the emergency service in the portion of the network. In this way, the monitoring system conserves computing resources, networking resources, and/or the like that would otherwise have been consumed providing insufficient emergency services, handling legal issues associated with providing insufficient emergency services, and/or the like.

There are various ways of deriving geolocation estimates of a UE that use one or more measurements provided by the UE or a RAN. In general, these will be measurements of the power at which a transmission of a RAN is received by the UE whose location is being estimated, where this is measured by the UE and reported to the RAN. A geolocation estimate may be improved by using an offset between a time at which a transmission from a RAN is received at a UE and a time at which that UE makes a transmission to the RAN. This offset may be established by the RAN because the RAN keeps track of timing corrections it has instructed the UE to apply, or because the UE reports this offset to the RAN, and/or the like. This offset may be used in many communication systems to help keep transmissions from the UE within a delay window when the transmissions arrive at a serving RAN and thus avoid interference with other transmissions from other UEs using the same spectral resources. A geolocation estimate of a Universal Mobile Telecommunications System (UMTS) UE may be improved by using a magnitude by which reception of a start of a transmission frame structure from one RAN by the UE is offset from reception of a start of a transmission frame structure from another RAN by the same UE.

In communication systems where an air interface relies on timing alignment of receive and transmit frames to facilitate efficient communication (e.g., LTE, NR, and/or the like) it may be necessary to operate a timing advance mechanism to manage a timing adjustment of transmissions from the UE as the UE moves through and between RANs so that the transmissions are received by a RAN within an acceptable interval. The value of the timing advance may be used to assist in estimation of a geolocation of the UE in combination with other techniques.

The LTE and NR communication systems allow for separate timing advance to be maintained for multiple RANs. To support this, the UE may perform measurements of a time that transmissions from RANs in a first timing advance group are offset from a time that transmissions from RANs in a second timing advance group are received by the UE. These measurements may be reported by the UE to the network and thus may be available for use in a geolocation estimation process that is independent of the UE. The measurements reported may include Spectrum Sharing Test and Demonstration (SSTD) in the context of LTE and System Frame Number and Frame Timing Difference (SFTD) in the context of NR. These independent timing offset delay measurements may be utilized to enhance geolocation estimates.

A geolocation estimation process may use measurements where such measurements are from more than one timing advance group and may be associated with RANs that may be from at least one frequency band or bandwidth part. Such RANs or bandwidth part may operate at different subcarrier spacings with consequently different timing advance resolution. A variety of timing advance resolutions in the measurements for a UE may support more accurate geolocation estimates for the UE. The RANs may operate in different frequency bands with different radio propagation environments or may include different antenna configurations. In this case, the measurements may form independent estimates of propagation delay and thus may increase an error resilience of a geolocation estimation process.

In some implementations, the monitoring system may utilize the capability of <NUM> and <NUM> systems for establishing simultaneous connections to a set of multiple RANs, where each RAN in the set may be assigned to a single timing advance group from a set of at least two timing advance groups and may be managed by two or more timing advance processes. The RANs may use multiple timing advance processes in LTE that supports multiple (e.g., five) groups of RANs. Moreover, the RANs may be disjoint in one or more parameters and may provide independent estimates of propagation delay. The RANs may be disjoint by virtue of having multiple geographic locations, operational frequency bands, subcarrier spacings, channel bandwidths, antenna orientations, antenna beamwidths, degrees of line of sight propagation, degrees of non-line of sight propagation, and/or the like. In some implementations, the parameters of the RANs may be configured to be disjoint to utilize an independence of resultant delay estimates. Some systems may implement beamforming and a UE may be able to receive two separate beams originating from a same transmitter. Such beams, even if co-located, may have marginally different timing advance, especially if on different bands and subcarrier spacings, different beamwidth capability, and/or the like, and thus may provide independent estimates of propagation delay. In some implementations beam patterns may be configured to cause independent estimates of propagation delay.

In some implementations, the monitoring system may utilize measurements of an existing set of RANs that are simultaneously providing connectivity to a UE. Alternatively, in response to a need to estimate a geolocation, or to provide a higher accuracy geolocation estimate, a UE may be configured with a set of additional RANs that provide connectivity to the UE, such that a set of one or more independent delay estimates may be determined. In some implementations, the monitoring system may utilize two or more contemporaneous measurements of timing advance.

A communication system may employ a synchronous operational mode, where all RANs are maintained within a specified limit of timing alignment. Alternatively, the communication system may employ an asynchronous mode where there is no fixed timing arrangement between the RANs, so the communication system may establish timing offsets, including any timing drift between the RANs, as a separate step to determining propagation timing delays between the UEs and the multiple RANs. For example, a global positioning system (GPS) receiver may be installed at each RAN. A magnitude of an offset between a reference clock time of each RAN and a GPS time may be measured and monitored so that the clock time of each RAN may be corrected to a common time reference.

<FIG> is a diagram of an example environment <NUM> in which systems and/or methods described herein may be implemented. As shown in <FIG>, environment <NUM> may include a monitoring system <NUM>, which may include one or more elements of and/or may execute within a cloud computing system <NUM>. The cloud computing system <NUM> may include one or more elements <NUM>-<NUM>, as described in more detail below. As further shown in <FIG>, environment <NUM> may include a network <NUM>, a UE <NUM>, and/or a RAN <NUM>. Devices and/or elements of environment <NUM> may interconnect via wired connections and/or wireless connections.

The cloud computing system <NUM> includes computing hardware <NUM>, a resource management component <NUM>, a host operating system (OS) <NUM>, and/or one or more virtual computing systems <NUM>. The cloud computing system <NUM> may execute on, for example, an Amazon Web Services platform, a Microsoft Azure platform, or a Snowflake platform. The resource management component <NUM> may perform virtualization (e.g., abstraction) of computing hardware <NUM> to create the one or more virtual computing systems <NUM>. Using virtualization, the resource management component <NUM> enables a single computing device (e.g., a computer or a server) to operate like multiple computing devices, such as by creating multiple isolated virtual computing systems <NUM> from computing hardware <NUM> of the single computing device. In this way, computing hardware <NUM> can operate more efficiently, with lower power consumption, higher reliability, higher availability, higher utilization, greater flexibility, and lower cost than using separate computing devices.

Computing hardware <NUM> includes hardware and corresponding resources from one or more computing devices. For example, computing hardware <NUM> may include hardware from a single computing device (e.g., a single server) or from multiple computing devices (e.g., multiple servers), such as multiple computing devices in one or more data centers. As shown, computing hardware <NUM> may include one or more processors <NUM>, one or more memories <NUM>, one or more storage components <NUM>, and/or one or more networking components <NUM>. Examples of a processor, a memory, a storage component, and a networking component (e.g., a communication component) are described elsewhere herein.

The resource management component <NUM> includes a virtualization application (e.g., executing on hardware, such as computing hardware <NUM>) capable of virtualizing computing hardware <NUM> to start, stop, and/or manage one or more virtual computing systems <NUM>. For example, the resource management component <NUM> may include a hypervisor (e.g., a bare-metal or Type <NUM> hypervisor, a hosted or Type <NUM> hypervisor, or another type of hypervisor) or a virtual machine monitor, such as when the virtual computing systems <NUM> are virtual machines <NUM>. Additionally, or alternatively, the resource management component <NUM> may include a container manager, such as when the virtual computing systems <NUM> are containers <NUM>. In some implementations, the resource management component <NUM> executes within and/or in coordination with a host operating system <NUM>.

A virtual computing system <NUM> includes a virtual environment that enables cloud-based execution of operations and/or processes described herein using computing hardware <NUM>. As shown, a virtual computing system <NUM> may include a virtual machine <NUM>, a container <NUM>, or a hybrid environment <NUM> that includes a virtual machine and a container, among other examples. A virtual computing system <NUM> may execute one or more applications using a file system that includes binary files, software libraries, and/or other resources required to execute applications on a guest operating system (e.g., within the virtual computing system <NUM>) or the host operating system <NUM>.

Although the monitoring system <NUM> may include one or more elements <NUM>-<NUM> of the cloud computing system <NUM>, may execute within the cloud computing system <NUM>, and/or may be hosted within the cloud computing system <NUM>, in some implementations, the monitoring system <NUM> may not be cloud-based (e.g., may be implemented outside of a cloud computing system) or may be partially cloud-based. For example, the monitoring system <NUM> may include one or more devices that are not part of the cloud computing system <NUM>, such as device <NUM> of <FIG>, which may include a standalone server or another type of computing device. The monitoring system <NUM> may perform one or more operations and/or processes described in more detail elsewhere herein.

The network <NUM> includes one or more wired and/or wireless networks. For example, the network <NUM> may include a cellular network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a private network, the Internet, and/or a combination of these or other types of networks. The network <NUM> enables communication among the devices of environment <NUM>. In some implementations, the network <NUM> may include an example architecture of a fifth generation (<NUM>) next generation (NG) core network included in a <NUM> wireless telecommunications system, a fourth generation (<NUM>) core network included in a <NUM> wireless telecommunications system, and/or the like.

The UE <NUM> includes one or more devices capable of receiving, generating, storing, processing, and/or providing information, such as information described herein. For example, the UE <NUM> can include a mobile phone (e.g., a smart phone or a radiotelephone), a laptop computer, a tablet computer, a desktop computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart glasses, a head mounted display, or a virtual reality headset), a mobile hotspot device, a fixed wireless access device, customer premises equipment, an autonomous vehicle, or a similar type of device.

The RAN <NUM> may support, for example, a cellular radio access technology (RAT). The RAN <NUM> may include one or more base stations (e.g., base transceiver stations, radio base stations, node Bs, eNodeBs (eNBs), gNodeBs (gNBs), base station subsystems, cellular sites, cellular towers, access points, transmit receive points (TRPs), radio access nodes, macrocell base stations, microcell base stations, picocell base stations, femtocell base stations, and/or similar types of devices) and other network entities that can support wireless communication for the UE <NUM>. The RAN <NUM> may transfer traffic between the UE <NUM> (e.g., using a cellular RAT), one or more base stations (e.g., using a wireless interface or a backhaul interface, such as a wired backhaul interface), and/or the core network.

In some implementations, the RAN <NUM> may perform scheduling and/or resource management for the UE covered by the RAN <NUM> (e.g., the UE covered by a cell provided by RAN <NUM>). In some implementations, the RAN <NUM> may be controlled or coordinated by a network controller, which may perform load balancing, network-level configuration, and/or other operations. The network controller may communicate with the RAN <NUM> via a wireless or wireline backhaul. In some implementations, the RAN <NUM> may include a network controller, a self-organizing network (SON) module or component, and/or a similar module or component. In other words, the RAN <NUM> may perform network control, scheduling, and/or network management functions (e.g., for uplink, downlink, and/or sidelink communications of the UE <NUM> covered by the RAN <NUM>).

<FIG> is a diagram of example components of a device <NUM>, which may correspond to the monitoring system <NUM>, the UE <NUM>, and/or the RAN <NUM>. In some implementations, the monitoring system <NUM>, the UE <NUM>, and/or the RAN <NUM> may include one or more devices <NUM> and/or one or more components of device <NUM>. As shown in <FIG>, device <NUM> may include a bus <NUM>, a processor <NUM>, a memory <NUM>, a storage component <NUM>, an input component <NUM>, an output component <NUM>, and a communication component <NUM>.

The bus <NUM> includes a component that enables wired and/or wireless communication among the components of device <NUM>. The processor <NUM> includes a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field-programmable gate array, an application-specific integrated circuit, and/or another type of processing component. The processor <NUM> is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the processor <NUM> includes one or more processors capable of being programmed to perform a function. The memory <NUM> includes a random-access memory, a read only memory, and/or another type of memory (e.g., a flash memory, a magnetic memory, and/or an optical memory).

The storage component <NUM> stores information and/or software related to the operation of device <NUM>. For example, the storage component <NUM> may include a hard disk drive, a magnetic disk drive, an optical disk drive, a solid-state disk drive, a compact disc, a digital versatile disc, and/or another type of non-transitory computer-readable medium. The input component <NUM> enables the device <NUM> to receive input, such as user input and/or sensed inputs. For example, the input component <NUM> may include a touch screen, a keyboard, a keypad, a mouse, a button, a microphone, a switch, a sensor, a global positioning system component, an accelerometer, a gyroscope, and/or an actuator. The output component <NUM> enables the device <NUM> to provide output, such as via a display, a speaker, and/or one or more light-emitting diodes. The communication component <NUM> enables the device <NUM> to communicate with other devices, such as via a wired connection and/or a wireless connection. For example, the communication component <NUM> may include a receiver, a transmitter, a transceiver, a modem, a network interface card, and/or an antenna.

The device <NUM> may perform one or more processes described herein. For example, a non-transitory computer-readable medium (e.g., the memory <NUM> and/or the storage component <NUM>) may store a set of instructions (e.g., one or more instructions, code, software code, and/or program code) for execution by the processor <NUM>. The processor <NUM> may execute the set of instructions to perform one or more processes described herein. In some implementations, execution of the set of instructions, by one or more processors <NUM>, causes the one or more processors <NUM> and/or the device <NUM> to perform one or more processes described herein. In some implementations, hardwired circuitry may be used instead of or in combination with the instructions to perform one or more processes described herein.

The device <NUM> may include additional components, fewer components, different components, or differently arranged components than those shown in <FIG>. Additionally, or alternatively, a set of components (e.g., one or more components) of the device <NUM> may perform one or more functions described as being performed by another set of components of the device <NUM>.

<FIG> is a flowchart of an example process <NUM> for determining a parameter characteristic of a state of a UE via autonomous scaling of input data resolution and aggregation. In some implementations, one or more process blocks of <FIG> may be performed by a device (e.g., the monitoring system <NUM>). In some implementations, one or more process blocks of <FIG> may be performed by another device or a group of devices separate from or including the device, such as a RAN (e.g., the RAN <NUM>). Additionally, or alternatively, one or more process blocks of <FIG> may be performed by one or more components of the device <NUM>, such as the processor <NUM>, the memory <NUM>, the storage component <NUM>, the input component <NUM>, the output component <NUM>, and/or the communication component <NUM>.

As shown in <FIG>, process <NUM> may include determining a first resolution and aggregation for data collection from a network, wherein the network includes one or more RANs and a core network (block <NUM>). For example, the device may determine a first resolution and aggregation for data collection from a network, as described above. In some implementations, the network includes one or more RANs and a core network. In some implementations, the first resolution and aggregation includes an aggregation time for when data is collected from the network and a resolution time for when measurements are collected from the network.

As further shown in <FIG>, process <NUM> may include providing, to the network, a first indicator identifying the first resolution and aggregation for data collection from the network (block <NUM>). For example, the device may provide, to the network, a first indicator identifying the first resolution and aggregation for data collection from the network, as described above.

As further shown in <FIG>, process <NUM> may include receiving, from the network, first performance management data associated with the network, based on the first indicator (block <NUM>). For example, the device may receive, from the network, first performance management data associated with the network, based on the first indicator, as described above. In some implementations, receiving the first performance management data associated with the network, based on the first indicator, includes receiving the first performance management data at the first resolution and aggregation from the network. In some implementations, the first performance management data includes one or more of timing data associated with the network, beaming data associated with the RANs of the network, data associated with the user equipment, data collected from an operations and maintenance interface, or environmental data associated with the network.

As further shown in <FIG>, process <NUM> may include calculating, based on the first performance management data, a first parameter characteristic of a state of a user equipment associated with the network (block <NUM>). For example, the device may calculate, based on the first performance management data, a first parameter characteristic of a state of a user equipment associated with the network, as described above.

As further shown in <FIG>, process <NUM> may include determining a trigger based on the first parameter characteristic and based on one or more of a root cause analysis, an application input associated with the user equipment, or a key performance indicator (block <NUM>). For example, the device may determine a trigger based on the first parameter characteristic and based on one or more of a root cause analysis, an application input associated with the user equipment, or a key performance indicator, as described above. In some implementations, the key performance indicator includes a key performance indicator identifying one or more of an error rate associated with a RAN serving the user equipment, a throughput associated with a RAN serving the user equipment, a quality of service associated with a RAN serving the user equipment, a quality of experience associated with a RAN serving the user equipment, a mean opinion score associated with a RAN serving the user equipment, a quantity of power utilized by the user equipment, whether the user equipment reached a maximum power, a connection drop associated with the user equipment, a latency associated with a RAN serving the user equipment, jitter associated with a RAN serving the user equipment, a cell load associated with a RAN serving the user equipment, or a velocity associated with the user equipment.

As further shown in <FIG>, process <NUM> may include identifying a portion of the network that is associated with the trigger based on the first performance management data (block <NUM>). For example, the device may identify a portion of the network that is associated with the trigger based on the first performance management data, as described above.

As further shown in <FIG>, process <NUM> may include determining a second resolution and aggregation for data collection from the portion of the network (block <NUM>). For example, the device may determine a second resolution and aggregation for data collection from the portion of the network, as described above. In some implementations, the first resolution and aggregation data collection are different than the second resolution and aggregation data collection. In some implementations, the second resolution and aggregation includes an aggregation time for when data is collected from the portion of the network and a resolution time for when measurements are collected from the portion of the network. In some implementations, the second resolution and aggregation data collection is faster than and includes a greater resolution than the first resolution and aggregation data collection.

As further shown in <FIG>, process <NUM> may include providing, to the portion of the network, a second indicator identifying the second resolution and aggregation for data collection from the portion of the network (block <NUM>). For example, the device may provide, to the portion of the network, a second indicator identifying the second resolution and aggregation for data collection from the portion of the network, as described above.

As further shown in <FIG>, process <NUM> may include receiving, from the portion of the network, second performance management data associated with the portion of the network, based on the second indicator (block <NUM>). For example, the device may receive, from the portion of the network, second performance management data associated with the portion of the network, based on the second indicator, as described above. In some implementations, receiving the second performance management data associated with the portion of the network, based on the second indicator, includes receiving the second performance management data at the second resolution and aggregation from the portion of the network. In some implementations, the second performance management data includes one or more of timing data associated with the portion of the network, beam data associated with RANs of the portion of the network, data associated with the user equipment, data collected from a wireless emergency service protocol interface, or environmental data associated with the portion of the network.

In some implementations, each of the first performance management data and the second performance management data includes data identifying one or more of an angle of arrival of a RAN signal in azimuth or elevation at the user equipment, a time to determine the angle of arrival or an inability to determine the angle of arrival, a raw time of arrival of the RAN signal, a timing advance associated with the user equipment, a quantity of beam changes by the user equipment, or a quantity of beam failure recoveries by the user equipment.

As further shown in <FIG>, process <NUM> may include calculating a second parameter characteristic of a state of the user equipment associated with the network based on the second performance management data (block <NUM>). For example, the device may calculate a second parameter characteristic of a state of the user equipment associated with the network based on the second performance management data, as described above.

As further shown in <FIG>, process <NUM> may include performing one or more actions based on the second parameter characteristic (block <NUM>). For example, the device may perform one or more actions based on the second parameter characteristic, as described above. In some implementations, performing the one or more actions includes one or more of causing a higher resolution faster available data feed to be provided by the portion of the network, generating and providing for display a two-dimensional map or a three-dimensional map of the second performance management data, or causing a parameter of a RAN, of the portion of the network, to be modified. In some implementations, performing the one or more actions includes one or more of causing, in the portion of the network, a change in a location of processing the second performance management data, causing an emergency service to be provided via switching from unicast operation to multicast operation in the portion of the network, or causing an emergency service to be provided via dispatching an autonomous vehicle with network coverage to the portion of the network.

The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed.

As an example, "at least one of: a, b, or c" is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiple of the same item.

No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more. " Further, as used herein, the article "the" is intended to include one or more items referenced in connection with the article "the" and may be used interchangeably with "the one or more. " Furthermore, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, or a combination of related and unrelated items), and may be used interchangeably with "one or more. " Where only one item is intended, the phrase "only one" or similar language is used. Also, as used herein, the terms "has," "have," "having," or the like are intended to be open-ended terms. Further, the phrase "based on" is intended to mean "based, at least in part, on" unless explicitly stated otherwise. Also, as used herein, the term "or" is intended to be inclusive when used in a series and may be used interchangeably with "and/or," unless explicitly stated otherwise (e.g., if used in combination with "either" or "only one of").

Claim 1:
A method (<NUM>, <NUM>), comprising:
determining (<NUM>, <NUM>), by a device, a first resolution and aggregation for data collection from a network,
wherein the network includes one or more radio access networks (RANs) and a core network;
providing (<NUM>, <NUM>), by the device and to the network, a first indicator identifying the first resolution and aggregation for data collection from the network;
receiving (<NUM>, <NUM>), by the device and from the network, first performance management data associated with the network, based on the first indicator;
calculating (<NUM>, <NUM>), by the device and based on the first performance management data, a first parameter characteristic of a state of a user equipment associated with the network;
determining (<NUM>, <NUM>), by the device, a trigger based on the first parameter characteristic and based on one or more of a root cause analysis, an application input associated with the user equipment, or a key performance indicator;
identifying (<NUM>, <NUM>), by the device, a portion of the network that is associated with the trigger based on the first performance management data;
determining (<NUM>, <NUM>), by the device, a second resolution and aggregation for data collection from the portion of the network;
providing (<NUM>, <NUM>), by the device and to the portion of the network, a second indicator identifying the second resolution and aggregation for data collection from the portion of the network;
receiving (<NUM>, <NUM>), by the device and from the portion of the network, second performance management data associated with the portion of the network, based on the second indicator;
calculating (<NUM>, <NUM>), by the device, a second parameter characteristic of a state of the user equipment associated with the network based on the second performance management data; and
performing (<NUM>, <NUM>), by the device, one or more actions based on the second parameter characteristic.