Patent Application
20240291844
The following generally relates to wireless data networks, such as radio access network (RAN) mobile networks. More particularly, the following relates to systems, devices and automated processes to monitor and/or control the performance of a wireless data network such as a 5G, 6G or other RAN network.
Wireless networks that transport digital data and telephone calls are becoming increasingly sophisticated. Currently, fifth generation (“5G”) and sixth generation (“6G”) broadband cellular networks are being deployed around the world. These advanced networks use emerging technologies to support data and voice communications with millions, if not billions, of mobile phones, computers and other devices. Advanced technologies are capable of supplying much greater bandwidth than was previously available, so it is likely that the widespread deployment of these new mobile networks could radically expand the number of services available to customers.
Traditionally, data and telephone networks relied upon proprietary designs based upon very specialized hardware and dedicated point-to-point data connections. More recently, industry standards such as the Open Radio Access Network (“Open RAN” or “O-RAN”) standard have been developed to describe interactions between the network and various client devices. The O-RAN model follows a virtualized wireless architecture in which wireless base stations (“gNBs”) are implemented using separate centralized units (CUs), distributed units (DUs) and radio units (RUS), along with various control planes that provide additional network functions (e.g., 5G Core, IMS, OSS/BSS/IT). Generally speaking, it is still necessary to implement the RUs with physical transmitters, antennas and other hardware located onsite within broadcast range of the end user's device.
Other components of the network, however, can be implemented using a more centralized architecture based upon cloud-based computing resources, such as those available from Amazon Web Services (AWS) or the like. This provides much better network management, scalability, reliability and redundancy, as well as other benefits. O-RAN CUs, DUs, control planes and/or other components of the network can now be implemented as software modules executed by distributed (e.g., “cloud”) computing hardware. Other network functions such as access control, message routing, security, billing and the like can similarly be implemented using centralized cloud computing resources. Often, a CU, DU, control plane or other image is created in software for execution by one or more virtual computers operating in parallel within the cloud environment. The many virtual servers can be very rapidly scaled to increase or decrease the available computing capacity as needed.
The use of virtualized hardware provides numerous benefits in terms of rapid deployment and scalability, but it also presents certain technical challenges that have not been encountered in more traditional wireless networks. Unlike traditional wireless networks that scaled through the addition of physical routers, switches and other hardware, RAN networks can scale upwardly and downwardly very quickly as new cloud-based services are deployed and/or existing services are retired or redeployed. Additional network components can be very quickly deployed, for example, through the use of virtual components executing in a cloud environment that can be very quickly duplicated and spawned as needed to support increased demand. Similarly, virtual components can be de-commissioned very quickly with very little cost or effort when network capacity allows. The virtual components provide substantial efficiencies, especially when compared to prior networks that were based upon complex interconnections between geographically dispersed routers, servers and the like.
One technical challenge that arises in the new networks, however, involves monitoring the status and performance of rapidly-evolving dynamic networks. Network components can be commissioned and de-commissioned very rapidly, and conditions can evolve very quickly in various parts of the network. Tracking the performance and status of a large-scale RAN network can therefore be very difficult due to the scale of processing resources involved and the dynamic nature of such networks.
As new networks are developed and deployed, then, substantial challenges arise in tracking the performance of the network and its many distributed components. A substantial desire therefore exists to build systems, devices and automated processes that allow for monitoring and control of emerging RAN networks. These and other features are described in increasing detail below.
According to various embodiments, a data pipeline architecture provides for efficient and scalable data collection and processing within a RAN-based wireless network. The data pipeline includes one or more data collection systems that provide streaming and/or query-based data from multiple processing modules to a data collection engine. The data collection engine collects the data and formats it into a common data format for delivery to a data reporting engine. The data reporting engine provides dashboards, reports or other information about the collected data. The data reporting engine may also interface with a database system for longer-term storage of collected digital data.
Various embodiments described herein relate to improvements in data sources that are able to retrieve data from the various VMs or other components of the RAN wireless network. By using real-time processing (RTP) agents that are distinct from the components themselves to report operating data, the processing load on the components can be relieved. At the same time, the system becomes more robust because RTP agents can be deployed close to the monitored systems, thereby being more resilient to network failure or regionalized outages. RTP agents can also be designed with their own storage capabilities, thereby providing redundancy and additional capability to recover from communications outages or other issues. Additional benefits of deploying real-time data collection agents are described below.
In one embodiment, a data processing system is implemented in a processing cloud having a plurality of components. The data processing system suitably comprises: a plurality of processing modules residing in the processing cloud that each implement one or more components of a radio access network (RAN) based mobile network, wherein each of the processing modules produces operating data during operation, and wherein a first one of the plurality of processing modules produces the operating data in a first format and a second one of the plurality of processing modules produces the operating data in a second format that is different from the first format; a plurality of real-time processing agents each associated with the processing cloud and configured to receive the operating data from at least some of the plurality of processing modules of the RAN based mobile network including the first and second processing modules in real time, to convert the received operating data from the first and second formats into a common data format, and to forward the operating data in the common data format for further processing; a data collection system associated with the processing cloud, wherein the data collection system is configured to receive the operating data forwarded from each of the plurality of real-time processing agents and to amalgamate the forwarded operating data in the common format; and a data management system configured to receive the amalgamated operating data in the common data format, to store the amalgamated operating data in a database, and to provide an output that describes the amalgamated operating data.
Another example embodiment provides an automated process performed by a data processing system comprising a plurality of processing modules residing in a data processing cloud. The automated process suitably comprises: receiving operating data from each of a plurality of processing modules executing in the data processing cloud at a plurality of real-time processing agents also executing in the data processing cloud, wherein each of the processing modules implements a component of a radio access network (RAN) based mobile network within the data processing cloud; converting at least some of the received operating data received from a format produced by the component of the RAN based mobile network to a common format; forwarding the operating data in the common format from each of the real-time processing agents to a data collection system associated with the data processing cloud; storing the amalgamated operating data in the common data format in a database; and providing an output that describes the amalgamated operating data.
Other embodiments provide improvements in alert processing. The real-time processing (RTP) agents deployed to collect operating data about various components of the network can also be designed to detect alert conditions (e.g., anomalous behavior). When such conditions occur, an alert can be sent out-of-band to an alert processing system for immediate action. RTP agents can also be used to store redundant data for compliance purposes, or for any other reason.
To that end, various embodiments supply systems, devices and/or automated processes to manage the flow of operating data within a cloud data processing system, such as the data processing system used to implement a wireless RAN network. The various structures and processes described herein may be particularly well-suited for tracking the behavior of a wireless network, although equivalent embodiments could be used in other environments and settings as well.
These and other example embodiments are described in increasing detail below.
The following detailed description is intended to provide several examples that will illustrate the broader concepts that are set forth herein, but it is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to be bound by any theory presented in the preceding background or the following detailed description.
According to various embodiments, a centralized data collection system obtains operating or other performance data relating to the various modules of a RAN-based mobile network system. The centralized data collection system can be configured to receive streaming data that may be available from one or more data sources. Alternately and/or additionally, the centralized data collection system can place queries to other sources of data. Data received via query and/or streams can be filtered, formatted, tagged with metadata and/or otherwise processed into a common format for delivery a data management system that stores the collected data for later processing. The data management system may additionally (and/or alternately) create dashboard or other reports for evaluation by humans and/or by other automated processes based upon the amalgamated streaming and query-based data that has been placed in a common format.
Using a “data pipeline” in this sense allows for real time (or near real-time, accounting for some delays inherent in processing, data communications and the like) monitoring and control of a RAN-based wireless network in a manner that was not previously thought to be possible. The use of a centralized data collection system also provides for rapid adaptation to dynamic cloud-based systems in a manner that makes very efficient use of available data processing resources, thereby conserving energy, data storage and cost to the system operator.
With reference to
In example system 100, a network operator maintains ownership of one or more radio units (RUS) 128, 129 associated with a wireless network cell. Each RU 128, 129 suitably communicates with user equipment (UE) operating within a geographic area using one or more antennas/towers capable of transmitting and receiving messages within an assigned spectrum of electromagnetic bandwidth. In various embodiments, the assigned spectrum may be allocated across one or more guest networks 1 to support multiple concurrent networks, if desired.
The Open RAN standard breaks communications into three main domains: the radio unit (RU) that handles radio frequency (RF) and lower physical layer functions of the radio protocol stack, including beamforming; the distributed unit (DU) that handles higher physical access layer, media access (MAC) layer and radio link control (RLC) functions; and the centralized unit (CU) that performs higher level functions, including quality of service (QOS) routing and the like. The CU also supports packet data convergence protocol (PDCP), service data adaptation protocol (SDAP) and radio resource controller (RRC) functions. The RU, DU and CU functions are described in more detail in the Open RAN standards, as updated from time to time, and may be modified as desired to implement the various functions and features described herein.
In the example illustrated in
In the example of
As noted above, each of the various network components shown in
Each RU is typically associated with a different wireless cell that provides wireless data communications to any number of user devices operating within broadcast range of the cell. RUs may be implemented with radios, filters, amplifiers and other telecommunications hardware to transmit digital data streams via one or more antennas. Generally, RU hardware includes one or more processors, non-transitory data storage (e.g., a hard drive or solid state memory) and appropriate interfaces to perform the various functions described herein. RUs are physically located on-site with the transmitter/antenna, as appropriate. Conventional RAN networks may make use of any number of wireless cells spread across any geographic area, each with its own on-site RU.
User devices are often mobile phones or other portable devices that can move between different cells associated with the different RUs, although RAN networks are also widely expected to support home and office computing, industrial computing, robotics, Internet-of-Things (IoT) and many other devices. A practical implementation will typically have any number of RUs that can each be individually configured to provide highly configurable geographic coverage for the RAN network 102.
As noted above, the various components of network 102 can be implemented using virtual private clouds (VPC) or other virtual hardware components. Each of these VPCs will typically produce data during operation that indicates status, performance, capacity and/or any number of other parameters. It is generally desired to monitor the status of network 102. One way to track network status is to process the large amount of data produced by the various modules and components to generate dashboards and/or other reports that can be viewed by an operator. Operating data can also be used to adjust the configuration or operation of the network, as desired. By tracking data produced by the various components of network 102, then, the performance of the network can be monitored and adjusted as desired.
In various embodiments, one or more data sources 130, 134 are provided to obtain raw data from one or more of the components of network 102. Data sources 130, 134 may be receive data as part of a data stream, if desired. Other data sources 130, 134 may simply receive and maintain log data or the like from one or more associated components, as appropriate. Any number of streaming and/or query-based data sources 130, 134 may be deployed within system 100 as desired, and streaming data sources may be intermixed and/or combined with query-based data sources in any manner.
In the example shown in
The streaming data source 130 will typically be configured to receive real-time data (or near real time data, accounting for some delays inherent in data processing, communications and the like) from one or more components of network system 102. Streaming data may be particularly useful for network components that generate substantial amounts of real-time data (e.g., performance measurements, etc.). Data source 130 will be configured to receive the data stream from the monitored component of system 102, typically as a consumer process executed by the data source 130. Other embodiments may use other tools, and/or may be configured in any other manner.
If desired, multiple components of RAN wireless system 102 could supply KAFKA or other streaming data to a common data source 130. DU and CU modules of network 102, in particular, provide substantial amounts of real-time data that can be very efficiently pipelined through a combined streaming source 130, as appropriate.
In the example of
In one embodiment, query-based data source 134 is implemented using PROMETHEUS software or the like, which allows for a pull-based data collection model using HTTP-type messaging. In this example, the PROMETHEUS software is configured to run on a computer server (implemented with conventional hardware and/or cloud-based resources as desired) that queries the monitored components according to any desired time schedule to receive data. The data received in response to the queries may be locally cached in any sort of non-transitory memory (e.g., solid state memory, magnetic or optical memory, cloud-based sources, and/or the like) for subsequent retrieval and processing as desired. Query-based data sources may be particularly useful in tracking data produced by the various DUs, MTAs and other components of the network that produce substantial amounts of log data. Typically, each monitored component is internally configured to write its output/log data to the data source 134, as desired.
Although
A data collection system 140 suitably communicates with one or more data sources 130, 134 to obtain streaming and/or query-based data. In various embodiments, data collection system 140 subscribes to one or more KAFKA feeds or other streaming services associated with data sources 130. Data collection system 140 may also be configured to place queries to PROMETHEUS or other query-based data sources 134 as desired. Data collection system 134 typically receives the requested and/or subscribed data, formats and/or filters the received data as appropriate and forwards the collected data to a data management system 150 for storage, reporting and/or any other further processing as desired. In various embodiments, the data collection system 140 receives data in JSON or similar format, appends source and/or service location information as tags or the like, and pushes the tagged data to the data management system 150 (using, e.g., HTTP structures or the like). Generally, the data collection system will be configurable to specify batch sizes, delivery times and/or other parameters for obtaining query based data and/or for pushing collected data to the data management system 150. Some embodiments may also filter the received data as desired to remove unwanted or unnecessary data that would otherwise consume excess storage in data management system 150. Other embodiments may perform additional monitoring, as needed.
In various embodiments, data sources 130, 134 are configured as real-time processing (RTP) agents that are able to receive operating data from one or more components of network 102 for collection and forwarding to data management system 150. In such cases, data sources 130, 134 may be configured as separate virtual machines (VMs) that operate independently from the components that supply operating data. In other embodiments, data sources 130, 134 may be implemented as separate computing devices programmed to collect and forward data in any manner. In still other embodiments, the functions of data sources 130, 134 may be built into one or more components of network 102. Data sources 130, 134 therefore include any appropriate computing hardware, software and/or firmware (including any cloud hardware) to implement the various functions and features described herein. Other embodiments may combine virtual data sources 130, 134 with discrete data sources and/or integrated data sources, as desired, so that different types of monitored components can be tracked in any appropriate manner.
Data management system 150 is any data processing system capable of receiving the data from data collection system 134 and formatting or otherwise presenting the collected data for further use. In various embodiments, data management system 150 is a computer server implemented with conventional or virtual cloud-based hardware executing DATADOG or similar software for managing collected data. In various embodiments, data management system 150 stores received data in a database 155 for later retrieval, as desired. Data management system 150 may also provide reports to human and/or automated reviewers. One or more dashboards may be presented on any display 158, for example. Reports can be used to monitor the status of network 102, to adapt the configuration or operation of network 102 (or any component thereof), and/or for any other purpose. Data management system 150 may further provide real-time alerts (e.g., via email, text message or the like) to human operators if certain events occur, such as outages, shutdowns, security breaches and/or the like.
In the example of
The example illustrated in
Turning now to
In the example of
Data can be obtained from any number of streaming and/or query based sources. In various embodiments, a configurable source list 215 maintains a listing of data sources, along with any associated data about the sources or the collection of data from that source. In one example, each source is listed with an identifier, a URL or similar address where the source can be messaged, and an indication of whether the source is a streaming source and/or a query-based source. In various embodiments, additional information such as timing of queries or streaming parameters may also be provided. Source list 215 may be manually and/or automatically updated at any time so that the information remains current. Additional data sources can be added to reflect when new sources come online, for example; sources can be removed or modified as subsequent operation of network 102 demands. Management application 210 suitable uses the information in source list 215 to drive streaming subscriptions and/or query generation as appropriate. To that end, application 210 may check source list 215 according to any regular or irregular time interval, and/or as directed by external processes if desired. Although the example of
Data collection system 140 can subscribe to any number of data streams providing data in any format. In the embodiment of
Data can alternatively or additionally be received from other components of network 102 acting as query-based data sources 134. In the example of
As noted above, data received via data streams and/or in response to data queries can be filtered or otherwise processed as desired. Data filtering feature 226 suitably receives data in JSON or another appropriate format. The received data may be augmented with additional data (e.g., source identifier, timing information, region or AZ identification, or the like). Augmentation could be provided through JSON or XML tagging, if desired, or in any other manner. The data can also be filtered as desired to remove any unwanted components, if desired.
Processed data is provided to output feature 228 for delivery to the data management system 150 described above. In various embodiments, output feature 228 provides data to the data management system 150 using HTTP structures (e.g., HTTP “PUT” features) or the like.
In operation, then, data management system 140 suitably obtains streaming and/or query-based data from one or more components of a RAN wireless network operating within a cloud-based computing environment. The data is obtained directly from the component, and/or via intervening data source systems 130, 134 that aggregate data from multiple data sources within the network 102. Collected data is tagged and filtered as desired, and the resulting data is delivered to a data management system 150 for storage, reporting and/or other actions as appropriate. Other embodiments may include other processing modules in addition to those illustrated in
Process 300 suitably includes the broad functions of populating a list of data sources (function 302), obtaining operating data from each of the listed sources by positing queries (functions 304, 306) and/or subscribing to a data stream published by the data source (function 308). Operating data obtained from query and streaming sources can be converted into a common format and/or otherwise amalgamated (function 310) for further processing, as desired. The amalgamated data can be filtered as desired, and/or tagged for further analysis (function 314). The processed data is provided for output (function 314), such as storage in a database 155 or the like. Dashboards, reports, alerts and/or other forms of reporting to describe the amalgamated data may be processed from the stored data as desired (function 316). Equivalent embodiments may supplement or differently-organize the various functions shown in
Source list 215 may be populated in any manner (function 302). In various embodiments, source list 215 may be manually updated by a human operator using a text editor, software application program interface (API), web-enabled form, or other mechanism for data entry. In other embodiments, source list 215 may be populated by one or more control routines operating within system 102. As new modules are spawned within system 102, for example, the process that spawns the new module may be programmed to update source list 215 so that the newly-spawned module can be tracked. Again, the list may be updated using any appropriate interface, including internal communications within a cloud service provider or the like.
Source list 215 will typically maintain, for each data source, a listing of the source based upon an identifier or name, as desired. Additional information may also be maintained, such as dates or times that data collection is to be initiated or halted, dates and times of data collection, and/or the like. Source list 215 may also include a URL or other locator to obtain operating data from the source, and/or an indicator of whether the source provides streaming or query-based data. This indicator may be a simple binary flag, if desired, or a more complex representation as desired. Source list 215 may also contain parameters for data filtering (e.g., desired data frequency, desired reporting thresholds or limits, amounts of data to be maintained, and/or any other parameters as desired).
The source list 215 is processed in any manner to obtain operating data from the various sources. In the embodiment illustrated in
Streaming data is similarly obtained in any manner (function 308). In various embodiments, the source is programmed or otherwise configured to publish a data stream that can be received by a subscription manager 220 or similar data consumer application. The KAFKA streaming system provided by Apache Software Foundation is one example of a streaming platform that can be leveraged to distribute and receive streaming data, as desired, although other embodiments could be formulated with any number of equivalent products and services, as desired.
Streaming and query-based operating data received from the various data sources is amalgamated in any manner (function 310). In various embodiments, the received data is at least temporarily stored in a database or other storage available to data collection platform 140 for subsequent processing. Data can also be formatted, as desired, so that data received from different sources can be collectively processed and used in reporting functions described below. That is, data received in different formats can be converted into a common format for more efficient processing. Amalgamating data from different types of sources permits much more sophisticated analysis and reporting than was previously available from disjoint data collection sources.
The amalgamated operating data collected from query-based and stream-based data sources can be converted, filtered, tagged and/or otherwise processed for subsequent analysis (function 312). Generally speaking, many embodiments will place received data into a relatively consistent format that can be analyzed and processed by data management system 150 to permit dashboards, alerts and reports to be generated by a common system from different types of data that have been collected about system 102.
Filtering may involve removing certain received data from further processing, as desired. In some embodiments, filtering parameters are stored in source list 215 for one or more different sources. Other embodiments could additionally or alternatively apply “system level” parameters regarding data that should be kept and/or discarded. Data from one or more sources may be discarded for certain days or times, for example, or data that is “out of range” or otherwise exceeding a parameter limit could be ignored, if desired. That is, data that is unlikely to be of further interest for any reason could be discarded to prevent excessive storage overhead, to reduce confusion with more relevant data, and/or for any other purposes. Other filters could collect only certain types of data that are of particular interest, as desired.
Data tagging may be performed in any manner. In various embodiments, the operating data received from the various data sources is automatically tagged with metadata or other information about the data source, the method of collection, dates and/or times of collection, and/or any other information that may be desired. Tagging may be performed by associating the data values with other relevant information within an extensible markup language (XML) structure, a Javascript object notation (JSON) structure and/or any other format desired. In various embodiments, data collection system 140 automatically places both streaming and query-based data into a consistent format, along with any appropriate metadata. Placing both streaming and query-based data into a consistent structure (e.g., JSON) with appropriate metadata can permit more powerful monitoring and reporting, as described below.
Data collection system 140 provides the amalgamated data for output and storage in any manner (function 314). In various embodiments, the filtered and tagged data is transmitted to a data management system 150 for storage in a database 155 and subsequent analysis. In one example, data management system 150 implements a data monitoring service such as DATADOG cloud monitoring or the like. In some implementations, the data monitoring service receives JSON, XML or similarly formatted data from data collection system 140 via secure or unsecure HTTP or the like, although other protocols or formats could be equivalently applied.
Data stored in database 155 can be processed in any manner (function 316). In various embodiments, the stored data is processed (e.g., by the data monitoring service executed by data management system 150) to create reports, dashboards, alerts and/or the like. Reports may be generated in response to queries received via an API or the like, as desired. Dashboards may be generated for real time presentation to monitor current status of system 102 and/or its components. Alerts (e.g., text message or email alerts) could be generated based upon one or more data values passing a threshold (e.g., for high or low utilization, excessive loading, etc.), in response to detected outages or other important events occurring within system 102, and/or based upon any other factors to identify that an alert condition has occurred. Alerts could be generated on an immediate basis (e.g., in real time, or in as near to real time as possible, recognizing some delays inherent in data communications, processing and storage). Other embodiments could report alerts based upon polling by an alert module, or on any regular or irregular temporal basis as desired. Any number of electronic outputs may be provided for display, publication and/or messaging, as desired.
With reference now to
For RTP agents 130 implemented within cloud-based hardware (e.g., the AWS system), agents 130 may be readily duplicated and deployed as needed. RTP agents 130 may be configured to pull data from the monitored components of system 102 via RAN interfaces or the like, thereby providing more efficient data collection than implementations that rely upon monitored components pushing operating data to a collection system 140. This provides a highly scalable monitoring capability that is able to efficiently grow and shrink with the network 102.
RTP agents 130 may communicate with one or more associated components of network 102 using the structures of system 102, including RAN interfaces, if desired. In various embodiments, communications can take place using a managed orchestration service such as the AIRFLOW service available from the Apache Software Foundation and implemented within the Amazon Managed Workflows product of the AWS system, although other embodiments may use different products as desired. Generally speaking, the RTP agents 130 use the Airflow or similar service to poll the monitored network components, and to responsively receive requested operating data produced by the monitored component. The Apache Spark product could also be used to process queries and data collection, if desired.
Data collection agent 130 suitably receives the operating data at an interface 402 and temporarily caches in the received data in a memory or other data storage 408. Various embodiments are able to provide additional filtering or other processing 404 prior to forwarding the filtered data to data collection system 140 via interface 406. In various embodiments, interface 406 is configured to deliver the filtered operating data via a Kafka or similar feed, although other embodiments could use other products or formats, including proprietary formats if desired.
Certain embodiments may store the cached data until requested to deliver the data and/or to ensure redundant storage in the event of a communications, processing or network issue. In some implementations, data collection system 140 and/or another control entity within system 100 could prompt additional polling of one or more components of the network 102 if current conditions warrant. This can be particularly useful in making real-time modifications to network 102 (e.g., deploying or canceling components of the network 102) since then-current conditions of operating components can be readily queried and observed.
Filtering performed by RTP 130 may be performed in any manner and will vary depending upon the monitored component and the type of data being processed. Data may be batched or otherwise aggregated, for example, for more efficient delivery to data collection system 140. Filtering may discard some irrelevant or unwanted data, if desired. Data can be compressed, averaged and/or otherwise aggregated for more efficient transmission and storage, if desired.
RTP data agents 130 could be deployed in any manner desired, depending upon the type of component(s) to be monitored. In various embodiments, a data agent 130 could be deployed within a traditional cloud service to monitor large components (e.g., a NDC 115 or RDC 116, 117), whereas more localized agents 130 may be deployed within conventional computing hardware (e.g., to run as VCs within AWS-Local-Zen, VMWare and/or the like) within a computing data center for an edge data center (EDC) such as BEDCs 122, 123. Still other agents 130 could be implemented as standalone computing devices on conventional PCs, embedded hardware, and/or the like. To that end, RTP agents 130 could be deployed on any appropriate hardware, including cloud hardware, to monitor any portion of network 102 desired. Data is received from the monitored component of network 102, filtered and/or cached, and forwarded to data collection system 140 as desired.
As noted above, some implementations could use the distributed data collection agents 130 to generate alerts as well. Alerts could be detected as part of the filtering function 404, for example, if the monitored component is observed to deviate from expected behavior in any way. If a monitored parameter exceeds or falls below one or more appropriate threshold values, for example, an alert condition could be flagged. Various embodiments could further consider rate of change and/or acceleration information in flagging alerts. Even further alerts could use artificial intelligence routines to identify anomalous behavior, if desired. Alerts may be transmitted (e.g., as an out-of-band or real time message) to data collection system 140, to data management system 150 and/or to alert generation system 168, as desired. The alert generated will vary based upon the monitored component and the type of alert, but appropriate responses could be to update a dashboard presentation, to present a flag on a dashboard presentation, to trigger a text message or email to a human operator, and/or to provoke any other action as desired.
Various embodiments therefore provide a data pipeline system that can monitor the operations of a RAN wireless network 102 and/or its various components, particularly components that operate within a cloud-based computing environment. In contrast to prior systems that were unable to process “big picture” analysis due to disparate types of data collection, a data pipeline as described herein is able to collect both query-based and streaming data, to amalgamate both types of data into a consistent format that can be tagged with relevant metadata, and to provide the amalgamated data for further analysis, alerts and/or the like. Other embodiments may provide additional benefits and features, as desired.
The general concepts set forth herein may be adapted to any number of alternate but equivalent embodiments. The term “exemplary” is used herein to represent one example, instance or illustration that may have any number of alternates. Any implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations, nor is it necessarily intended as a model that must be duplicated in other implementations. While several exemplary embodiments have been presented in the foregoing detailed description, it should be appreciated that a vast number of alternate but equivalent variations exist, and the examples presented herein are not intended to limit the scope, applicability, or configuration of the invention in any way. To the contrary, various changes may be made in the function and arrangement of elements described without departing from the scope of the claims and their legal equivalents.
This application claims priority to U.S. Provisional Application Ser. No. 63/500,254 filed on May 4, 2023. This application is also a continuation-in-part of U.S. patent application Ser. No. 18/311,860 filed on May 3, 2023. That application claims priority to U.S. Provisional Application Ser. No. 63/338,269 filed on May 4, 2022. Each of these applications is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63338269 | May 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 63500254 | May 2023 | US |
| Child | 18654804 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 18311860 | May 2023 | US |
| Child | 18654804 | US |
