Proactive and reactive management for devices in a network

BACKGROUND

0001Customer-premises equipment (CPE) is an electronic device located at a customer's premises that itself connects to a network or enables other devices to connect to a network. CPE devices include mobile phones, telephones, routers, switches, residential gateways (RGs), set-top boxes (STBs), fixed mobile convergence devices, home networking adapters, Internet access gateways, and home Internet of Things (loT) solutions that include centralized hub and connected smart peripherals (e.g. doorbell, security camera, sensor, home appliance, etc.). CPE devices couple to networks (e.g wide area networks (WANs), the Internet, etc. to thereby enable consumers to access services; CPE devices can distribute those services in a home via a local area network (LAN) or Wireless LAN (WLAN). Customers use CPE devices for various operations, including connecting to the Internet, communicating with a network or a device, placing or receiving phone calls, email, hosting Voice over Internet Protocol (VoIP) calls, and other telecommunications services.

0002Network providers have elected to use Technical Report 069 (“TR-069”) as a protocol to monitor and manage CPE devices. As a bidirectional Simple Object Access Protocol (SOAP)/Hypertext Transfer Protocol (HTTP)-based protocol, TR-069 provides communication between CPE devices and servers for management and modification of CPE devices. Network providers implement TR-069 in a wide range of telecommunications technology, including digital subscriber line (DSL), cable and Ethernet RGs, optical network terminals (ONTs), IP television STBs, network attached storage (NAS), powerline adapters, femtocells, microcells, picocells, and IP phones. The Broadband Forum manages the TR-069 standard and reports that the number of devices implementing TR-069 exceeds 350 million. More information regarding TR-069 is found at https://www.broadband-forum.org/standards-and-software/technical-specifications/tr-069-files-tools, which is incorporated by reference for its entirety.

