Patent Application
20140066052
User devices, such as mobile phones, may run various applications that perform various tasks (e.g., a productivity application, a gaming application, a news application, a weather application, etc.). An application may communicate with a network in order to perform the tasks.
The following detailed description of example embodiments refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
An application, running on a user device (such as a mobile phone), may cause a problem on the user device, or may cause a problem with a network to which the user device is connected. For example, the application may cause the user device to lose a connection to the network. A network provider may want to determine a cause of the problem, or factors that contribute to the problem, such as parameters of the user device when the connection was lost (e.g., a signal strength of the user device, a quantity of applications running on the user device, etc.).
In order to determine a cause of the problem, the network provider may collect information from the user device running the application. However, collecting the information from a single user device or a small quantity of user devices may not reveal a cause of the problem. The network provider may be able to better determine a cause of the problem if the network provider collects information from a large quantity of user devices (e.g., ten or more user devices, one hundred or more user devices, one thousand or more user devices, one million or more user devices, etc.). Implementations described herein may enable a network provider to more accurately diagnose problems caused by an application by collecting information associated with the problem from a large quantity of user devices. Additionally, implementations described herein may enable a network provider to more efficiently diagnose application-related problems by automating information collection.
As illustrated in
As further illustrated in
An implementation is described herein as being performed within a long term evolution (“LTE”) network for explanatory purposes. Some implementations may be performed within a network that is not an LTE network, such as a third generation (“3G”) network.
Environment 200 may include an evolved packet system (“EPS”) that includes an LTE network and/or an evolved packet core (“EPC”) that operate based on a third generation partnership project (“3GPP”) wireless communication standard. The LTE network may be a radio access network (“RAN”) that includes one or more base stations 260 that take the form of evolved Node Bs (“eNBs”) via which user device 265 communicates with the EPC. The EPC may include MME 220, PGW 225, and SGW 230 that enable user device 265 to communicate with network 210 and/or an Internet protocol (“IP”) multimedia subsystem (“IMS”) core. The IMS core may include CSCF server 250 and/or application server 255, and may manage authentication, session initiation, account information, profile information, etc., associated with user device 265. PCRF server 235, HSS 240, and AAA server 245 may reside in the EPC and/or the IMS core.
Network 210 may include one or more wired and/or wireless networks. For example, network 210 may include a cellular network, a public land mobile network (“PLMN”), a second generation (“2G”) network, a third generation (“3G”) network, a fourth generation (“4G”) network, a fifth generation (“5G”) network, an LTE network, and/or another network. Additionally, or alternatively, network 210 may include a local area network (“LAN”), a wide area network (“WAN”), a metropolitan area network (“MAN”), a telephone network (e.g., the Public Switched Telephone Network (“PSTN”)), an ad hoc network, an intranet, the Internet, a fiber optic-based network, and/or a combination of these or other types of networks.
MME 220 may include one or more computation and/or communication devices that gather, process, search, store, and/or provide information in a manner described herein. In some implementations, MME 220 may perform operations relating to authentication of user device 265. Additionally, or alternatively, MME 220 may facilitate the selection of a PGW 225 and/or an SGW 230 to serve traffic to and/or from user device 265. MME 220 may perform an operation associated with handing off user device 265 from a first base station 260 to a second base station 260 when user device 265 is transitioning from a cell associated with the first base station 260 to a cell associated with the second base station 260. Additionally, or alternatively, MME 220 may select another MME (not pictured), to which user device 265 should be handed off (e.g., when user device 265 moves out of range of MME 220).
PGW 225 may include one or more computation and/or communication devices that gather, process, search, store, and/or provide information in a manner described herein. PGW 225 may include one or more data processing and/or traffic transfer devices, such as a gateway, a router, a modem, a switch, a firewall, a network interface card (“NIC”), a hub, a bridge, a proxy server, an optical add/drop multiplexer (“OADM”), or any other type of device that processes and/or transfers traffic. In some implementations, PGW 225 may aggregate traffic received from one or more SGWs 230, and may send the aggregated traffic to network 210. Additionally, or alternatively, PGW 225 may receive traffic from network 210 and may send the traffic to user device 265 via SGW 230.
SGW 230 may include one or more computation and/or communication devices that gather, process, search, store, and/or provide information in a manner described herein. SGW 230 may include one or more data processing and/or traffic transfer devices, such as a gateway, a router, a modem, a switch, a firewall, a NIC, a hub, a bridge, a proxy server, an OADM, or any other type of device that processes and/or transfers traffic. In some implementations, SGW 230 may aggregate traffic received from one or more base stations 260 associated with the LTE network, and may send the aggregated traffic to network 210 (e.g., via PGW 225) and/or other network devices associated with the IMS core and/or the EPC. SGW 230 may also receive traffic from network 210 and/or other network devices, and may send the received traffic to user device 265 via base station 260. Additionally, or alternatively, SGW 230 may perform operations associated with handing off user device 265 to and/or from the LTE network.
PCRF server 235 may include one or more server devices, or other types of computation and/or communication devices, that gather, process, search, store, and/or provide information in a manner described herein. In some implementations, PCRF server 235 may establish quality of service and charging (e.g., packet accounting) rules for a communication session based on committed quality of service levels per subscriber, per user device, per service type, per application, etc. PCRF server 235 may receive input (e.g., from the IMS core) regarding users, user devices 265, subscriptions, and/or applications. PCRF server 235 may create quality of service and charging policy rules for the session (e.g., for a user, a subscriber, a user device 265, an application, etc.), and may provide the policy rules to PGW 225, which may handle packets for the communication session with a particular user device 265 (e.g., running a particular application) based on the policy rules.
HSS 240 and/or AAA server 245 may include one or more server devices, or other types of computation and/or communication devices, that gather, process, search, store, and/or provide information in a manner described herein. For example, HSS 240 may manage, update, and/or store, in a memory associated with HSS 240, profile information associated with user device 265 that identifies applications and/or services that are permitted for use by and/or accessible by user device 265, information associated with a user of user device 265 (e.g., a username, a password, a personal identification number (“PIN”), etc.), subscription information, rate information, minutes allowed, bandwidth allocation policy information, and/or other information. AAA server 245 may include a device that performs authentication, authorization, and/or accounting operations associated with a communication session associated with user device 265.
CSCF server 250 may include one or more server devices, or other types of computation and/or communication devices, that gather, process, search, store, and/or provide information in a manner described herein. CSCF server 250 may process and/or route calls to and from user device 265 via the EPC. For example, CSCF server 250 may process calls received from network 210 that are destined for user device 265. In another example, CSCF server 250 may process calls received from user device 265 that are destined for network 210.
Application server 255 may include one or more server devices, or other types of computation and/or communication devices, that gather, process, search, store, and/or provide information in a manner described herein. Application server 255 may host and execute applications and/or services, such as IMS services, and may interface with CSCF server 250. For example, application server 255 may include a telephony application server.
Base station 260 may include one or more devices that receive, process, and/or transmit traffic, such as audio, video, text, and/or other data, destined for and/or received from user device 265. In some implementations, base station 260 may be include an eNB associated with the LTE network that receives traffic from and/or sends traffic to network 210 via PGW 225 and/or SGW 230. Additionally, or alternatively, one or more base stations 260 may be associated with a RAN that is not associated with the LTE network. Base station 260 may send traffic to and/or receive traffic from user device 265 via an air interface. In some implementations, base station 260 may be a small cell, such as a microcell, a picocell, and/or a femtocell.
User device 265 may include any computation and/or communication device, such as a wireless mobile communication device, that is capable of communicating with base station 260 and/or a network (e.g., network 210). For example, user device 265 may include a radiotelephone, a personal communications system (“PCS”) terminal (e.g., that may combine a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (“PDA”) (e.g., that can include a radiotelephone, a pager, Internet/intranet access, etc.), a smart phone, a laptop computer, a tablet computer, a personal gaming system, and/or another type of mobile computation and/or communication device. User device 265 may send traffic to and/or receive traffic from network 210 (e.g., via base station 260, SGW 230, and/or PGW 225).
Monitoring device 270 may include one or more server devices, or other types of computation and/or communication devices, that gather, process, search, store, and/or provide information in a manner described herein. In some implementations, monitoring device 270 may gather information associated with network problems. For example, monitoring device 270 may gather information about an application that causes a problem with network 210, the EPS, the EPC, the IMS core, the LTE network, and/or user device 265. Monitoring device 270 may gather the information from any of the devices and/or networks illustrated in
While shown as being located external to the EPS and the EPC, monitoring device 270 may be implemented within the EPS and/or the EPC. Additionally, or alternatively, while shown as separate from PGW 225, SGW 230, and/or base station 260, monitoring device 270 may be integrated into (and a part of) PGW 225, SGW 230, and/or base station 260.
The number of devices and/or networks illustrated in
Bus 310 may include a path that permits communication among the components of device 300. Processor 320 may include a processor, a microprocessor, and/or any processing logic (e.g., a field-programmable gate array (“FPGA”), an application-specific integrated circuit (“ASIC”), etc.) that interprets and/or executes instructions. In some implementations, processor 320 may include one or more processor cores. Memory 330 may include a random access memory (“RAM”), a read only memory (“ROM”), and/or any type of dynamic or static storage device (e.g., a flash, magnetic, or optical memory) that stores information and/or instructions for use by processor 320.
Input component 340 may include any mechanism that permits a user to input information to device 300 (e.g., a keyboard, a keypad, a mouse, a button, a switch, etc.). Output component 350 may include any mechanism that outputs information from device 300 (e.g., a display, a speaker, one or more light-emitting diodes (“LEDs”), etc.).
Communication interface 360 may include any transceiver-like mechanism, such as a transceiver and/or a separate receiver and transmitter, that enables device 300 to communicate with other devices and/or systems, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. For example, communication interface 360 may include a mechanism for communicating with another device and/or system via a network, such as network 210, the EPS, the EPC, the IMS core, and/or the LTE network. Additionally, or alternatively, communication interface 360 may include a logical component with input and output ports, input and output systems, and/or other input and output components that facilitate the transmission of data to and/or from another device, such as an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (“RF”) interface, a universal serial bus (“USB”) interface, or the like.
Device 300 may perform various operations described herein. Device 300 may perform these operations in response to processor 320 executing software instructions included in a computer-readable medium, such as memory 330. A computer-readable medium may be defined as a non-transitory memory device. A memory device may include space within a single storage device or space spread across multiple storage devices.
Software instructions may be read into memory 330 from another computer-readable medium or from another device via communication interface 360. When executed, software instructions stored in memory 330 may cause processor 320 to perform one or more processes that are described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
The number of components illustrated in
As shown in
In some implementations, monitoring device 270 may identify poor network performance and/or poor device performance by measuring a parameter associated with the network and/or the device, such as latency, packet error rate, jitter, packet delay variation, signal strength, voice quality, video quality, quality of service, call failure rate, call setup success rate, call setup time, bit rate, bandwidth, throughput, and/or any other parameter that may be used to measure network and/or device performance. In some implementations, the parameter may indicate a severity of a network problem and/or a device problem. Monitoring device 270 may use any quantity and/or combination of parameters to identify poor performance. In some implementations, monitoring device 270 may compare a value of a parameter to a threshold to determine that performance is poor.
In some implementations, monitoring device 270 may identify an application that is a cause of the poor performance. For example, monitoring device 270 may determine that a particular application is impacting a parameter associated with poor network and/or device performance, or may determine that a particular application is causing and/or contributing to an undesirable value of a parameter. For example, monitoring device 270 may determine that the particular application is running during poor performance (e.g., based on a parameter value), that the particular application is associated with (e.g., sending or receiving) packets exhibiting poor performance, that a particular application has caused a device to crash, etc.
In some implementations monitoring device 270 may automatically determine an application to monitor, based on an indication of poor network performance. Additionally, or alternatively, monitoring device 270 may determine an application to monitor based on user input.
As further shown in
In some implementations, monitoring device 270 may store (e.g., in memory) a parameter associated with a particular type of network and/or device problem. Monitoring device 270 may receive an indication that a network and/or device is experiencing a particular problem, and may retrieve, from memory, the parameter associated with the particular problem. Additionally, or alternatively, monitoring device 270 may store (e.g., in memory) a parameter associated with a particular application. Monitoring device 270 may receive an indication that a particular application is causing poor performance, and may retrieve, from memory, the parameter associated with the particular application.
In some implementations, the parameter may include information that identifies a user device 265 from which the parameter is collected, such as a device identifier (e.g., an international mobile subscriber identity, an international mobile equipment identity, a mobile equipment identifier, etc.), a device type (e.g., mobile phone, smart phone, tablet, a mobile phone model, a smart phone model, a tablet model, etc.), a device type identifier (e.g., a model number, a serial number, etc.), etc. Additionally, or alternatively, the parameter may include information that identifies a characteristic of a user device 265 from which the parameter is collected, such as a hardware parameter of user device 265 (e.g., a processor included in user device 265, processing power of the processor, an amount of memory included in user device 265, an amount of available memory on user device 265, etc.), a software parameter of user device 265 (e.g., a quantity of applications running on user device 265, an identification of the applications running on user device 265, an amount of device memory being used by the applications running on user device 265, etc.), etc.
In some implementations, the parameter may include information that identifies a location of a user device 265 from which the parameter is collected, such as a geographic location of user device 265 (e.g., identified by latitude and longitude, determined using a global positioning system component and/or a triangulation component, etc.), a cell site associated with user device 265 (e.g., a region associated with one or more base stations 260 that are in communication with user device 265), a network device identifier that identifies a network device that is communicating with user device 265 (e.g., an MME 220, a PGW 225, an SGW 230, a base station 260, etc.), etc.
In some implementations, the parameter may include performance information. For example, the parameter may include a packet error rate associated with user device 265, a packet error rate associated with a network device communicating with user device 265, and/or a packet error rate associated with an application being run by user device 265. The packet error rate may include a quantity of packets that are not received and/or are incorrectly received (e.g., altered due to noise, interference, distortion, packet asynchronization, etc.) at a destination device during a time period. Additionally, or alternatively, the parameter may include latency information, such as a delay between sending a packet from a source device (e.g., base station 260, user device 265, etc.) and receiving the packet at a destination device (e.g., base station 260, user device 265, etc.). Additionally, or alternatively, the parameter may include jitter and/or packet delay variation (e.g., a difference in delay between a set of packets transmitted from a source device to a destination device).
In some implementations, the parameter may include signal strength information. Signal strength information may include a received signal strength indicator (“RSSI”) value associated with a wireless connection (e.g., a wireless connection between base station 260 and user device 265). An RSSI value may represent a measurement of power present in a received radio signal. Additionally, or alternatively, signal strength information may include a signal to interference plus noise ratio (“SINR”) value associated with a wireless connection. An SINR value may measure the quality of a wireless connection, and may be calculated as SINR=P/(I+N), where P represents signal power, I represents interference power, and N represents noise power.
In some implementations, the parameter may include quality information associated with user device 265 and/or an application running on user device 265, such as voice and/or video quality (e.g., calculated using a mean opinion score), a quality of service, etc.
In some implementations, the parameter may include a call failure rate (e.g., a fraction of calls that fail to connect to a desired device), a call setup success rate (e.g., a fraction of calls that successfully connect to a desired device), a call setup time (e.g., a length of time required to establish a call between devices), or the like. Additionally, or alternatively, the parameter determined by monitoring device 270 may include a bit rate, bandwidth, and/or throughput associated with a connection between devices (e.g., measured in kilobits per second, megabits per second, gigabits per second, etc.).
In some implementations, the parameter may include information that identifies a network to which user device 265 is connected (e.g., an LTE network, a 3G network, an SMS network, etc.) and/or a network used by an application running on user device 265. Additionally, or alternatively, the parameter may include an identification of a network process that user device 265 is undergoing, such as a handoff between network devices (e.g., MMEs 220, base stations 260, etc.).
In some implementations, the parameter may include time information, such as a time at which the parameter is measured by user device 265, transmitted by user device 265, and/or received by monitoring device 270. In some implementations, the parameter may be collected before, during, and/or after an application is running on user device 265 (e.g., the application to be monitored).
Returning to
In some implementations, monitoring device 270 may determine the user device 265 based on whether the application to be monitored is installed on user device 265. For example, monitoring device 270 may select a user device 265 from which to collect the parameter when the user device 265 has the application installed and/or present on the user device 265.
In some implementations, monitoring device 270 may determine the user devices 265 based on a geographic location. For example, monitoring device 270 may determine that a particular geographic region is experiencing a problem, and may collect the parameter from user devices 265 located within the geographic region.
In some implementations, monitoring device 270 may determine the user devices 265 based on a user and/or a user profile associated with user device 265. For example, a user may decide to allow monitoring device 270 to collect the parameter from a user device 265 associated with the user, and the user may give express permission for monitoring device 270 to collect the parameter. In some implementations, the user may give permission for monitoring device 270 to collect one set of parameters, and may not give permission to collect another set of parameters.
As further shown in
In some implementations, monitoring device 270 may transmit the information to user devices 265 based on a network condition. For example, monitoring device 270 may transmit the information during offpeak hours (e.g., offpeak hours of a service area in which user devices 265 are located). Additionally, or alternatively, monitoring device 270 may transmit the information to user devices 265 based on device conditions. For example, user device 265 may enter a service associated with poor performance, and monitoring device 270 may transmit the information to user device 265 based on user device 265 entering the service area.
In some implementations, monitoring device 270 may set a quality of service parameter of the application to be run on user device 265. For example, monitoring device 270 may set a quality of service parameter based on a location of user device 265 (e.g., geographic location, service area location, proximity to a network device, etc.), a service subscription associated with user device 265, network conditions, and/or other network parameters. In this way, monitoring device 270 may maintain a performance of user device 265 while the application is running, and may prevent user device 265 from experiencing a performance degradation while running the application.
As still further shown in
As still further shown in
In some implementations, monitoring device 270 may analyze the received information to determine a cause of poor network and/or device performance. For example, monitoring device 270 may determine, using a threshold, whether the monitored application is a cause of and/or a contributor to poor network and/or device performance. For example, monitoring device 270 may determine that the application is a cause of poor network performance when more than half of user devices 265 return a parameter value that is less than (or greater than) a threshold.
As an example, assume that monitoring device 270 sends an instruction to user device 265 to download an application, “App Z,” and monitor a signal strength (e.g., RSSI, SINR, received power level of a signal, etc.) before, during, and after running App Z. Monitoring device 270 may determine that App Z is a cause of poor performance if the signal strength received while App Z is running is less than (e.g., less than by more than a threshold amount) the signal strength before and/or after running App Z. Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the signal strength received after App Z has run is less than (e.g., less than by more than a threshold amount) the signal strength received before App Z has run.
In some implementations, monitoring device 270 may gather the above signal strength information from multiple user devices 265, for example ten (10) user devices 265. Monitoring device 270 may determine that App Z is a cause of poor performance if the signal strength while running App Z is less than the signal strength before and/or after running App Z on more than a threshold quantity of user devices (e.g., more than half, or at least six (6) user devices 265). This example of using a threshold with multiple user devices 265 may be applied to other parameters, and is discussed here with respect to signal strength as an example.
Additionally, or alternatively, monitoring device 270 may aggregate the signal strength received from the ten (10) user devices 265. For example, monitoring device 270 may calculate the average signal strength received from the ten (10) user devices 265. Monitoring device 270 may compare the aggregated value (e.g., the average) to a threshold to determine whether App Z is a cause of poor performance. For example, monitoring device 270 may determine that App Z is a cause of poor performance if the average signal strength while running App Z is less than the average signal strength before and/or after running App Z. This example of using an aggregated and/or average parameter value may be applied to other parameters, and is discussed here with respect to signal strength as an example.
In some implementations, monitoring device 270 may collect location information from user device 265 before, during, and after running App Z. Monitoring device 270 may use the location information to determine whether a change in signal strength is caused by App Z, or caused by the location of user device 265. For example, monitoring device 270 may determine that user device 265 was traveling away from base station 260 while App Z was running, and may determine that App Z was not a cause of the poor performance. This example of using location information to determine that an application is not a cause of poor performance may be applied to other parameters, and is discussed here with respect to signal strength as an example.
As another example, assume that monitoring device 270 sends an instruction to user device 265 to download App Z and monitor a packet error rate before, during, and after running App Z. Monitoring device 270 may determine that App Z is a cause of poor performance if the packet error rate while App Z is running is greater than the packet error rate before and/or after running App Z. Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the packet error rate after App Z has run is greater than (e.g., by more than a threshold amount) the packet error rate before App Z has run.
In some implementations, monitoring device 270 may use multiple parameters to determine whether an application is a cause of poor performance. For example, monitoring device 270 may determine that App Z is a cause of poor performance if the packet error rate while App Z is running is greater than the packet error rate before and/or after running App Z, and if the signal strength while App Z is running is less than the signal strength before and/or after running App Z. This example of using multiple parameters to determine that an application is not a cause of poor performance may be applied to other parameters, and is discussed here with respect to packet error rate and signal strength as an example.
As another example, assume that monitoring device 270 sends an instruction to user device 265 to download App Z and monitor a packet delay and/or a packet delay variation before, during, and after running App Z. Monitoring device 270 may determine that App Z is a cause of poor performance if the packet delay and/or packet delay variation while App Z is running is greater than the packet delay and/or packet delay variation before and/or after running App Z. Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the packet delay and/or packet delay variation after App Z has run is greater than (e.g., by more than a threshold amount) the packet delay and/or packet delay variation before App Z has run.
Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the call failure rate and/or call setup time while App Z is running is greater than the call failure rate and/or call setup time before and/or after running App Z. Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the call failure rate and/or call setup time after App Z has run is greater than (e.g., by more than a threshold amount) the call failure rate and/or call setup time before App Z has run.
Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the call setup success rate while App Z is running is less than the call setup success rate before and/or after running App Z. Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the call setup success rate after App Z has run is less than (e.g., by more than a threshold amount) the call setup success rate before App Z has run.
Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the bit rate, bandwidth, and/or throughput while App Z is running is less than the bit rate, bandwidth, and/or throughput before and/or after running App Z. Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the bit rate, bandwidth, and/or throughput after App Z has run is less than (e.g., by more than a threshold amount) the bit rate, bandwidth, and/or throughput before App Z has run.
Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the voice quality, video quality, and/or quality of service while App Z is running is less than the voice quality, video quality, and/or quality of service before and/or after running App Z. Additionally, or alternatively, monitoring device 270 may determine that App Z is a cause of poor performance if the voice quality, video quality, and/or quality of service after App Z has run is less than (e.g., by more than a threshold amount) the voice quality, video quality, and/or quality of service before App Z has run.
In some implementations, monitoring device 270 may collect a hardware parameter (e.g., processing power, available memory, device type) from user device 265 (e.g., before, during and/or after running App Z). Monitoring device 270 may use the hardware parameter to determine whether poor performance is caused by App Z, or caused by hardware limitations and/or conditions of user device 265. For example, monitoring device 270 may determine that user device 265 has low processing power and/or low memory (e.g., lower than a threshold), and may determine that App Z was not a cause of the poor performance. Additionally, or alternatively, monitoring device 270 may determine that App Z was a cause of the low processing power and/or low memory. Additionally, or alternatively, monitoring device 270 may determine that App Z running on a particular user device (e.g., a device type, a model number, a device with a particular hardware configuration, etc.) is a cause of poor performance.
In some implementations, monitoring device 270 may collect a software parameter from user device 265 (e.g., before, during and/or after running App Z). Monitoring device 270 may use the software parameter to determine whether poor performance is caused by App Z, or caused by software limitations and/or conditions of user device 265. For example, monitoring device 270 may determine that user device 265 is running a large quantity of applications simultaneously (e.g., more than a threshold), and may determine that App Z was not a cause of the poor performance. Additionally, or alternatively, monitoring device 270 may determine that App Z running in conjunction with another particular application is a cause of poor performance.
In some implementations, monitoring device 270 may collect information regarding the type of network (e.g., LTE, 3G, etc.) to which user device is connected before, during, and/or after running App Z. Monitoring device 270 may use the network type to determine whether App Z was a cause of poor performance. For example, monitoring device 270 may determine that App Z was a cause of poor performance if user device 265 is connected to an LTE network before running App Z, and user device 265 is connected to a 3G network during and/or after running App Z.
In some implementations, monitoring device 270 may determine that user device 265 was undergoing a network process (e.g., a handoff between network devices) before, during, and/or after running App Z. Monitoring device 270 may use information associated with the network process to determine whether App Z was a cause of poor performance. For example, monitoring device 270 may determine that App Z was not a cause of poor performance if user device 265 was undergoing a handoff between base stations 260 during the running of App Z.
Returning to
Additionally, or alternatively, monitoring device 270 may transmit an alarm and/or a notification to a device. Additionally, or alternatively, monitoring device 270 may generate a report based on the analysis, and may transmit the report to a device. The device may be associated with network 210, a network operator, an application developer, and/or an end user.
In some implementations, monitoring device 270 may provide information to a device associated with a developer of the application (e.g., indicating that the application causes problems under certain conditions, notifying the developer that the application has been disabled, and/or recommending that the developer fix the application). Additionally, or alternatively, monitoring device 270 may provide information to user devices 265 that include the application (e.g., indicating that the application causes problems under certain conditions, notifying the user that the application has been disabled, and/or recommending that the user not run the application). Additionally, or alternatively, monitoring device 270 may provide information to a network device, such as a network device associated with a network operator.
While a series of blocks has been described with regard to
As shown in
As further shown in
In some implementations, the retrieval and running of the application may be automatic (e.g., may not require user intervention), and a user may have given prior express permission for the automatic retrieval and running of the application. Additionally, or alternatively, user device 265 may receive, from monitoring device 270, an instruction to disable, exit, and/or uninstall one or more other applications while the application is running. Additionally, or alternatively, user device 265 may receive, from monitoring device 270, an instruction to run the application using a particular network (e.g., a 3G network, an LTE network, etc.), or to communicate with a particular network device (e.g., base station 260) when running the application.
As still further shown in
As still further shown in
While a series of blocks has been described with regard to
As illustrated in
Implementations described herein may enable a network provider to more accurately diagnose a cause of a problem due to an application by collecting information associated with the problem from a large quantity of user devices. Additionally, implementations described herein may enable a network provider to more efficiently diagnose a cause of a problem by automating information collection.
The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the embodiments.
As used herein, the term “component” is intended to be broadly construed as hardware, firmware, or a combination of hardware and software.
The term “packet,” as used herein, may refer to a packet, a datagram, a cell, a fragment of a packet, a fragment of a datagram, a fragment of a cell, or any other type or arrangement of data that may be carried at a specified communication layer.
Some implementations are described herein in conjunction with thresholds. The term “greater than” (or similar terms), used to describe a relationship of a value to a threshold, may be used interchangeably with the term “greater than or equal to.” Similarly, the term “less than” (or similar terms), used to describe a relationship of a value to a threshold, may be used interchangeably with the term “less than or equal to.”
It will be apparent that systems and/or methods, as described herein, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these systems and/or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and/or methods were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement the systems and/or methods based on the description herein.
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.
No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
