US20160021173A1 - Resource management in a big data environment - Google Patents

Abstract

A method and system to automatically analyze, diagnose and repair the state of a network utilizing big data and machine learning techniques. Data from disparate sources related to a first network element is received by a processing layer. Contextual information from a measurements megastore related to the first network element and other network elements is retrieved. The data from the disparate sources and the contextual information is analyzed by an intelligence layer comprising big data and machine learning techniques. Upon determining, by the intelligence layer, that a predetermined condition is met or a predetermined threshold is exceeded, a notification is provided to the first network element. Over time, the intelligence layer adapts to learn based on growing amounts of historical data.

Description

CROSS REFERENCE TO RELATED PATENT APPLICATIONS
• This patent application claims priority to U.S. Provisional Application No. 62/025,453, entitled “Intelligent Automatic Troubleshooting for Cellular Networks”, filed on Jul. 16, 2014, to U.S. Provisional Application No. 62/025,958, entitled “Radio Resource Management with Big Data Feeds,” filed on Jul. 16, 2014, to U.S. Provisional Application No. 62/025,961, entitled “Recommendation Engine for Network Insights”, filed on Jul. 17, 2014, to U.S. Provisional Application No. 62/025,441, entitled “Automatic Healthcare Monitoring System Leveraging Cellular Data Systems,” filed on Jul. 16, 2014, and to U.S. Provisional Application No. 62/193,002, entitled “Big Data Machine Learning Use Cases,” filed on Jul. 15, 2015 which applications are hereby incorporated in their entirety by reference.
BACKGROUND
• Presently, there is a revolution with the advent of big data techniques. Where prior data storage technologies, such as relational databases, were not sufficiently performant for large amounts of data, the advent of alternative data stores, based in the cloud, along with parallel processing algorithms, such as map-reduce, have made big data practical, performant, and cost effective. Furthermore, presently there have been recent advances in performant processing, including on large amounts of data to allow for real-time analysis of data or near-real-time analysis of data. One example includes Spark which provides such processing on Hadoop and leverages in-memory computation. Since big data provides statistically significant amount of data to analyze, big data lends itself well to existing machine learning techniques.
• Big data and machine learning techniques, may be applied to a wide array of domains. One example is wireless communications which have experienced constant and significant transformation, guided by the continuous development of new network technologies and services, ushered in by the smartphone revolution and its countless applications. In this regard, wireless, such as cellular, systems have continuously evolved to cope with the increasing traffic demands, as well as the performance requirements imposed by these applications. The evolution of the wireless communication systems have typically taken place in isolated blocks, such as improving the performance at the radio level, or improving the architecture of the core network. While wireless communication has improved in the past decade, portions of the backend systems that support the networks still may include legacy architectures such as 3G and 2G networks.
• This creates a tremendous operational challenge for network operators that need to grow their systems in a sustainable way. Due to the complexity associated with the use of different types of wireless devices, different types of data services, and disparate radio access networks, the cost of customer care is significantly increasing. Further, there have not been significant advances on improving the various communication systems that utilize contextual information from other systems and network elements in the network. In order to keep up with the ever changing and demanding network performance requirements, wireless providers must transform their maintenance cost structure while having the flexibility to address the ever-evolving customer demands in a cost effective way. The fluidity of the network requirements, the evolving customer needs, and the need to stay cost effective present challenges to the traditional approaches. It is with respect to these considerations and others that the present disclosure has been written.
BRIEF DESCRIPTION OF THE DRAWINGS
• The drawing figures depict one or more implementations in accord with the present teachings, by way of example only, not by way of limitation. In the figures, like reference numerals refer to the same or similar elements.
• FIG. 1 illustrates an example network architecture for implementing a radio resource management architecture.
• FIG. 2 illustrates an example high level interface block diagram of the elements of a radio access network.
• FIG. 3 is a block diagram showing a Radio Resource Management (RRM) module interacting with the data framework, consistent with an exemplary embodiment.
• FIG. 4 is a flow diagram of an example process for a modified RRM utilizing Big Data Records.
• FIG. 5 is a flow diagram of an example process for adjusting a connection between an eNodeB and an EU based on a notification from the measurements megastore.
• FIG. 6 is a block diagram of a data framework, consistent with an exemplary embodiment.
• FIG. 7 illustrates an example model for a root cause identification.
• FIG. 8 is a flow diagram of an example process for maintaining a radio access network performance.
• FIG. 9 is an example user interface of a terminal coupled to a measurements megastore.
• FIG. 10, which illustrates a high level diagram of a system that includes remote health monitoring, consistent with an exemplary embodiment.
• FIG. 11 is a block diagram of a data framework of a monitoring system, consistent with an exemplary embodiment.
• FIG. 12 is a flow diagram of an example process for identifying a health condition using Big Data Records.
• FIG. 13 illustrates a network or host computer.
• FIG. 14 illustrates a computer with user interface elements.
DETAILED DESCRIPTION
• This disclosure generally relates to methods and systems of optimizing network elements. A scalable network backend is provided based on an open architecture that provides simplified access to data and increases automation. The operational efficiency and the overall cost of operation of the network is reduced by automation of functions and rationalization of hardware and software resources. The use of big data technologies, complemented with machine learning approaches, simplify and automate complex tasks, resulting in a more efficient network operation, improved customer quality and reduced subscriber churn.
• In one aspect, the systems described herein provide an open platform where multiple data feeds from disparate sources are combined and processed in real time. In one embodiment, the system performs continuous monitoring and transmission of the monitored data from each network node, which can be synthesized at a centralized remote server. The synthesized data harvested from disparate sources is analyzed for potential problems and relevant solutions are provided.
• In one aspect, data from disparate sources related to a first network element is received by a processing layer. Contextual information from a measurements megastore related to the first network element and other network elements is retrieved. The data from the disparate sources and the contextual information is analyzed by an intelligence layer. Upon determining, by the intelligence layer, that a predetermined condition is met or a predetermined threshold is exceeded, a notification is provided to the first network element.
Example System Architecture
• FIG. 1 illustrates an example network architecture for implementing a radio resource management architecture.FIG. 1 illustrates amobile communication network100 as may be operated by a carrier or service provider to provide a wide range of mobile communication services and ancillary services or features to its subscriber customers and associated mobile device users. The elements generally indicated by thereference numeral100 are elements of the mobile communication network and are operated by or on behalf of the carrier. Themobile communication network100 provides communications between user equipment (UE)102ato102d, as well as communications for the UE with networks and stations outside themobile communication network100.
• For purposes of later discussion, several UE's appear in the drawing, to represent some examples of the devices that may receive various services via themobile communication network122. Today, UE's typically take the form of portable handsets, smart-phones, tablet computers, personal digital assistants (PDAs), and smart watches, although they may be implemented in other form factors, including consumer, business, and medical electronic devices, such as a wearablepersonal health monitor102d. Themobile communication network100 allows users of the UE's (e.g., customers or subscribers) to initiate communication, and receive information from theinternet120.
• Themobile communication network100 typically is implemented by a number of interconnected networks. Hence, theoverall network100 may include a number of Radio Access Networks (RANs)122, as well as regional ground networks interconnecting a number of RANs and a wide area network (WAN) interconnecting the regional ground networks to core network elements, such as the Multimedia Messaging Service Centers (MMSCs). A regional portion of thenetwork100, such as that serving UE's102band102cmay include one or more RANs (represented by wireless communication network122) and a regional circuit and/or packet switched network and associated signaling network facilities.
• Physical elements of a RAN122, operated by one of the mobile service providers or carriers, include a number of base stations represented in the example ofFIG. 1 by an eNodeB119 node. Such eNodeB119 nodes may include a base transceiver system (BTS) that communicates via an antennae system at the site of the node and over the air-link with one or more of the UE's (102ato102d) when the UE's are within range. Each eNodeB119 node may include a BTS coupled to several antennae mounted on a radio tower within a coverage area often referred to as a “cell.” The BTS is the part of the radio network that sends and receives RF signals to/from the UE's that the eNodeBnode119 currently serves. Theradio access networks122 carries the user communications for the UE's between the respective eNodeB119 nodes and other elements with or through which the UE's communicate. In various embodiments, the radio that transmits communication signals (to one or more UE's) at each eNodeB may adjust the power output, bandwidth, etc., based on contextual information received from ameasurements megastore140 and/or alerts received from amonitoring server130, discussed in more detail later. Individual elements such as switches and/or routers forming theradio access network122 are omitted here for simplicity but are discussed in relevant part in the context ofFIG. 2.
• The radioaccess network portion122 of themobile communication network100 connects to a public packet data communication network, such as the network commonly referred to as the “Internet” shown at120. Packet communications via theradio access network122 and theInternet120 may support a variety of services through thenetwork100, such as providing contextual information from the measurements megastore and alerts from themonitoring server130 to various network elements of theradio access network122, as well as provide communications of text and multimedia messages, e-mail, web surfing or browsing, programming and media downloading (including audio and video), etc. to the UE's. For example, the UE's102ato102dmay be able to receive messages from and send messages to user terminal devices, such as personal computers, either directly (peer-to-peer) or via various servers (not separately shown).
• Of note for purposes of this discussion, many of the network messages and alerts discussed herein are sent to and received from various UE's using theradio access network122 as well as elements of theradio access network122. The Evolved Packet Core (EPC) of theradio access network122 uses the concept of Evolved Packet System (EPS) bearer channels to route IP traffic from agateway107 in theradio access network122 to a UE. A bearer channel is an IP packet flow with a defined quality of service (QoS) between the Packet Data Network (PDN) Gateway (PGW)107 and the UE (e.g.,13ato13e).
• TheeNodeBs119 are normally interconnected with each other by an interface known as “X2.” The communication between each eNodeB includes Radio Resource Management (RRM), which covers all functions related to the radio bearers, such as radio bearer control, radio admission control, radio mobility control, scheduling, and dynamic allocations of resources to UEs in both uplink and downlink. In one aspect, the RRM can communicate with the measurements megastore140 and/or receive messages from themonitoring server130 to optimize its control features.
• In one embodiment,network100 includes ameasurements megastore server140, which is coupled for communication via theinternet120. The measurements megastore server stores contextual information (which may be from various sources) that is relevant to creating a more efficient connection (e.g., power consumption and/or speed) between a UE and theradio access network122 as well as optimizing the components of theradio access network122. For simplicity, the UE and the components of the radio access network are collectively referred herein as network elements. In various embodiments, the contextual information provided by themeasurements megastore server140 may include different types of information. For example, the contextual information may include application level information that is extracted via Deep Packet Inspection (DPI) that is received from one or moreradio access networks122. The contextual information at theserver140 may include UE terminal category (e.g., smart-phone, tablet, laptop, personal health monitoring device, etc.) information. The contextual information may also relate the capabilities of the network element, such as the maximum transmission bitrate and whether it is configured to be a low power device (configured for low power versus high performance). In one embodiment, the contextual information may provide the latest stored power status of the network element, which may be used to optimize the connection between theradio access network122 and the respective UE.
• Accordingly, themeasurements megastore server140 stores contextual information comprising disparate data from various sources. The data stored in theserver140 comprises information that can be used by the network elements of thewireless communication network122 to provide a tailored optimization of the resources of the each network element, respectively. Alternatively or in addition, themonitoring server130 can retrieve the contextual information from themeasurements megastore140, which includes information from theentire network100, and analyze the contextual information together with data from disparate sources related to a network element to determine whether one or more predetermined conditions are met to trigger a message to the respective network element to optimize its performance in the context of theentire network100. In contrast, a prior art cellular communication network may only utilize locally obtained metrics from a small subset of network elements such as network elements in the core network from the same vendor, or network elements deployed to implement a specific feature in the network, to decide how to optimally assign resources to each communication link of a UE102 to the to theRadio Access Network122.
• For example, to establish a connection between a UE and an eNodeB, a prior art radio scheduler (at an eNodeB) may merely consider locally accessible information, such as the amount of data in the buffer of the respective UE, the identified radio quality, and the device capability, for the scheduler to determine the number of turns to assign to each link between the UE and the corresponding eNodeB. Even in more advanced prior art systems that may use Deep Packet Inspection (DPI) to, for example, assign a different quality level to a Skype video call than to a File Transfer Protocol (FTP) transfer, the data that is extracted from the particular subsystem (i.e., wireless communication network) and is not shared between different network elements. However, this extracted data is limited and the resources allocated to a connection between an eNodeB and a corresponding UE is a guess at best. For example, in prior art systems, even if a radio scheduler of aneNodeB119 may determine the terminal category of the terminal, the scheduler may still not be aware that the UE (e.g.,102d) is a machine to machine (M2M) module that needs to save as much battery life as possible.
• In contrast, in one aspect, the system described herein allows the sharing of information across multiple eNodeB's119 by storing contextual information at ameasurements megastore server140, which improves the capacity of thewireless communication network122 by allocating, for example, the type of resources in a connection between a UE (e.g.,102d) and itscorresponding eNodeB119. Thus, the radio communication between a UE102 and theradio access network122 is better adjusted by making use of contextual information such as the type of customer, data plan, type of application, type of device, etc., which is provided by the measurements megastore140 via theinternet140.
• Themonitoring server130 and the measurements megastore140 may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load and/or to provide additional functionality. For example, in one embodiment there may be a remote health (e.g., for humans)monitoring server150 that is similar in configuration to the measurements megastore140 but may be specialized in remote health monitoring. In this regard, thesystem100 provides an open platform where multiple data feeds from various UE's, such as thepersonal health monitor102d, and disparate systems, such as other networks and servers, can be combined and processed in real time, for millions of individuals. Thus, the functionality described herein with respect to each of theservers130,140, and150 can also be provided by one or multiple different servers. The actual operation of thesystem100 is described by way of example later.
• FIG. 2 illustrates an example high level interface block diagram of the logical nodes of aradio access network122. For example, the System Architecture Evolution (SAE)200 is the core network architecture of Third Generation Partnership Project's (3GPP's) Long Term Evaluation (LTE) wireless communication standard. TheSAE200 has a flat, all-IP architecture with separation of control plane and user plane traffic. TheSAE200 system includeseNodeB219, Mobility Management Entity (MME)202, Home Subscriber Server (HSS)204, and the Policy Control and Charging Rules Function (PCRF)206, which are part of themobile traffic network122 and are each network elements. TheeNodeB219 can be viewed as an enhanced base station that acts as an interface between theUE202 and theradio access network122.MME202 is a control-node for the communication access network. For example, it is used for idle mode mobile device tracking and paging procedure including retransmissions. It also provides bearer channel activation/deactivation process and selection of the serving gateway (SGW)212 for the UE202e.
• The Home Subscriber Server (HSS)204 is a central database that contains user-related and subscription-related information. TheHSS204 provides features such as mobility management, call and session establishment support, user authentication and access authorization. For example, the HSS stores the Mobile Station International Subscriber Directory Number (MSISDN), the SIM-card identification information, and the like.
• The Packet Data Network (PDN) Gateway (PGW)107 provides connectivity from theUE202 to external packet data networks. The Policy Control and Charging Rules Function (PCRF)206 provides for policy control decision-making, as well as for controlling the flow-based charging functionalities in the Policy Control Enforcement Function (PCEF), which resides in thePGW107. ThePCRF206 provides the QoS authorization that decides how certain data flow is treated in the PCEF and ensures that this is in accordance with the user's subscription profile.
• The Serving Gateway (SGW)212 routes and forwards data packets to the mobile202 through theMME202. For example, a data packet can include a notification message that an account threshold is exceeded. TheSGW212 manages and stores mobile device parameters of the IP bearer channel service, including network internal routing information. Each of these network elements and others can be adjusted in performance based on the contextual data from the measurements megastore140 and the alerts/messages of themonitoring server130.
Radio Resource Management (RRM)
• FIG. 3 is a block diagram showing a Radio Resource Management (RRM) module interacting with the data framework, consistent with an exemplary embodiment. TheeNodeB319 acts as a base station between one or more UE's (e.g., UE302) and a wireless communication network. In the example ofsystem300, eacheNodeB330 includes ascheduler322 that is configured to provide priority (e.g., allocating the number of turns) for data transmission between theUE302 and the wireless communication network. TheeNodeB319 may include alink adaptation324 unit that is configured to adjust the transmission mode to the channel conditions by, for example, adjusting modulation, coding, and selecting the appropriate time for transmission.
• TheeNodeB319 may include aflow control326 unit that is configured to control the flow of the operations of theeNodeB319. Theflow control326 unit may provide admission control, coordination of the security signaling, compression, etc. The eNodeB includes anantenna330 that is configured to communicate with various UE's (e.g. UE302) within its wireless communication range.
• The various components of theeNodeB319 together comprise anRRM module328, which is configured to communicate with thedata framework370 via an open Application Program Interface (API)334. As illustrated insystem300, the data framework may include themeasurements megastore340, anintelligence layer350 and adata processing layer352. For example, theAPI334 may facilitate communication betweeneNodeB319 through thewireless communication network122, via the internet120 (ofFIG. 2) to themeasurements megastore340. Thedata processing layer352 may also receive localized information from theRRM328.
• As discussed before, the measurements megastore340 is configured to store contextual information from various network elements, such as RRM modules of different eNodeB's, that can be shared by eNodeB319 (and other eNodeB's configured to receive information from the measurements megastore140), to better adjust the respective network element of the radio communication over thewireless communication network122 ofFIG. 1. Such optimization may include at least one of: admission control, scheduler, link adaptation, and power control procedures of the respective eNodeB.
• In embodiment, in order to populate the contextual information in themeasurements megastore340, data is gathered by thedata processing layer352 ofsystem300. The data gathered by the processing layer may be from various sources, which may include data from elements of thewireless communication network122, such as RRM module's coupled to thewireless communication network122, as well as other servers (e.g.,130,150) of thesystem100. The type of information received by thedata processing layer352 may include subscriber radio trace (e.g., location) provided by a UE, operations subsystem (OSS), customer care records, billing, application performance monitoring reports, and other information, including relevant information from the internet. In one embodiment, at least some of this information is provided by themeasurements megastore340.
• In one embodiment, the data includes information from Deep Packet Inspection (DPI) provided by various eNodeB's. Thedata processing layer352 may be performed in real time and/or in batch. The data may be provided to a network element (e.g., anRRM module328 at an eNodeB319) via a query performed by the network element in real time or may be pushed to the RRM module at predetermined time intervals or in response to a notification generated by theintelligence layer350.
• In one embodiment, theintelligence layer350 may be configured to receive the information from thedata processing layer352 and determine whether predetermined one or more conditions are met. These conditions may be provided by a rule set stored in a memory of the intelligence layer. When a predetermined condition is met, the intelligence layer may generate a relevant alert. For example, theintelligence layer350 may analyze the patterns of the data provided by thedata processing layer352 for any outliers that may indicate a problem at an RRM. In this regard, theintelligence layer350 may trigger a notification to other RRM modules to prevent and/or mitigate the problem from spreading. The alert may simply be a notification (e.g., a suggestion to act) or an active control signal that alters the RRM method of one or more modules that are part of thesystem300.
• Theintelligence layer350 typically includes a probability tree that stores the probabilities that particular causes and/or events were the root cause of a network event such as a dropped call. The implementation of a probability tree is described in further detail with respect toFIG. 7. Note that that a node with anintelligence layer350 need not have the same probability tree as other nodes. In this way, nodes may be partitioned according to scenario and/or use cases.
• For example, thedata processing layer352 may receive information from first RRM module that is indicative of a problem. The data received from the first RRM module may, for example, indicate that the SGW is overloaded with signaling messages. Theintelligence layer350, upon identifying the problem with the first SGW, may retrieve contextual information from the measurements megastore related to the network element and other network elements. Upon determining that a condition is met or a predetermined threshold is exceeded, theintelligence layer350 may issue a notification to other RRM modules configured to receive messages from thedata framework370. In one embodiment, the first RRM module also receives the alert from thedata framework370, generated by theintelligence layer350. In this regard, the other eNodeB modules can buffer or discard the communication requests going to their systems, respectively, to prevent the problem that affected the first RRM module.
• Accordingly, the contextual information in the measurements megastore340 can be made available to an RRM module by the measurements megastore340 in response to a request (e.g., query) from the RRM module, or may be provided as a notification from thedata framework370.
• With the foregoing overview of the system, it may be helpful now to consider a high-level discussion of an example operation of thesystem300. To that end,FIG. 4 illustrates a high level flow chart of thedata framework430 and anRRM module402 and their interaction with one another. TheRRM module402 may be one of several RRM modules that are configured to receive data from adata framework430. Thedata framework430 includes contextual information that is gathered from multiple sources, which is used by theRRM module402 for adjusting the resources of the RRM module (e.g., optimize a connection between an eNodeB and an UE).
• Beginning with thedata framework430, instep434, relevant data is collected from various sources into a common data framework. This data is collected by a data processing layer in real-time and/or in batch. The data gathered may be from various sources, which may include different components of thewireless communication network122, including separate RRM module's configured to operate on thewireless communication network122. For example, each RRM module may provide the radio resources based on its local knowledge of thewireless communication network122 and its corresponding UE(s) of thesystem100 ofFIG. 1. The sources of the data gathered may also include other servers ofsystem100 and the internet. The type of information received by the data framework430 (via the processing layer) may include subscriber radio trace (e.g., location) provided by a UE, operations subsystem (OSS), customer care records, billing, application performance monitoring reports, and other information, including relevant information from the internet. In one embodiment, the data harvested by the data processing layer ultimately becomes the contextual data that is stored at themeasurements megastore server340, which may be used retrieved by other network elements or the data processing layer.
• In one embodiment, instep436, the data gathered from the various sources by thedata framework430 is provided to theRRM module402 to adjust its resources allocated to a connection between its eNodeB and a corresponding UE. The information may include data that has not been processed by the intelligence layer, such as general information on subscribers and network nodes.
• In one embodiment, instep438, the data gathered by the data framework is further processed by an intelligence layer, which is operative to analyze the data and extract patterns and/or trends therefrom. For example, instep438, the intelligence layer may determine whether one or more thresholds are exceeded or one or more criteria are met. For example, the RRM module is OFF or the number of dropped calls exceeds 0.1%. In various embodiments, the considerations by the intelligence layer may include user/subscriber predetermined preferences, subscriber limitations (e.g., exceeding a threshold data usage), the type of plan (e.g., higher grade plans may be given priority), type of UE (e.g., devices that are intended to work under low power conditions are provided connections that demand less power), etc. In this regard, instep422, thedata framework430 may provide one or more messages to the appropriate RRM module(s) in a form of special alerts, which may include instructions on how to adjust the local resources for a connection between the eNodeB and its corresponding UE, on an individual basis. For example, the appropriate RRM module(s) where the alert from thedata framework430 to the RRM module(s) are sent may be based on sector and/or time (e.g., the RRMs covering a sports stadium at the time of a game).
• On theRRM module402 side, instep406, theRRM module402 calculates the radio resources based on local knowledge. The local knowledge may include the type of device (UE) it is establishing a connection with, the number of UE's the local eNodeB is connected with, traffic, power consumption, modulation quality, temperature of the eNodeB, etc. In one embodiment (not shown) this information is provided to thedata framework430 via thedata processing layer352.
• Instep408, theRRM module402 adjusts the resource allocation between its eNodeB and each UE on an individual basis, based on the general information data received from thedata framework430 instep420. As discussed above, in one embodiment, theRRM module402 may receive one or more messages from thedata framework430 in the form of one or more special alerts (i.e., notifications). Instep408, theRRM module402 assigns the resources of eNodeB based on the special alerts on subscribers and network nodes received from the data framework. Whilesteps408 and408 have been illustrated by way of example to be separate steps, in one embodiment, the adjustment of resources and the assignment of resources may be performed by the same step (e.g.,408).
• For example, based on the information received from thedata framework430 having themeasurements megastore140, the eNodeB of theRRM module402 may adjust the connection based on the power (e.g., consumption limitation) requirements for each UE individually. In various instances, based on the contextual information received from themeasurements megastore140, an eNodeB may gradually reduce the number of UE's that are allowed to connect to a respective eNodeB in order to balance theradio access network122 resources and/or prevent failure. For example, thescheduler322, upon receiving a warning from themeasurements megastore340, may stop sending new session requests to theradio access network122.
• Other remedial actions may include reducing the bandwidth or preventing communication with specific UE's that have exceeded predetermined thresholds or have not met one or more criteria. In various embodiments, the restriction(s) may be lifted after a threshold time or upon receiving a message from the measurements megastore140 that the UE is within predetermined thresholds. In one example, the restrictions may be lifted when a criterion is met (e.g., sporting event at an arena, which is serviced byeNodeB319, has completed), which reduces the risk of overloading the eNodeB of theRRM module402.
• FIG. 5 is a flow diagram of an example process for adjusting a connection between an eNodeB and an EU based on a notification from themeasurements megastore140. The flow diagram ofFIG. 5 is a particular example that considers the type of the network element and the stored criteria for such a type of element. Instep506, the RRM module determines the radio signal quality between an UE the eNodeB based on local knowledge. In one embodiment, instep508, the RRM module determines the appropriate coding format based on the determined radio signal quality based on local knowledge.
• Instep510, the RRM module communicates with the measurements megastore140 to receive contextual information therefrom. This step may be performed as a query from the RRM module to themeasurements megastore140, or a push notification from the measurements megastore140 to the RRM module based on predetermined criteria stored at themeasurements megastore140.
• In the example ofFIG. 5, the RRM module may perform a query (e.g., over the internet120) to the measurements megastore140 in support of various network operations. In the present example, the network operation is to initiate and establish a communications for a UE. In various embodiments, the RRM may send the UE device identifier and/or other indicators of radio signal quality based on local knowledge to themeasurements megastore140. In response, instep520, the measurements megastore140 may indicate that the type of UE that the RRM module is in the process of establishing a connection with, is intended to work at low power, and the connection between the eNodeB and the UE should be optimized for low power operation. For example, the connection may be serving an M2M customer that may benefit from a connection that uses the least amount of power. This scenario may be of importance for medical devices that are implanted or are wearable personal health monitoring devices. Thus, instep520, the contextual information provided by the measurements megastore140 may be in the form of a notification (e.g., warning) or an instruction to the RRM module to adjust the connection such that the UE consumes a more optimized (e.g., least) amount of power.
• In another scenario, the indicators of radio quality that were determined based on local knowledge, that were provided to themeasurements megastore140, may include the battery status (e.g., running low). In this regard, the measurements megastore140 in cooperation with the intelligence layer may identify from previously stored user preferences that the UE (that is now running low on power) should be operated in low power mode to extend its duration as long as possible. In this regard, the intelligence layer may issue a notification (in step520) to the RRM module that the connection between the eNodeB and the UE should be of low power. Thus, without the additional input from themeasurements megastore140, the RRM module would not have determined that the user preferences include a low power operation when a predetermined condition is met (i.e., running at low power).
• Accordingly, instep512, the RRM modifies the coding scheme to provide a connection with the UE that provides the most power savings, which may include a lower bandwidth operation, thereby freeing upradio access network122 resources for other purposes. For example, the warning received from the intelligence layer triggers an “event handler” at the eNodeB to perform some the power saving functions.
Intelligent Automatic Troubleshooting for Radio Access Networks
• As discussed above, in one aspect, by using ameasurements megastore140, automatic detection of network problems at a subscriber level are made possible. In some scenarios, a problem can be identified (and sometimes prevented) even before the customer becomes aware of the problem, which greatly improves customer relations. This advantage may be better understood in view of existing approaches to address network problems and related customer complaints. For example, when a subscriber (e.g., customer) experiences a network problem, there is typically a lengthy and sometimes frustrating process involved, which is typically highly manual, requiring the frequent intervention of skilled engineers to identify and resolve the issues.
• For example, a customer first must call and explain the symptoms to a customer care representative, who classifies the matter based on predetermined criteria. An internal record may be generated to be analyzed by an appropriately skilled engineer. An engineer may create a Call Reliability Report that includes the traffic volume, number of dropped calls, reasons for the dropped calls, and an overall calculated drop call rate for the node(s) of concern. In some cases, there is an intermediate engineering triaging group that may address some of the complaints, while in other cases, the case is sent to a field engineer to investigate the root of the problem. Due to the complexity of the radio access network, the field engineer may investigate multiple systems to determine what the cause of the problem may be based on the limited analysis that s/he could perform from the local knowledge of the network.
• The challenges of the engineer are further exacerbated by the fact that in today's cellular networks, there are an increasing number of data sources with a substantial amount of performance data that is collected from each network element (e.g., eNodeB), which is often aggregated in time intervals such as minutes, hours, days, etc. Together the data provides key performance indicators (KPIs), which are reviewed by engineers to better understand the overall health of the radio access network, detect problematic situations, and decide when it is time to upgrade part of the network. Furthermore, in existing systems it is difficult to aggregate data from disparate sources, particularly if they are of different nature. For example, a report including a drop call rate trend in one area is not easy to combine with the churn rate trend. Such specialized report requires significant processing and therefore may not be immediately available to the engineer. Once the data is made available, the engineer must still manually analyze the large volume of data, which is not only inefficient but may also be incomplete because an engineer may not be able to effectively discern trends from multiple data sources. The result is typically a sub-optimal radio access network performance.
• In contrast, in the system described herein, the bulk (if not all) of the analysis of the state of the network automatically performed by a data framework that includes ameasurements megastore140. Indeed, the root cause of the problem may be determined (if not prevented) even before the customer becomes aware of the problem. Such automation is made possible by ameasurements megastore140 that, together with a data processing layer and an intelligence layer, is configured to detect problems at a subscriber level by not only relying on local knowledge of the network element, but also using data related to the entire network and by automatically curing the problem and/or providing a notification (e.g., reporting it) to the appropriate representative and/or field engineer.
• In one embodiment, to accommodate the real-time and large volume of information that is being generated by many (e.g., millions) of subscribers, the measurements megastore140 uses a massive parallel processing technology such as Hadoop, Storm, or Spark. In addition, machine learning components are used to identify patterns and trends based on pre-determined training sets. In one embodiment, previously unknown problems are detected by different clustering models. For example, data is grouped in such a way wherein objects in the same group (i.e., cluster) are more similar to each other than to those in other groups (i.e., clusters).
• FIG. 6 is a block diagram a data framework, consistent with an exemplary embodiment. The data framework ofFIG. 6 is similar to that ofFIG. 3 discussed above, but has been redrawn for clarity to facilitate the discussion of automatic troubleshooting of radio access networks. The data framework ofFIG. 6 includes adata processing layer682, anintelligence layer684 that may include programmable pattern detection rules688, anautomation layer686 that is configured to store programmable set of actions based on theproblem type690, and ameasurements megastore680.
• The type of information received by thedata processing layer682 may include, among other elements: data from a customer care trouble ticket database; network element counters and KPIs; network element (UE) location; alarm and fault information; subscriber information, including subscriber plans, utilization (e.g., minutes/data), billing address, etc.; handset information, including handset type, OS, apps, battery status, etc.; subscriber detailed information records, including Geolocation, radio, core network and IP level traces; Wi-Fi records and metrics, etc. Thedata processing layer682 may be performed in real time and/or in batch. The monitoring may be performed continuously, 24 hours a day, 7 days a week, at predetermined intervals, or in response to a trigger from the intelligence layer384 of the monitoring system. Thus, thedata processing layer682 monitors detailed subscriber traces, and records fault situations, such as a dropped call, an access failure, or a problem with Internet connectivity. This data is stored in the measurements megastore680 together with data from other network elements as contextual information that may be used by various network elements.
• Theintelligence layer684 is configured to receive the information from thedata processing layer684 and pattern detection rules688 that may be preprogrammed in theintelligence layer684. In one embodiment, theintelligence layer684 may include different intelligence models for different types of failures. Theintelligence layer684 is configured to identify a probable cause of a problem as well as an estimation of accuracy (error) for the error detection. In one embodiment, the accuracy of the detection is based on the frequency of the occurrence of the error.
• For example, the estimation of accuracy may be high when a customer may be experiencing degraded performance (drops, access failures, etc.) in an area that has been identified by the intelligence layer to be undergoing maintenance or where there is a known lack of coverage. The intelligence layer may further improve the accuracy by reviewing the customer trace, network health indicators, and the UE reports, etc. From the disparate sources of data, theintelligence layer684 can identify whether the drop is due to (1) coverage, (2) interference, (3) hardware failure, (4) software failure, etc.
• Theautomation layer686 may trigger an automatic response to an identified network error without having to rely on prior human processing of the raw data harvested by thedata processing layer682. In one embodiment, the appropriate action for an identified problem is pre-programmed by a system administrator at the intelligence layer or at the network element node. The action may be a resetting of a node or sending a note to the field engineer with the identified problem and potential solution. In other cases, the automated action may be to send a message to the subscriber, notifying them of the cause of the problem (e.g., there is ongoing maintenance work in the area), or providing an automatic credit to compensate for the degraded performance and notifying the subscriber of the same.
• In one example, where multiple subscribers suffer a substantially similar problem in one area, theautomation layer686 may automatically send a message to all subscribers in that area to prophylactically cure the problem before the subscribers are affected by the problem. Put differently upon determining that a group of other network elements in an area of the first network element meet a predetermined condition or exceed a predetermined threshold, a notification is automatically sent to all network elements in that group. In one embodiment, network errors that are identified with an accuracy below a first threshold are treated differently from those with an accuracy of above a second threshold. In one embodiment, the first and second threshold have the same value. For example, if an error has been detected that is deemed to be of low accuracy, an automatic action may not be performed until additional data is received to improve the accuracy and/or the subscriber calls about the problem. However, if the error is identified with a high accuracy, automatic immediate remedial measures are undertaken.
• For example, theautomation layer686 in cooperation with theintelligence layer684 may propose a palliating action upon determining that a particular subscriber is not receiving the expected quality of service. In case of a coverage problem, the intelligence layer may determine whether there is an option to use Wi-Fi calling. In this regard, theautomation layer686 may send a notification to the subscriber and care representative to facilitate the activation of Wi-Fi calling.
• FIG. 7 illustrates an example model for an automatic root cause identification. Specifically,FIG. 7 illustrates a probability tree that stores information as to the probable root cause for a dropped call. Based on a large corpus of data, a machine learning algorithm can determine the probabilities that an event, such as a dropped call, was correlated to a particular cause. In turn, a particular cause, may have different potential causes of its own, each with their own probabilities. Eventually, the probability of a root cause, may be discerned.
• InFIG. 7, we start at the top of the probability tree with adropped call event702. Every event is associated with a probability P(Event). For example the probability that a detected network event could be a dropped call is illustrated as P(Yes)=0.15 (or 15%). The probability that the detected network event is some other event is P(No)=0.85.
• The probability tree may then be traversed to determine the most likely root causes. To do so, the probability tree is traversed to the nodes representing potential immediate causes for thedropped call event702. These may includeradio interference704,poor coverage706,hardware failure708,software failure710, orother failures712. As with the dropped call event, each cause is associated with a probability. Because, these causes are potential causes, the probabilities are expressed as conditional probabilities P(Condition|Event). For example, the probability that a dropped call was caused by ahardware failure708 is shown as P(HW|DC)=0.2. Similarly, the probability that a dropped call was caused by asoftware failure710 is shown as P(SW|DC)=0.3.
• Cause nodes may in turn have their own respective causes. For example,radio interference704 andpoor coverage706 may have the same cause714.Hardware failure708 may have different possible causes, here shown as aphysical error716 and misconfiguration of user equipment718. Again, the each node is associated with a respective probability, and as potential causes, each probability is expressed as a conditional probability. Here the probability that a physical error in thehardware716 caused a hardware failure is shown as P(PH|HW)=0.1. The probability that the hardware was misconfigured718 caused the hardware failure is shown as P(MCG|HW)=0.6.
• Note that asoftware failure710 may also be caused by misconfiguration718. Even though the probability tree traverses to a node also traversable fromhardware failure708, the misconfiguration node718 has its own probability as the cause of asoftware failure710 as shown as P(MCG|SW)=0.3. Asoftware failure710 may also be caused by having a wrong version of software installed720, with a causal conditional probability of P(WVER|SW)=0.5.
• Similarly,other causes712, may have their own respective causes722.
• A probability tree is generally populated via receiving a statistically significant corpus of data. The data is then applied to the probability tree to compute the probabilities in the probability tree.
• When performing a diagnosis, the probability tree starts with the causes and/or KPI leaf nodes724,726,728,730,732. Depending on the network data observed, the probabilities of the causes and/or KPI leaf nodes724,726,728,730,732 are updated. For example, if a misconfiguration is actually observed, the probability of the misconfiguration728 is changed to 100%. If a cause724 is not observed, that probability is changed to 0%. Probabilities need not be binary, i.e. solely 100% or 0%. Intermediate (non 0% non 100%) probabilities may be computed based on a sampling or running average of data.
• Once the causes and/or KPI leaf nodes724,726,728,730,732 are updated, the parent node probabilities are updated according to Bayes Algorithm. Thus the conditional probabilities of theparent nodes714,716,718,720 and722 are updated using the child node as a determination as to whether a condition was satisfied. The probabilities of theparent nodes714,716,718,720 and722 are then updated. This process is repeated for the level of parent nodes above, until theroot node702 is reached. At this point, all the probabilities in the probability tree have been updated in light of the observed causes and/or KPIs724,726,728,730,732.
• Potential root causes of the root node, the dropped call,702 will be surfaced to a user by selecting all child nodes with updated probabilities exceeding a predetermined threshold.
• After finishing analysis, the probability tree is returned to its original state and original probabilities.
• However, over time the historical data may be collected and upon agreement by an administrator, at least a subset of the historical data may be applied to the probability tree to permanently update the probabilities in the probability tree. Subsequent analyses will then use the updated probability tree. In this way, the probability tree learns from historical data.
• It is to be emphasized that this particular approach in machine learning is but one option. Other well-known options include entropy based trees and naïve-Bayesian trees. One advantage peculiar to a Bayesian based tree is that the domain of causes and/or KPIs may be partitioned into sub-domains without forcing re-computation of the probabilities. Accordingly, a probability tree may be partitioned for different subsets of the network as desired by the administrator.
• FIG. 8 is a flow diagram of an example process for assisting an engineer in maintaining a radio access network performance. Instep802, data is automatically collected from various sources into a common data framework that is stored in the measurements megastore. Instep804, a pattern recognition is performed on the data by one or more clustering algorithms. In one embodiment, instep806, the key metrics to be analyzed are preprogrammed in the measurements megastore or are interactively provided to the measurements megastore via a user interface900 (seeFIG. 9) by an operator. Theuser interface900 may be via a software application on a terminal or a handheld device that is communicatively coupled either directly or wirelessly to the measurements megastore140 ofFIG. 1. In various embodiments, the engineer can select (e.g.,904) the type of analysis to be performed and the level of detail to be reported, both at the network element (e.g., geographical/node level) and at the KPI level.
• There are an unlimited number of patterns that the measurements megastore may detect. For example, an area with a high churn rate may show that most of the subscribers are concentrated in a small geographical area. A sector experiencing degraded performance may indicate a high number of resets in a specific time period. A large number of customers who call customer care may show the number of calls that are being routed directly to voice mail to be exceeding a predetermined threshold limit. An area indicating a drop call rate that is within a predetermined threshold, may indicate a number of instances in which customers had to re-dial within a predetermined time, to exceed a threshold limit (which may indicate a poor call quality). A sector may indicate congestion despite carrying traffic that is below a threshold limit. A threshold number of customers may experience their coverage shrink after a network upgrade. Of course, countless other scenarios are supported.
• Instep808, relevant patterns, as they are learned, are persisted, for example in a memory of themeasurements megastore140. In one embodiment the measurements megastore140 displays the analysis results, comprising the most relevant patterns, to the engineer on theuser interface900. In another embodiment, patterns that are associated with automated fixes, may trigger the execution of those automated fixes.
• In one embodiment, instep810, the engineer may rate the analysis results of the measurements megastore. In this regardFIG. 900 illustrates by way of example an interface that may be used by an engineer to rate the relevance of the analysis (e.g., discovery) of the measurements megastore by a selection of 1 to 5stars906. In various embodiments, the selection may be performed after the engineer has confirmed and cured the network issue, or upon initial display on theuser interface900.
• In one embodiment, instep810, the engineer may request an automatic KPI and/or a notification to be issued based on the analysis. The KPI may be stored in the measurements megastore and used as a reference. The KPIs and notifications may can be used to predict events, such as when an area will likely increase its churn level.
• In one embodiment, instep812, the system described above can be trained, where it automatically repeats prior analysis based on prior similar circumstances and generates similar KPI's and/or alarms continuously, at predetermined intervals, or when a specific error is identified. In one example, intelligence layer of the system described herein may be combined with a self-organizing network (SON), to perform automatic planning, configuration, management, optimization, and healing of the radio access network.
Example Use Case in the Medical Field
• As discussed above, in one aspect, the system described herein provides an open platform where multiple data feeds from disparate sources can be combined and processed in real time. Much of the preceding discussion has been towards application in network management. However, the techniques described herein provide a learning and feedback loop that may be applied to any field where there is a stream of event data, where the event data may be classified into categories that may be correlated with causes. Where a probability tree can be constructed, the preceding techniques may be applied.
• One example alternative field where this capability is particularly useful is in the medical field, which increasingly uses health monitors, such asUE102d, which may be worn by both the healthy and ill to monitor the medical well-being of the wearer. Today, one or more of such health monitors can be worn to provide a range of medical analysis of a user (sometimes referred to herein as a patient or subscriber) and provided to an appropriate caregiver to extract the relevant information from the one or more health monitors.
• These health monitors can come in a variety of forms, such as implanted, worn on the wrist, worn around the neck as a necklace, strapped around the chest, etc., These monitors can monitor a variety of health functions, such as heart rate, heart rhythm, blood pressure, motion, oxygen saturation, temperature, glucose level, etc. Traditionally, each health monitor operates in isolation. For example, the health monitor that measures the heart rate is mutually exclusive from the health monitor that measures the glucose level or motion. The data points that are acquired are then provided either directly to the patient on a user display or stored in a memory of the health monitor, respectively, to be later read by one or more caregivers. In some cases, the acquired data is sent periodically, or upon trigger from the user, to disparate receivers at one or more caregivers. Each health monitor is typically applied in response to a health ailment suspected by the caregiver. Accordingly, in traditional systems, a continuous monitoring that provided a synthesis of the information from the health monitors to identify unsuspected health conditions is not available.
• In contrast, the system described herein is capable of performing continuous monitoring and/or continuous transmission of the monitored data from each health monitor, which can be synthesized at a centralized remotehealth monitoring system150. The synthesized information harvested from the disparate sources is configured to analyze the data for potential ailments and provide relevant notifications.
• Reference now is made toFIG. 10, which illustrates a high level diagram of a system that includes remote health monitoring, consistent with an exemplary embodiment. Insystem1000 one or more health monitors, represented by UEs1002(1) to1002(N), are operative to monitor various aspects of the health ofuser1004. The health monitors1002(1) to1002(N) can provide the health information to one or more disparate monitoring systems, represented insystem1000 byapplication servers1,2 (1030,1032), andUE collection systems1 to N (1034(1) to1034(N)). For example,application servers1,2 (1030,1032), andUE collection systems1 to N (1034(1) to1034(N)) may be regarded as third party systems that provide health related recordings of measurements from corresponding health monitors, which may be in the form of a Samsung Gear Watch or Apple iWatch.
• The health information may be provided by various networks. For example, some health monitors may communicate with their monitoring system over one radio access network1022(a) while other health monitor may communicate over another radio access network1022(b). In one embodiment, a health monitor may communicate with their respective (e.g., subscribed) monitoring system over a radio access network1022(a) by using a device that is configured to communicate over the network1022(a), such as a smart phone, tablet, etc. In one embodiment, the health monitors1002(1) to1002(N) provide the health information directly to thehealth monitoring server150.
• In one aspect, theexample system1000 is compliant with the Health Insurance Portability and Accountability Act (HIPPA) in that physical and technical safeguards are included to limit the access to the remote health monitoring server to only authorized individuals and account holders. In one example, unique user IDs, automatic log off procedures, encryption, and decryption are required to access thesystem1000.
• In one aspect, the remotehealth monitoring server150 acts as a measurements megastore and provides an open platform where the multiple data feeds from thedisparate servers1030,1032 and collection systems1034(1) to1034(N) are combined. The health data is processed in real time, for many (e.g., millions) of individuals likeuser1004 by a data processing layer, which may be part of thehealth monitoring server150 or in communication therewith. In addition, the remotehealth monitoring server150 may gather data, such as patient records fromhospitals1040 andcare providers1050. Such data may include medical history, prior treatments, recorded blood-work, etc. In addition, the remote health monitoring server may gather data from the radio access network (e.g.,1022(a),1022(b)) to determine the location information of theuser1004, identify network issues that may prevent data transmission, and other variables affecting network connectivity and the customer endpoints. In various embodiments, the location of theuser1004 may be determined by various techniques, such as triangulation, multilateration, and/or the GPS coordinates that may be provided by the health monitor (e.g.,1002(1) to1002(N)), or its corresponding UE (e.g.,1006).
• The data from the disparate monitors is analyzed for patterns and trends. Upon determining that that one or more thresholds are exceeded or one or more criteria are met, the remotehealth monitoring server150 may send a notification to theuser1004 via a notification to a user interface of the corresponding health monitor (e.g., UE1002(1)) or corresponding UE networkcapable device1006. In one embodiment, thehealth monitor server150 may send a notification to arelevant care provider1050 and/or hospital, based on the type of condition.
• FIG. 11 is a block diagram of a data framework of a monitoring system, consistent with an exemplary embodiment. The data framework insystem1100 uses massive parallel processing methods to gather health data from one or more health monitors (UE's) in real time. To facilitate the discussion, theautomation layer1108, the intelligence layer11104, and thedata processing layer1102 is illustrated as being separate from themeasurements megastore1110, while it will be understood, that in various embodiments, these the functions may be combined on a single platform (i.e., a single measurements megastore that performs the features of the data processing layer, intelligence layer, and automation layer.)
• The data framework includes adata processing layer1102, anintelligence layer1104, which may includepattern detection rules1106, anautomation layer1108 and ameasurements megastore1110. The type of information received by thedata processing layer352 may include subscriber radio trace (e.g., location) provided by a UE and/or the radio access network, healthcare records from one or more sources, customer care records, billing, application performance monitoring reports, and other information, including relevant information from the WEB. Thedata processing layer1102 may be performed in real time and/or in batch. The monitoring may be performed continuously, 24 hours a day, 7 days a week, at predetermined intervals, or in response to a trigger from theintelligence layer1104 of the monitoring system.
• Theintelligence layer1104 is configured to receive the information from thedata processing layer1102 andpattern detection rules1106 that may be preprogrammed in the intelligence layer. In one embodiment, the detections may be originally programmed by expert professionals, based on prior knowledge. A self-learning feature of the intelligence layer is operative to detect abnormal conditions without previous knowledge of that particular problem. Specifically, causes and/or KPIs may be detected as present when undesirable events, such as dropped calls occur. As described with respect toFIG. 7, a probability tree may be populated and/or updated to store the probabilities that those causes and/or KPIs are correlated with the undesirable event. In one embodiment, thepattern detection rules1106 are different depending on the type of patient (e.g., leukemia vs. diabetes). For example, the health monitoring system, upon identifying patterns that are consistent with a medical condition, may update its rule set to focus on that condition by performing more analysis of the health data related to that medical condition. Thus, thepattern detection rules1106 may be different from one subscribed user to the next.
• To detect a specific condition, multiple data sources that were processed at thedata processing layer1102 may be analyzed and cross-correlated to determine whether one or more conditions are met. Specifically, first detected causes and/or KPIs are checked against a probability tree (see the discussion with respect toFIG. 7) whether they could possibly be a root cause for detected undesirable network events, such as dropped calls. Then the probability tree is traversed starting with the detected causes and/or KPIs. Since the probability tree stores probabilities, that the detected causes and/or KPIs caused an event, the probability tree can be traversed according to the most probable paths. In this way, conditions for undesirable network conditions may be evaluated as to the likelihood that particular causes and/or KPIs (and other events/causes along the path in the probability tree) in fact caused those undesirable network conditions.
• Thus, theintelligence layer1104 constantly sifts through the data to identify patterns within the disparate data sources. When a predetermined condition is met, the intelligence layer may generate a relevant alert to at least one of the user604, the care provider650, a contact person previously stored in the database of themeasurements megastore1110, and/or an emergency service. For example, theintelligence layer1104 may analyze the patterns of the data for individual types of measurements (blood pressure), or cross-correlate with different types of measurements or data (e.g., glucose level, weight, age, white blood cells, etc.,) provided by thedata processing layer352 and family history from themeasurements megastore1110, to identify any outliers (e.g., meeting a predetermined condition or exceeding a predetermined threshold) that may indicate a health concern with the patient.
• Accordingly, theautomation layer1108 may trigger an automatic response to the identified condition of the patient604 without having to rely on prior human processing of the raw data harvested by the data processing layer. Put differently, the intelligence layer coupled with theautomation layer1108 can detect health problems at a subscriber (i.e., patient) level and provide a notification without the subscriber or the health care provider having even suspected a health problem with the subscriber. An authorized care giver, medical practitioner, family and friends, or emergency response may be automatically contacted based on the preferences stored in a user profile stored in themeasurements megastore1110. For example, the medical practitioner211amay provide immediate medical advice. The appropriate entity may be contacted automatically via the applicationserver automation layer1108 of themeasurements megastore1110. The appropriate entity may be contacted through theradio access network122, through a public switched telephone network (PSTN) (not shown), or through an internet connection (120 inFIG. 1). In one example, different information is sent depending on the receiving entity. For example, when family/friends are contacted, the location information and the type of emergency may be sent. In contrast, when a medical practitioner is contacted, the location information, type of emergency, vital signs, medical history, etc., are sent. Thus, while different entities may be contacted for help, only specifically authorized entities receive the location information. In one example, the location information is used to send a prescription information to the closest pharmacy to the health monitor (e.g.,102dinFIG. 1).
• FIG. 12 is a flow diagram of an example process for identifying a health condition using contextual information received from a measurements megastore. Consider a subscriber (who believes to be healthy) to be wearing one or more health monitors. For example, the health monitors may be an electronic fitness bracelet, an electronic necklace that can measure temperature/humidity, and a smart phone that is placed on the bed where the subscriber is resting. Further, the subscriber indicates on an app of the smartphone that the phone is placed on his bed, thereby allowing it to monitor his or her sleeping pattern.
• Instep1204 the measurements megastore may receive continuous information from all three sensors. For example, the smart phone may provide the location information from its global positioning system (GPS) and movement information from its accelerometer; the electronic fitness bracelet may provide the heart rate and movement information from its accelerometer; and the electronic necklace may provide a measurement of the temperature of the subscriber. In various embodiments, the health information may be received by the measurements megastore over different radio access networks and collection systems, as discussed in the context ofFIG. 6 above. In particular, the health information may be received by the data processing layer of the data framework that includes a measurements megastore.
• Instep1206, the intelligence layer of the measurements megastore analyzes the health information to determine whether there is a high level of movement. For example, it may correlate the movement information from the fitness bracelet with the information from the smartphone. If both sources indicate that there is no high level of movement, the intelligence layer concludes that there are no health issues in connection with sleep apnea (i.e., step1210). However, if one of the sources indicates a high level of movement which is not confirmed by the second source, the intelligence layer may consult the WEB to determine whether the smartphone or the fitness bracelet has a more accurate accelerometer, and base its analysis regarding movement on the more accurate fitness monitor for this measurement.
• If the intelligence layer of the measurements megastore identifies a high level of movement, it then determines whether there is a high heart rate. To that end, instep1208, the intelligence layer analyzes the health information obtained from the fitness bracelet. In one embodiment, the intelligence layer may consult the WEB (or a lookup table) and/or other previously stored data to determine what is considered a high heart rate for this subscriber. For example, the stored information may indicate the weight, height, and age of the subscriber and previous medical conditions that may affect the heart rate (e.g., pace-maker). If the heart rate is not considered high for this subscriber, the intelligence layer concludes that there are no health issues in connection with sleep apnea (i.e., step1210).
• If the heart rate is determined to be high, instep1212, the intelligence layer interacts with the automation layer to provide a notification to one or more recipients (e.g., the smartphone, the fitness bracelet, authorized care giver, medical practitioner, family and friends, and/or emergency response), depending on the severity of the condition or predetermined personal preferences of the subscriber. For example, the subscriber may receive a notification on their smart phone indicating that they may be suffering from sleep apnea. The automation layer may also recommend one or more additional health monitors to better analyze the medical condition, which may be used in subsequent measurements (i.e., step1214).
Example Computer Platform
• As shown by the above discussion, functions for storing contextual information, monitoring network elements, remote monitoring of subscribers' health, identifying a network status based on local knowledge, providing a connection between network elements, and other functions, can be implemented on computers connected for data communication via the network elements of theradio access network122, operating as themonitoring server130, measurements megastore140,eNode B119, and components of theradio access network122, as shown inFIGS. 1 and 2. Although special purpose devices may be used, such devices also may be implemented using one or more hardware platforms intended to represent a general class of data processing device commonly used to run “server” programming so as to implement the receiving data from disparate sources from, retrieving contextual information, analyzing information for determining whether a predetermined condition is met or a predetermined threshold is exceeded, and providing notifications, as discussed above, albeit with an appropriate network connection for data communication.
• FIGS. 13 and 14 provide functional block diagram illustrations of general purpose computer hardware platforms.FIG. 13 illustrates a network or host computer platform, as may typically be used to implement a server.FIG. 14 depicts a device with user interface elements, as may be used to implement a personal computer, such ascomputer102cofFIG. 1 or a workstation, or to implement a computing device, such as a portable handset, a smart-phone, tablet computer, a personal digital assistant or other type of mobile station or mobile terminal device (e.g.,devices102ato102dofFIG. 1), although the device ofFIG. 14 may also act as a server if appropriately programmed. It is believed that the general structure and general operation of such equipment as shown inFIGS. 13 and 14 should be self-explanatory from the high-level illustrations.
• A general purpose computer configured as a server, for example, includes a data communication interface for packet data communication. The server computer also includes a central processing unit (CPU), in the form of one or more processors, for executing program instructions. The server platform typically includes an internal communication bus, program storage and data storage for various data files to be processed and/or communicated by the server, although the server often receives programming and data via network communications. The hardware elements, operating systems and programming languages of such servers are conventional in nature. As used herein, the computer system ofFIG. 14 uses a massive parallel processing technology such as Hadoop, Storm, or Spark. Of course, the server functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load. In various other embodiments, the functionality of themonitoring server130, measurements megastore140, and the remote health monitoring system, may be combined in one or more server platforms.
• The software functionalities involve programming, including executable code as well as associated stored data, e.g., files used for applications on the computing device to receive data from disparate sources by the processing layer, retrieving contextual information from the measurements megastore, analyzing the data from disparate sources and the contextual information, and providing notifications. The software code is executable by the computing device. In operation, the code is stored within the computing device. At other times, however, the software may be stored at other locations and/or transported for loading into the appropriate computing device system. Execution of such code by a processor of the computing device enables the computing device to perform functions of retrieving information, analyzing the information, providing notifications, etc., in essentially the manner performed in the implementations discussed and illustrated herein.
• Hence, aspects of the methods of receiving and processing SUs as outlined above may be embodied in programming. Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and/or associated data that is carried on or embodied in a type of non-transitory machine readable medium.
CONCLUSION
• While the foregoing has described what are considered to be the best mode and/or other examples, it is understood that various modifications may be made therein and that the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be applied in numerous applications, only some of which have been described herein. It is intended by the following claims to claim any and all applications, modifications and variations that fall within the true scope of the present teachings.
• Unless otherwise stated, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications that are set forth in this specification, including in the claims that follow, are approximate, not exact. They are intended to have a reasonable range that is consistent with the functions to which they relate and with what is customary in the art to which they pertain.
• Except as stated immediately above, nothing that has been stated or illustrated is intended or should be interpreted to cause a dedication of any component, step, feature, object, benefit, advantage, or equivalent to the public, regardless of whether it is or is not recited in the claims.
• It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein. Relational terms such as first and second and the like may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “a” or “an” does not, without further constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.
• The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.

Claims (36)

What is claimed is:

1. A computer system comprising:

a processor;

a network interface coupled to the processor configured to enable communications via a communication network;

a storage device for content and programming; and

a program stored in the storage device having a data processing layer and an intelligence layer, wherein execution of the program by the processor configures the computer system to perform acts comprising:

receiving data from disparate sources related to a first network element by the processing layer;

retrieving a contextual information from a measurements megastore related to the first network element and other network elements;

analyzing the data from disparate sources and the contextual information by the intelligence layer; and

upon determining, by the intelligence layer, that a predetermined condition is met or a predetermined threshold is exceeded, providing a notification to the first network element.

2. The computer system ofclaim 1, wherein the storage device further includes an automation layer and the notification is provided by the automation layer.

3. The computer system ofclaim 1, wherein the notification is provided to one or more other network elements.

4. The computer system ofclaim 1, wherein execution of the program further configures the computer system to perform acts comprising:

upon determining that a group of other network elements in an area of the first network element meet the predetermined condition or exceed the predetermined threshold, automatically sending the notification to the network elements to the group of other network elements.

5. The computer system ofclaim 1, wherein the contextual information includes at least one of: (i) a type of a data plan of a subscriber of the network, and (ii) a type of first network element.

6. The computer system ofclaim 1, wherein the data from the disparate sources includes at least one of: (i) a subscriber radio trace, (ii) an operations subsystem (OSS), (iii) a customer care record, (iv) a billing information, and (iv) an application performance monitoring report.

7. The computer system ofclaim 1, wherein at least some of the disparate sources provide data to the processing layer, which is based on the local knowledge of the network of the at least some disparate sources, respectively.

8. The computer system ofclaim 1, wherein the analyzing by the intelligence layer includes determining patters or trends across the disparate data from the disparate sources and the contextual information.

9. The computer system ofclaim 1, wherein the disparate sources comprise network elements from one or more radio access networks.

10. The computer system ofclaim 1:

wherein the analyzing by the intelligence layer includes considering a network element subscriber's predetermined preferences, limitations, plan, and type of network element, and

wherein the network element is a mobile device that is subscribed to be used on the network.

11. The computer system ofclaim 1, wherein execution of the program further configures the computer system to perform acts comprising:

making the contextual information available to the first network element and the other network elements before analyzing the information.

12. The computer system ofclaim 10, wherein the contextual information includes general information on subscribers and network nodes.

13. The computer system ofclaim 1, wherein the contextual information is provided to the first network element via a query performed by the first network element to the measurements megastore via an open application program interface (API).

14. The computer system ofclaim 1, wherein the notification includes information that is operative to adjust a performance of the first network element.

15. The computer system ofclaim 1, wherein:

the network element is a resource management module; and

the notification is operative to adjust at least one of: (i) a scheduler, (ii) a link adaptation, and (iii) a flow control of the resource management module.

16. The computer system ofclaim 1, wherein the notification is operative to display on a user interface of the first network element that the first network element needs service.

17. The computer system ofclaim 1, wherein the contextual information is used to adjust at least one of: (i) an admission control, (ii) a scheduler, (iii) a link adaptation, and (iv) a power control procedure of the first network element.

18. The computer system ofclaim 1, wherein the notification is provided to a network administrator in real time.

19. The computer system ofclaim 1, wherein the data processing of the data processing layer is performed in real time.

20. The computer system ofclaim 1, wherein:

the notification is operative to place a restriction on one or more network elements; and

the restriction is lifted after a threshold time has elapsed or upon a new notification operative to remove the restriction is sent to the one or more network elements.

21. The computer system ofclaim 1, wherein the measurements megastore uses massive parallel processing technology of at least one of: (i) Hadoop, (ii) Storm, and (iii) Spark.

22. The computer system ofclaim 21, wherein execution of the program further configures the computer system to perform acts comprising:

machine learning via one or more clustering models performed on a pre-determined training set by the intelligence layer and operative to identify patterns and trends in the data from the disparate sources and the contextual information.

23. A network element comprising:

a processor;

a network interface coupled to the processor configured to enable communications via a communication network;

a storage device for content and programming; and

a program stored in the storage device having a data processing layer and an intelligence layer, wherein execution of the program by the processor configures the network element to perform acts comprising:

determining local radio resources on the network;

receiving contextual information from a measurements megastore, wherein the contextual information is related to radio resources of other network elements on the network; and

adjusting a resource allocation based on the local radio resources and the received contextual information.

24. The network element ofclaim 23, wherein the measurements megastore uses massive parallel processing technology of at least one of: (i) Hadoop, (ii) Storm, and (iii) Spark.

25. The computer system ofclaim 23, wherein execution of the program further configures the network element to perform acts comprising:

receiving one or more notifications from a data framework associated with the measure measurements megastore, wherein the one or more notifications are based on an analysis of the contextual information for patterns and trends; and

assigning one or more resources of the network element based on the notification.

26. The computer system ofclaim 23, wherein execution of the program further configures the network element to perform acts comprising:

providing the determined local radio resources to a measurements megastore via the network.

27. A monitoring server configured to determine a root cause of a communication network error, the server comprising:

a processor;

a network interface coupled to the processor configured to enable communications via the communication network;

a storage device for content and programming; and

a program stored in the storage device having, wherein execution of the program by the processor configures the monitoring server to perform acts comprising:

collecting disparate data from disparate sources into a common data framework;

receiving key metrics to be analyzed from a selection performed on a user interface of a network element;

analyzing the disparate data from the disparate sources via one or more clustering algorithms operative to identify at least one of patterns and trends;

providing at least one of the identified patterns and trends to the user interface of the network element;

receiving ratings on at least one of the identified patterns and trends from the user interface of the network element;

automatically sending a notification and key performance indicator (KPI); and

saving the KPI in a measurements megastore.

28. A health monitoring server configured to monitor a health of a subscriber, the server comprising:

a processor;

a network interface coupled to the processor configured to enable communications via a communication network;

a storage device for content and programming; and

a program stored in the storage device having a data processing layer and an intelligence layer, wherein execution of the program by the processor configures the computer system to perform acts comprising:

receiving disparate data related to the subscriber's health from disparate sources;

retrieving a contextual information from a measurements megastore related to the health of the subscriber;

analyzing the information from the disparate sources and the measurements megastore for at least one of patterns and trends; and

upon determining that one or more thresholds are exceeded or one or more criteria are met, generating a notification.

29. The health monitoring server ofclaim 28, wherein the notification is sent to at least one of the disparate sources of the disparate data.

30. The health monitoring server ofclaim 28, wherein the disparate data from the disparate sources includes at least one of: a subscriber radio trace, healthcare records from one or more sources, customer care records, billing, and application performance monitoring reports.

31. The health monitoring server ofclaim 28, wherein the sources of the data include one or more implanted or worn personal health monitors of the subscriber, and records from a server storing personal health information of the subscriber.

32. The health monitoring server ofclaim 28, wherein the disparate data is first received from one or more application servers and collection systems over one or more networks before being received by the remote health monitoring server.

33. The health monitoring server ofclaim 28, wherein the disparate data is received at least in part from one or more health monitors configured to measure at least one of: heart rate, blood pressure, motion, oxygen saturation, temperature, and glucose level.

34. The health monitoring server ofclaim 28, wherein the health monitoring server is configured to provide an open platform wherein the disparate data from the disparate sources are combined and processed in real time.

35. The computer system ofclaim 28, wherein execution of the program further configures the monitoring server to perform acts comprising:

determining a location information of the subscriber;

identifying any network issues that may prevent data transmission or connectivity; and

upon determining that there is a network issue, preventing the determination of whether one or more thresholds are exceeded or one or more criteria are met to prevent a false alarm.

36. The computer system ofclaim 28, wherein the notification is sent to at least one of: the subscriber, a care provided, a contact person previously stored in a database of the measurements megastore, and an emergency service.

Images