0003Although TR-069 is widely implemented to manage CPE devices, the TR-069 standard and implementing equipment have several shortcomings that affect consumers, network providers, and service providers. For example, service or network providers that use the TR-069 standard require a call center to handle customer calls where TR-069 has identified a failing or problematic device. The network provider hosting the call center takes considerable time and value away from the provider and customer when CPE devices fail. Also, most subscribers find fixing a device that operates under TR-069 challenging, as a CPE device interface (e.g., an RG's interface) is complex. For example, a user generally cannot access a CPE device's configuration settings necessary to fix a TR-069 issue from the user interface.

0004Moreover, if subscriber access to a CPE device interface is permitted, there is a likelihood that the subscriber will improperly change configuration settings, resulting in CPE device failure, poor performance, or subscriber frustration. The eventual outcome is a call to customer support, which takes away valuable time and resources for all parties involved. Additionally, service providers and network providers waste millions of dollars per year on call centers and operations to fix devices operating on the TR-069 standard. Accordingly, the industry needs technology to address the above-mentioned problems and potentially provide additional benefits.

BRIEF DESCRIPTION OF THE DRAWINGS

0005The following drawings illustrate some implementations of the disclosed technology.

0006<figref idref="DRAWINGS">FIG. 1</figref> illustrates a CPE environment in accordance with some implementations of the disclosed technology.

0007<figref idref="DRAWINGS">FIG. 2</figref> illustrates a more detailed overview of the remote management system in <figref idref="DRAWINGS">FIG. 1</figref> in accordance with some implementations of the disclosed technology.

0008<figref idref="DRAWINGS">FIG. 3</figref> illustrates a more detailed overview of the health engine of <figref idref="DRAWINGS">FIG. 1</figref> in more detail in accordance with some implementations of the disclosed technology.

0009<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating a set of operations for managing a CPE device in accordance with some implementations of the disclosed technology.

0010<figref idref="DRAWINGS">FIG. 5</figref> is flowchart illustrating a set of operations for resolving an issue with a CPE device in accordance with some implementations of the disclosed technology.

0011<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart illustrating a set of operations for proactively correcting CPE device behavior.

0012The drawings are not drawn to scale. Also, some components or operations can be separated into different blocks or combined into a single block for the purposes of discussion of some of the implementations of the disclosed technology. The disclosed technology is intended to cover modifications, equivalents, and alternatives falling within the scope of the disclosed technology. For example, memory storing instructions can be located on a device or located in a remote location relative to the device. Also, a processor can execute instructions stored in a memory locally or read instructions from a remote memory.

DETAILED DESCRIPTION

0013The disclosed technology includes a health engine that monitors and modifies CPE devices. The health engine can detect patterns in CPE device behavior, identify problems or potential problems with CPE devices, and adjust CPE device configuration proactively or reactively to address problems or potential problems. For example, the health engine can determine that a person frequently uses a smartphone to initiate VoIP calls on weekdays between 9:00 and 11:00 a.m. Prior to 9:00 a.m. on weekdays, the health engine can determine the smartphone is not working due to a software error and, based on this determination, the health engine can instruct the smartphone to install updated software prior to the user initiating a VoIP call. Alternatively, the health engine can cause the smartphone to restart prior to 9:00 am. In some implementations, the health engine modifies CPE devices automatically before a user is aware of an issue or potential issue. The health engine is a combination of specialized hardware and software that can communicate with CPE devices over a network and is described in more detail in <figref idref="DRAWINGS">FIG. 3</figref>.

0014The health engine can enable a CPE device to comply with E911 emergency standards in accordance with the Third Generation Partnership Project (3GPP). For example, 3GPP defines requirements for mobile devices setting up emergency sessions on an IP Multimedia Subsystem (IMS) network. One requirement for setting up emergency sessions is determining the address or geolocation where a call is initiated such that an E911 operator can determine the location of a user. The health engine can determine that a CPE device is attempting or previously attempted to set up an IMS session to place a call or access the Internet by pulling information from the IMS network. The health engine also can determine that the IMS network or IP network handling the phone call cannot determine the CPE device's physical address and, in response, the health engine can query a customer database to determine the user's billing address. The health engine can ask the user if the user's billing address is the user's physical location through text message, email, or voice call. Alternatively, the health engine can receive an alternative address from the user through user input to determine an actual location of the CPE device.

0015In some implementations, the health engine has benefits related to improving computer and network technology. For example, the health engine reduces calls to call centers by actively and remotely resolving device- and network-related issues. By reducing calls to call centers, service and network providers reduce costs of operating networks, and customers are more satisfied with the quality of service. Additionally, the health engine reduces load on monitoring servers and IMS networks used in implementing the TR-069 standard because the amount of traffic that relates to errors is reduced.

0016<figref idref="DRAWINGS">FIG. 1</figref> illustrates a CPE environment in accordance with some implementations of the disclosed technology. The CPE environment <b>100</b> includes CPE devices <b>105</b>, network <b>110</b>, network <b>115</b>, remote management system <b>120</b>, and health engine <b>125</b>. In some implementations, the CPE environment <b>100</b> includes a home, office, residential area, commercial area, or any combination of these environments. Although the CPE environment <b>100</b> illustrates only CPE devices, the CPE environment <b>100</b> can also include Internet of Things (loT) devices. IoT devices include desktops and laptop computers, smartphones, tablets, wearables, appliances, automobiles, and other devices that can connect to a network. Manufacturers may prefer to add the TR-069 standard to IoT networks to increase security and monitoring of IoT devices.

0017The CPE devices <b>105</b> provide services and functions for users and include mobile phones, telephones, routers, switches, RGs, STBs, fixed mobile convergence products, home networking adapters, IoT devices, and access points. The CPE devices <b>105</b> enable consumers to access services and distribute those services in a home or elsewhere via a LAN, WLAN, personal area network (PAN), etc. In some implementations, customers use the CPE devices <b>105</b> to connect to the Internet, access databases, communicate with a network or another device, place or receive phone calls, and host VoIP calls.

0018The network <b>110</b> and the network <b>115</b> enable CPE devices and other devices in the CPE environment <b>100</b> to communicate and connect with other devices. The networks <b>110</b> and <b>115</b> can include a LAN, Wireless LAN (WLAN), a Wide Area Network (WAN), Global System for Mobile Communications (GSM), Bluetooth, WiFi, Fixed Wireless Data, 2G, 2.5G, 3G, 4G, 5G, and LTE networks, using messaging protocols such as TCP/IP, Short Message Service (SMS), multimedia messaging service (MMS), or any other wireless data networks or messaging services. The networks <b>110</b> and <b>115</b> can also include wired networks.

0019In some implementations, the network <b>110</b> is the Internet, and the network <b>115</b> is an IMS network. For example, network <b>110</b> can be a WLAN network set up by a customer or service provider, and the network <b>115</b> is an IMS network. The IMS network can implement Session Initiation Protocol (SIP)-based communication. More information regarding IMS can be found at http://www.3gpp.org/technologies/keywords-acronyms/, which is incorporated herein for its entity. The IMS network can include at least a Proxy Call Session Control Server (P-CSCF); a Serving CSCF (S-CSCF); an Interrogating CSCF (I-CSCF), and other network elements such as Breakout Gateway Control Function (BGCF), Media Gateway Control Function (MGCF), and Signaling Gateway (SGW). The IMS network is connected to a Home Subscriber Server (HSS) and the public switched telephone network (PSTN).

0020In some implementations, the network <b>110</b> is referred to as the “signaling network” because it governs paging, signaling, and monitoring of the CPE device according to the TR-069 standard. In some implementations, the network <b>115</b> is referred to as “service network” because it provides a service or services (e.g., VoIP or email) for the CPE device. The CPE <b>105</b> may connect to network <b>115</b> in two different ways. As seen on <figref idref="DRAWINGS">FIG. 1</figref>, CPE <b>105</b> can directly reach network <b>115</b> with mobile broadband (e.g. LTE), or through the Internet with fixed broadband (e.g. cable) utilizing IPsec tunnels. In implementations where the network <b>110</b> is a signaling network and the network <b>115</b> is the service network, network providers can keep signaling and monitoring bandwidth on the network <b>110</b> and keep service bandwidth on the network <b>115</b>. Decreasing bandwidth usage on a service network can improve a customer's experience with the service when using the CPE device.

0021The remote management system <b>120</b> is a vendor-agnostic system that manages and monitors the CPE devices <b>105</b>. The remote management system <b>120</b> can use protocols such as TR-069, Simple Network Management Protocol (SNMP), SOAP, HTTP/HTTPS, and Open Mobile Alliance (OMA) Device Management (DM). The remote management system <b>120</b> is described in more detail in <figref idref="DRAWINGS">FIG. 2</figref>, but as a general overview, the remote management system <b>120</b> can generate ACS reports related to the operation of the CPE devices <b>105</b> and send instructions to the CPE devices <b>105</b>. The instructions can include updating software, updating firmware, a command to restart the device, or other TR-069 commands. In some implementations, the remote management system <b>120</b> communicates with the health engine <b>125</b> to improve the health of the CPE devices <b>105</b>.

0022As shown by the bold double-headed arrows in <figref idref="DRAWINGS">FIG. 1</figref>, the remote management system <b>120</b> communicates with the health engine <b>125</b> (e.g., using Extensible Messaging and Presence Protocol (XMPP)). The remote management system <b>120</b> and health engine <b>125</b> communicate with each other. The health engine <b>125</b> collects CPE data/reports directly from the remote management system utilizing an integrated listener routine with either a pull or push mechanism. The health engine <b>125</b> could send instructions either directly with XMPP, or through ACS, to the CPE devices. The health engine can detect patterns in CPE device behavior, identify problems with CPE devices, identify healthy or unhealthy conditions, and adjust CPE device configuration proactively or reactively to address the error or unhealthy condition. A problem is defined as a CPE device error or service error. Examples of errors can be found in Table 1 below. An unhealthy condition is defined as an abnormal condition compared to a normal dataset. For example, if a CPE device is usually active between 9 to 11 a.m. on weekdays, and then the CPE is inactive from 9 to 11 a.m., the CPE device is unhealthy and the health engine can analyze the CPE device as described in <figref idref="DRAWINGS">FIG. 3</figref> and <figref idref="DRAWINGS">FIG. 4</figref>.

0023Continuing with <figref idref="DRAWINGS">FIG. 1</figref>, if the network <b>115</b> is an IMS network, the health engine can communicate with the IMS network to receive data related to CPE devices using services on the IMS network or connecting to the IMS network. For example, the health engine <b>125</b> can invoke an application program interface (API) to pull data from the IMS network. The API can pull data related to IMS sessions, call failure, call success, call duration, data throughput for session, amount of data used by devices, and applications accessed or used on the IMS network. The API can be written in Java™ or C/C++/C#. In some implementations, the API is a representational state transfer (REST) service to a Web 2.0 application. The health engine <b>125</b> can analyze the data (e.g., CPE profile data, CPE device behavior data, IMS data) and use it to instruct the remote management system <b>120</b> pulled from the network. The health engine <b>125</b> is described in more detail in <figref idref="DRAWINGS">FIG. 3</figref>.

0024In some implementations, the health engine <b>125</b> automatically addresses an error or unhealthy condition. By automatically addressing an error or unhealthy condition, the health engine <b>125</b> reduces the number of calls to call centers and improves a customer's experience with the CPE device, network provider, and service provider.

0025<figref idref="DRAWINGS">FIG. 2</figref> illustrates a more detailed overview of the remote management system <b>120</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. <figref idref="DRAWINGS">FIG. 2</figref> includes an auto configuration server (ACS) <b>205</b>, an Operations Support System (OSS)/Business Support System (BSS) <b>210</b>, a policy database <b>215</b>, a customer care unit <b>220</b>, a report engine <b>225</b>, and an ACS graphical user interface (GUI) <b>230</b>. The remote management system <b>120</b> implements CPE management functions within a common framework such as the TR-069. Each of the components of the remote management system <b>120</b> is described in more detail below. In some implementations, the remote management system <b>120</b> includes is a combination of hardware and software including a CPU and memory device.

0026The ACS <b>205</b> is a server that sets up, manages, modifies, and monitors CPE devices. In some implementations, the ACS <b>205</b> implements the TR-069 standard to centrally manage CPE devices in a network or networks. The ACS <b>205</b> can configure CPE devices, register CPE accidents, register failure or events associated with CPE devices, set up or register new CPE devices, and monitor CPE devices. Although the ACS <b>205</b> is illustrated as a single server in <figref idref="DRAWINGS">FIG. 2</figref>, the ACS <b>205</b> can also be a distributed computing system encompassing multiple servers located at the same or at geographically disparate physical locations.

0027The OSS/BSS <b>210</b> provides a network operator the ability to perform accounting, business operations (e.g., billing), and network maintenance for the service provider for a network. In some implementations, the OSS/BSS <b>210</b> also enables a network operator to define the billing parameters, rate plans and associated logic, and customer schemes.

0028The policy database <b>215</b> enables CPE policy management and enforcement. The policy database <b>215</b> includes data related to timing aspects of the remote management system <b>120</b> such as the time interval during which the CPE must notify the ACS, search for updates, report data parameters (e.g., Quality of Service (QoS)), bytes sent/received, applications used or previously used, user updates, blocking settings, and security settings restricting users from changing specific parameter values. In some implementations, a technician can update the policy database <b>215</b> remotely.

0029The report engine <b>225</b> generates ACS reports. The ACS reports can include log and configuration data from the CPE devices <b>105</b>. In some implementations, ACS reports include policy diagnostics, stores diagnostics information, authentication flow diagnostics, passed authentications, failed authentications, authentication summary, session status summary, security information, and session history.

0030The ACS GUI <b>230</b> allows technicians to review data associated with the remote management system <b>120</b>. As seen in revised <figref idref="DRAWINGS">FIG. 1</figref>, customer care unit <b>220</b> utilizes ACS GUI <b>230</b> to retrieve CPE data from CPE Database <b>235</b> through ACS <b>205</b>. In some implementations, the ACS GUI <b>230</b> includes a computer and screen where a technician can review information associated with the system. In some implementations, a technician can use the ACS GUI <b>230</b> to configure log files, server certificates, ACS server settings, policies, access, and security settings. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, a customer care unit <b>220</b> utilizes the ACS GUI <b>230</b> to retrieve CPE status. The remote monitoring system <b>120</b> may also include the following components: a CPE database <b>235</b> that stores data reported by each CPE; an XMPP server <b>240</b>, where the ACS <b>205</b> and the health engine <b>125</b> both utilize the XMPP server <b>240</b> to send instructions to CPE <b>105</b>; and a web proxy <b>245</b> that operates as an intermediary server to redirect incoming traffic from CPE devices.

0031<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram illustrating exemplary elements of the health engine <b>125</b>. The health engine can detect patterns in CPE device behavior, identify problems or potential problems with CPE devices, and adjust CPE device configuration proactively or reactively to address problems or potential problems.

0032The health engine <b>125</b> includes central processing unit (CPU) <b>300</b> and a memory <b>305</b> storing a CPE profiler <b>310</b> that is associated with CPE profiler database <b>325</b>, a user activity analyzer <b>315</b> that is associated with user activity database <b>330</b>, and a health implementer <b>320</b> and associated health implementer database <b>335</b>. These hardware and software components communicate to perform operations of the health engine. The CPU <b>300</b> can be a single processing unit or multiple processing units in a device or distributed across multiple devices. The CPU <b>300</b> can be physically or electronically coupled to other hardware devices, for example, with the use of a bus, such as a peripheral component interconnect or small computer interface bus. In some implementations, the CPU <b>300</b> can include an application-specific integrated circuit (ASIC) designed to run programs stored in memory <b>305</b>.

0033The memory <b>305</b> includes one or more of various hardware devices for volatile and non-volatile storage and can include both read-only and writable memory. For example, a memory can comprise random access memory (RAM), CPU registers, read-only memory (ROM), and writable non-volatile memory, such as flash memory, hard drives, CDs, DVDs, magnetic storage devices, tape drives, and device buffers. The memory is not a propagating signal divorced from underlying hardware; rather, a memory is non-transitory. The memory <b>305</b> can be physically coupled to the CPU <b>300</b> or the CPU <b>300</b> can communicate with the memory using data bus, network, cloud service, wireless, or wired connection. Each of the components of the health engine <b>125</b> included in the memory <b>305</b> are described in more detail below.

0034The CPE profiler <b>310</b> profiles CPE devices. In some implementations, the CPE profiler <b>310</b> determines hardware and software characteristics of a device. For example, the CPE profiler <b>310</b> determines firmware, firmware version, software version, and specifications of a device. The CPE profiler <b>310</b> can determine characteristics about a device by querying the device directly, or the CPE profiler <b>310</b> can receive serial number information and look up the specifications of the device. The CPE profiler <b>310</b> can also determine when a device was restarted, the frequency of restarts, and when the device was last updated. The CPE profiler <b>310</b> can store and access data in the CPE profiler database <b>325</b>.

0035The user activity analyzer <b>315</b> collects and analyzes CPE device activity. CPE device activity can include session information, types of applications currently or previously used by a CPE device, CPE device bandwidth usage, security settings, number of calls placed, duration of time spent using the CPE device, time spent using a particular application or function on the CPE device, data used per unit of time (e.g., hour, minute, week, day), CPE device power health (e.g., battery health), frequency of restarting the CPE device, or other statistical data for the CPE device.

0036In some implementations, the user activity analyzer <b>315</b> uses a clustering algorithm to determine whether a CPE device is healthy or unhealthy. A health CPE device is operating normally and an unhealthy device is operating abnormally compared to a normal operating dataset associated with the CPE device. To determine whether a CPE device is healthy or unhealthy, the user activity analyzer <b>315</b> can use a cluster algorithm includes grouping a set of objects (e.g., CPE device activity data) into groups (called a cluster) that are more similar (in some sense or another) to each other than to those in other clusters. Clusters include groups with small distances among the cluster members, dense areas of the data space, intervals, or particular statistical distributions. Some example clusters are the duration and time a user is using a CPE device. For example, the user activity analyzer <b>315</b> can collect CPE usage data over a two-week period. Based on this data, the user activity analyzer <b>315</b> can determine that a CPE device is mostly likely active and healthy between 9:00-11:00 a.m. and 5:00-8:00 p.m. because the user is able to use applications on the CPE device. A technician can adjust clusters or parameters for clusters to modify the definition of healthy of unhealthy behavior.

0037In addition to the clustering algorithm, the user activity analyzer <b>315</b> can implement unsupervised anomaly detection algorithms. The algorithms detect anomalies set under an assumption that the majority of the instances in the data set are normal and look for instances that seem to fit least to the remainder of the data set. For example, the user activity analyzer <b>315</b> can determine that a smartphone is experiencing calling issues because for weeks, it placed calls every day, but for the last few days, it has not and the smartphone is likely experiencing an anomaly. The user activity analyzer <b>315</b> can store and access information in the user activity database <b>330</b>.

0038Continuing with <figref idref="DRAWINGS">FIG. 3</figref>, the health implementer <b>320</b> can resolve CPE device issues. In some implementations, the health implementer <b>320</b> sends a request to a malfunctioning CPE device to restart. In some implementations, the health implementer <b>320</b> causes a CPE device to update its software or firmware. The health implementer <b>320</b> can also receive feedback from a CPE device that recently received a proposed solution (e.g., restart) and determine if the CPE device is operating properly. The health implementer <b>320</b> can communicate with CPE devices through the ACS <b>205</b> or receive ACS reports from the report engine <b>225</b>. The health implementer at least partially makes its decision to resolve a CPE device issue based on the user activity analyzer <b>315</b>. Some examples of errors and associated corrective actions are described below. In some implementations, the health engine automatically implements an associated response action based on receiving or detecting an error in the CPE device.

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Errors and Associated Response Actions</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="210pt" align="left" /><tbody valign="top"><row><entry>Example Error</entry><entry>Example Actions</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>E-911 address</entry><entry>Query customer care database for user address or bill address; send a</entry></row><row><entry>error</entry><entry>request to user to confirm user or billing address is address for CPE</entry></row><row><entry /><entry>device (e.g., text message, email, notification to confirm address,</entry></row><row><entry /><entry>phone call); receive confirmation of billing address for CPE device and</entry></row><row><entry /><entry>update CPE device address.</entry></row><row><entry>SIM card error</entry><entry>Determine Subscriber Identify Module (SIM) card is unregistered on</entry></row><row><entry /><entry>network; send instructions to network operator to register SIM card or,</entry></row><row><entry /><entry>if network operator unavailable, attempt to register SIM card again and</entry></row><row><entry /><entry>notify user if unsuccessful.</entry></row><row><entry /><entry>Send notification to user that an incorrect SIM card is installed in the</entry></row><row><entry /><entry>CPE device; request that user provide a shipping address for new SIM</entry></row><row><entry /><entry>card or provide user with location of technical support to fix or replace</entry></row><row><entry /><entry>SIM card.</entry></row><row><entry /><entry>Determine the user has installed a multi-SIM card, send instructions to</entry></row><row><entry /><entry>device to switch Mobile Subscriber Integrated Services Digital Network</entry></row><row><entry /><entry>Number (MSISDN) number based on user location and user database</entry></row><row><entry /><entry>lookup.</entry></row><row><entry>IMS server or</entry><entry>Determine user attempted to send a message too large for an IMS</entry></row><row><entry>network error</entry><entry>server because the message is above a policy message size limit;</entry></row><row><entry /><entry>send instructions to CPE device to segment or parse the message into</entry></row><row><entry /><entry>multiple messages.</entry></row><row><entry /><entry>Determine a CPE device is experiencing an increasing number of</entry></row><row><entry /><entry>errors because aspects of an SIP session such as requested media,</entry></row><row><entry /><entry>bandwidth, or addressing style are not acceptable; send instructions to</entry></row><row><entry /><entry>the CPE device to restart device or restart session when device is not</entry></row><row><entry /><entry>in use.</entry></row><row><entry>Drop call error or</entry><entry>Determine CPE device has more dropped calls than a previous time</entry></row><row><entry>frequent call</entry><entry>period; send instructions to the device to restart and/or run diagnostic</entry></row><row><entry>dropping</entry><entry>on call feature when the user is not or is unlikely to be using the</entry></row><row><entry /><entry>device.</entry></row><row><entry /><entry>Determine CPE device frequently has dropped calls; send instructions</entry></row><row><entry /><entry>to CPE device to perform factory reboot; email user of the CPE device</entry></row><row><entry /><entry>regarding factory reboot.</entry></row><row><entry>Temperature</entry><entry>Determine that a CPE device has exceeded its recommended</entry></row><row><entry>warning or fan</entry><entry>temperature once or several times; send instructions to a neighbor</entry></row><row><entry>failure</entry><entry>CPE device to handle load of the failing CPE device; send instructions</entry></row><row><entry /><entry>to shut down or idle failing CPE device; and send instructions to a</entry></row><row><entry /><entry>technician to replace or fix failing fan or move location of CPE device</entry></row><row><entry /><entry>to a cooler area or room.</entry></row><row><entry>Unhealthy</entry><entry>Determine device is experiencing an unhealthy condition (e.g., not</entry></row><row><entry>condition</entry><entry>calling at usually times based on a clustering algorithm), and send a</entry></row><row><entry /><entry>restart or reboot command to the CPE device.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0039In addition to reacting to CPE device errors or unhealthy conditions, the health engine can proactively act. Proactively acting means the health engine <b>125</b> has determined an expected behavior of a CPE device based on, e.g., a clustering algorithm, and then, the health engine <b>125</b> sends a command to test whether the device is prepared to function properly for during an upcoming period. For example, if the health engine <b>125</b> determines a CPE device is usually active between the periods of 9 to 11 a.m. on weekdays to place VoIP calls, the health engine <b>125</b> can send instructions to test the VoIP application for a CPE device at 8:55 a.m. every week day. If the test fails, the health engine <b>125</b> can send a restart or reboot command to the CPE device. In some implementations, the health engine <b>125</b> can determine that a CPE device generally sends more than 15 MB of email between 8 a.m. to 3 p.m. on weekdays based on a clustering algorithm. In these implementations, the health engine <b>125</b> can test whether email service is working properly at 7:30 am. Also, if the health engine <b>125</b> determines that the CPE device failed to send more than 15 MB of email on a weekday, the health engine <b>125</b> can query the CPE to determine if an error occurred or it can query the user to ask if the email is functioning properly.

0040<figref idref="DRAWINGS">FIG. 6</figref> more generally describes this operation. Beginning in block <b>605</b>, the health engine <b>125</b> recognizes expected behaviors of CPE devices, and can determine whether a device may soon fail or otherwise encounter a problem. In block <b>610</b>, the health engine determines one or more proactive measures to prevent the failure or other problem. In block <b>615</b>, the health engine sends instructions to the device or to the network to prevent such failure or problem from occurring.

0041Although <figref idref="DRAWINGS">FIG. 3</figref> illustrates that memory <b>305</b> includes the CPE profiler <b>310</b>, the user activity analyzer <b>320</b>, and the health implementer <b>325</b>, these components also can be stored in separate memories. For example, the CPE profiler <b>310</b> can have its own processor and be stored in a separate server device with respect to the health implementer <b>320</b>.

0042Also, although the ACS <b>205</b> monitors and manages the CPE devices <b>105</b>, the health engine <b>125</b> can offload monitoring and managing responsibilities from the ACS <b>205</b>. For example, the health engine <b>125</b> can analyze the ACS reports and then determine appropriate solutions to fixing errors or improving (e.g., optimizing) the perform of CPE devices.

0043<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating a set of operations for managing a CPE, also referred to as process <b>400</b>. The process <b>400</b> includes receiving information about the operation and activity of a CPE device and using this information to improve the operation of the device and the user's experience. In some implementations, the health engine <b>125</b> (<figref idref="DRAWINGS">FIG. 3</figref>) initiates the process <b>400</b> automatically once a CPE device is registered. In other implementations, a network technician can initiate the process <b>400</b> for single or multiple CPE devices by accessing the health engine <b>125</b> through the ACS GUI <b>230</b> (<figref idref="DRAWINGS">FIG. 2</figref>).

0044At receiving operation <b>400</b>, the health engine <b>125</b> receives a status report from a remote management system <b>120</b> (<figref idref="DRAWINGS">FIG. 1</figref>). The status report generally includes information about the operation of the device such as firmware, hardware, latest uploads and downloads of software, error reports, requests, time stamps, and other information common in the TR-069 standard. In some implementations, a technician can adjust the ACS report to include or not include particular device information based on policy or goals of the server or network provider.

0045In some implementations, the health engine <b>125</b> pulls the status report from an ACS server, and in other implementations the ACS server periodically, or whenever a change to the current status (e.g. registration error, dropped call, etc.) occurs, sends the status report to the health engine. The health engine <b>125</b> can receive status reports with various frequency. In some implementations, the health engine receives a status report for a CPE device every 15 minutes. A network technician can adjust the frequency of ACS reporting based on network bandwidth, demands of the network, and CPE device type (e.g., devices with a low or high failure rate).

0046At detecting operation <b>410</b>, the health engine <b>125</b> detects behavior of the CPE device. Behavior of the CPE device can include hours of operation (e.g., when the CPE device is active, inactive, how long it was unregistered for), applications used by the device currently or previously, quality of service during operation, data related to performance metrics (e.g., download or upload speed and amount of data), frequency of errors, security information, and other information the CPE device is enabled to store and transmit. The health engine stores the device activity in a CPE device database such as the user activity database <b>330</b> (<figref idref="DRAWINGS">FIG. 3</figref>).

0047In some implementations, the health engine <b>125</b> stores the CPE device behavior and it analyzes the stored data. For example, the health engine can store CPE device operation status (e.g., active or inactive) on a weekly or monthly basis. The health engine can implement a clustering algorithm to determine periods when the device is mostly likely to be active or least likely to be active. The health engine can also determine the most frequently used applications or services for the CPE device. In some implementations, the health engine <b>125</b> associates periods of user activity with the most frequently used applications. The health engine <b>125</b> can use these datasets to define periods of normal use or abnormal use.

0048At decision operation <b>415</b>, the health engine analyzes CPE device behavior data from the ACS <b>205</b> to determine if the device has been treated. If so, in block <b>425</b> the health monitoring device receives feedback from the treated device, via ASC, following execution of an action. At block <b>425</b>, the health engine <b>125</b> can receive feedback from a CPE after the execution of the action. In some implementations, the health engine <b>125</b> uses the feedback to determine if the executed action was partially or completely effective in fixing the problem. For example, the health engine <b>125</b> can determine if the device is unhealthy or healthy after the execution operation. Additionally, the health engine <b>125</b> can send the feedback to a network provider if the health engine <b>125</b> determines that a CPE device or a group of CPE devices fails to operate properly even after several attempted fixes or solutions. The network provider can develop a new fix or solution, and then upload this fix into the health engine <b>125</b> if similar problems arise again for another CPE device.

0049If the device has not been treated, then at decision operation <b>420</b> the health engine <b>125</b> determines whether a CPE device is healthy. If the health engine <b>125</b> determines that a CPE device is healthy, the process <b>400</b> returns to the receiving operation <b>405</b>, where it receives another status report from the CPE device. Otherwise if the CPE device is determined to be unhealthy, or if the device has not been fixed at decision operation <b>430</b>, then the health engine <b>125</b> determines the appropriate actions to fix device or prevent failure. In some implementations, a technician can include a waiting period between decision operation <b>420</b> and starting process <b>400</b> again. If the device is determined to be fixed at decision operation <b>430</b>, then the health engine <b>125</b> will label the executed action as valid and update the Health Implementer Database <b>335</b> at learning operation <b>445</b>.

0050To determine whether a CPE device is healthy, the health engine <b>125</b> analyzes the behavior of the CPE device and the status report. If the status report includes errors, the health engine <b>125</b> can communicate with a remote management system <b>120</b> (<figref idref="DRAWINGS">FIG. 2</figref>) to determine an action for fixing device (see determining operation <b>435</b>).

0051At determining operation <b>435</b>, the health engine <b>125</b> determines an action for fixing the CPE device. In some implementations, the health engine <b>125</b> determines the action by querying an error and associated action for resolving the issue. Examples of errors and associated actions can be found in Table 1. At execution operation <b>440</b>, the health engine <b>125</b> executes a resolution action. In some implementations, the health engine sends instructions to the CPE device, where the instructions cause the CPE device to restart or update its software.

0052Although the health engine <b>125</b> performs process <b>400</b> in implementations described above, other devices can perform process <b>400</b>. For example, the remote management system <b>120</b> (<figref idref="DRAWINGS">FIG. 2</figref>) can perform process <b>400</b> by receiving instructions from the health engine <b>125</b>.

0053<figref idref="DRAWINGS">FIG. 5</figref> is flowchart illustrating a set of operations for resolving an issue with a CPE device, also referred to as process <b>500</b>. Process <b>500</b> includes determining a CPE device has failed to meet criteria for properly operating on a network and addressing this failed criteria. In some implementations, the health engine <b>125</b> (<figref idref="DRAWINGS">FIG. 3</figref>) performs operation <b>500</b> when it receives a notification from an IMS network that a CPE device is not set up for E-911 sessions because the CPE device lacks an address or geolocation. The health engine <b>125</b> can initiate process <b>500</b>, or an IMS network can send a request to the health engine <b>125</b> to start the process. For example, the health engine <b>125</b> can implement process <b>500</b> after a user installs a VoIP device on a CPE device.

0054At determining operation <b>505</b>, the health engine <b>125</b> determines a CPE has failed to meet network criteria or failed to set up a session. For example, the health engine <b>125</b> can receive a notification from an IMS network that a CPE device cannot start an E911 emergency session because the CPE device does not have an associated address or geolocation. At determining operation <b>510</b>, the health engine <b>125</b> determines how to fix the failed criteria. For example, the health engine <b>125</b> can determine from a lookup table that the system can look up a billing address associated with a user of the CPE device and use this address as the address or geolocation for the device.

0055At sending operation <b>515</b>, the health engine <b>125</b> sends instructions to a device or network to resolve the failure. For example, the health engine <b>125</b> can send instructions to OSS/BSS or customer care unit to look up a user's address, and then send this address to the user to verify it is indeed the location of the CPE device. In some implementations, the health engine <b>125</b> sends an SMS message, a MMS message, or email message to the CPE device or user of the CPE device to confirm a billing address. Alternatively, the health engine <b>125</b> can query a user to input a new billing address or address associated with the location of the CPE device.

0056Although the health engine <b>125</b> can end process <b>500</b> after the sending operation <b>515</b>, the health engine <b>125</b> can perform process <b>500</b> again. For example, if the health engine <b>125</b> determines that the CPE device has moved permanently (e.g., a user moved his/her residential location, a business moved its geographic location, or a CPE device's IP address has changed along with a different ISP location), the health engine <b>125</b> can repeat the process <b>500</b> for the CPE device. The health engine <b>125</b> can determine a CPE device has moved based on receiving an indication from the network provider that the CPE device has been deactivated for a long time or from the billing system (e.g., a user changed his/her address).

0057Although the health engine <b>125</b> performs process <b>500</b> in implementations described above, other devices can perform process <b>500</b>. For example, the remote management system <b>120</b> (<figref idref="DRAWINGS">FIG. 2</figref>) can perform process <b>500</b> by receiving instructions from the health engine <b>125</b>.

CONCLUSION

0058Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to.” As used herein, the terms “connected,” “coupled,” “physically coupled,” “electronically coupled,” or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof. Additionally, the words “herein,” “above,” “below,” and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word “or,” in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

0059Special-purpose hardware (e.g., circuitry), as programmable circuitry appropriately programmed with software and/or firmware or as a combination of special-purpose and programmable circuitry, can perform the operations of this disclosed technology. Some implementations include a non-transitory computer readable medium storing instructions, which can be used to program a computer (or other electronic devices) to perform a process. The non-transitory computer readable can include optical disks, compact disc read-only memories (CD-ROMs), magneto-optical disks, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions.

0060The phrases “in some implementations,” “according to some implementations,” “in the implementations shown,” “in other implementations,” and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one implementation of the disclosed technology and may be included in more than one implementation. In addition, such phrases do not necessarily refer to the same implementations or different implementations.

0061The above Detailed Description of examples of the disclosed technology is not intended to be exhaustive or to limit the technology to the precise form disclosed above. While specific examples for the technology are described above for illustrative purposes, various equivalent modifications are possible within the scope of the technology, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative implementations may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or subcombinations. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel, or may be performed at different times. Further, any specific numbers noted herein are only examples: alternative implementations may employ differing values or ranges.

0062The teachings of the technology provided herein can be applied to other systems, not necessarily the system described above. The elements and acts of the various examples described above can be combined to provide further implementations of the technology. Some alternative implementations of the technology may include not only additional elements to those implementations noted above, but also may include fewer elements.

0063These and other changes can be made to the technology in light of the above Detailed Description. While the above description describes certain examples of the technology, and describes the best mode contemplated, no matter how detailed the above appears in text, the technology can be practiced in many ways. Details of the system may vary considerably in its specific implementation while still being encompassed by the technology disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the technology should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the technology with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the technology to the specific examples disclosed in the specification, unless the above Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology under the claims.

0064To reduce the number of claims, certain aspects of the disclosed technology are presented below in certain claim forms, but the applicant contemplates the various aspects of the technology in any number of claim forms. For example, while only one aspect of the technology is recited as a computer-readable medium claim, other aspects may likewise be embodied as a computer-readable medium claim, or in other forms, such as being embodied in a means-plus-function claim. Any claims intended to be treated under 35 U.S.C. § 112(f) will begin with the words “means for”, but use of the term “for” in any other context is not intended to invoke treatment under 35 U.S.C. § 112(f). Accordingly, the applicant reserves the right to pursue additional claims after filing this application to pursue such additional claim forms, in either this application or in a continuing application.