1. Field of the Invention
The present invention relates to the field of testing data transfer services. In particular, the present invention provides a method and system for comprehensive testing of a connection to a network.
2. Description of the Related Art
New services are currently being introduced that expand upon Internet Protocol (IP). IP is a packet-switching technology for transporting information over Internet connections. Some exemplary IP services include Voice over Internet Protocol (VoIP) for making phone calls, and Internet Protocol Television (IPTV) to provide television programs and video content to a customer's television set. The introduction of these new services highlights the need for maintaining trouble-free customer IP connections.
In order to maintain a customer connection, the customer connection can be monitored periodically or checked upon request. A comprehensive testing and monitoring device should be able to address the various types of connections that are available to a customer. Various testing modules, like “ping” and “trace”, already test certain aspects of the customer connection. However, as the network connection carries more traffic and is counted on for greater reliability, testing connections will generally require more extensive knowledge of network status, configuration parameters, etc.
The present invention provides a method and system for comprehensive testing of a customer connection to a communications network. Comprehensive testing is provided comprising testing at various stages of the network connection, such as customer premises equipment (CPE), telephone company equipment, and Internet Service Provider (ISP) equipment. Results of the testing and related configuration parameters are stored in a plurality of data sets related to a customer. A customer interface is provided wherein a customer connection can be identified from information obtained at the customer interface. In one embodiment, the customer interface is an Interactive Voice Recorder (IVR), which interacts with a customer over a telephonic connection. In another embodiment, the customer interface is a graphical user interface (GUI), such as a web page, that is accessible by a customer service operator. To monitor a customer connection, the present invention typically obtains at least a first dataset and a second dataset related to testing and/or configuration of the customer connection. A comparison can be made between parameters in the first dataset and parameters in the second dataset. The results of the comparison indicate a state of the customer connection and issues that may affect the connection, such as inoperative network devices, incorrect configuration parameters, etc.
In one aspect of the present invention, the first and second dataset can be obtained at a network element, such as a router. In one implementation, the first and second dataset include historical data, obtained at different times. The times can be determined by an operator. Differences, or changes, between a parameter such as a configuration parameter in the first dataset and the corresponding parameter in the second dataset can be flagged. Also, the first and second dataset can be compared in light of a change of a customer related parameter recorded in a provisioning database. In addition, a dataset can be obtained from the CPE, for instance, by operating a program at the CPE to check configuration parameters at the CPE. For example, a program can be made to operate on a personal computer to obtain values from a registry for a Windows™ operating system operating on the personal computer. In another implementation of the present invention, a parameter in the first dataset obtained from a network element can be compared to the same or a related parameter in a second dataset obtained from a customer database. If the parameter change between data sets occurs without a corresponding change entry in a provisioning data base a network problem or issue is indicated. The customer can be notified of any identified network problems.
Examples of certain features of the invention have been summarized here rather broadly in order that the detailed description thereof that follows may be better understood and in order that the contributions they represent to the art may be appreciated. There are, of course, additional features of the invention that will be described hereinafter and which will form the subject of the claims appended hereto.
For detailed understanding of the present invention, references should be made to the following detailed description of an exemplary embodiment, taken in conjunction with the accompanying drawings, in which like elements have been given like numerals.
In view of the above, the present invention through one or more of its various aspects and/or embodiments is presented to provide one or more advantages, such as those noted below.
A software agent can be used to compile CPE data at the CPE 112. Such software agents are short diagnostic programs that can operate from the CPE and feed data back to the IP Tool, often using a commonly-used channel for data transmission, such as a port used for hypertext transfer protocol (HTTP) at a personal computer (PC). An agent typically obtains connectivity data at the CPE, such as local configuration parameters, etc. In one embodiment, an agent operating on a personal computer can examine a Microsoft Windows™ registry (a database of nearly all the settings for Windows™ and installed applications) of the PC. The agent can compare registry values to previously acquired registry data set values (e.g., acquired a few weeks prior). Changes in the registry can thereby be noted, such as could be due to a corrupted registry, for example, or by customer tinkering. Thus if the other network elements are working correctly, but the customer still cannot connect, the registry configuration parameters data sets can be checked. The IP Tool stores any changes a customer may make to any of the CPE by obtaining data sets from agents installed in CPE software. Additionally, the telephone company can assemble data sets from multiple CPE locations and create graphs for customers aggregated in one data set group, such as all customers at a point-of-presence (POP) connection to the network.
Telco Monitoring & Traffic Data database 108 typically compiles historical data sets obtained from various Telco equipment 114. Historical data sets are data obtained at various intervals, i.e., historically, such as hourly or daily. The IP Tool 102 can obtain the compiled data sets from the Telco Monitoring & Traffic Data database 108 and test for any performance degradation issues at the Telco equipment.
An ISP Monitoring & Traffic Data database 110 typically compiles historical data sets related to customer activity and traffic at the ISP 116. The IP Tool can obtain the compiled data sets from the ISP Monitoring & Traffic Data database 110 and use the data sets to determine any ISP problems.
The IP tool comprises IP Tool Equipment 104 and Testing Data database 106. The IP Tool Equipment 104 typically comprises a processor and a user interface for customer service. In an exemplary embodiment, the user interface comprises a Graphical User Interface for use by a customer service operator. In an alternative embodiment, the user interface comprises an Interactive Voice Responder (IVR) that interacts with the customer over a telephone connection. The Testing Data database 106 typically stores tests results in data sets that can be performed on the various network elements associated with the customer connection.
The IP Tool can continuously monitor network elements and perform tests at intervals determined by an operator. In an additional aspect of the present invention, the IP Tool reports any detected problems, such as a broken connection, a failed network element, an incorrect configuration parameter at a router, etc., to a Network Operating Center, which can alert the customer or network operator/user or prepare repair tickets to address the problem. When the network is continuously monitored, any detected problems can be flagged, and Ambush Alerts can be produced for customers. An Ambush Alert anticipates a customer service call and is presented to the customer upon calling into customer service. In the embodiment in which the user interface is an IVR, the IP Tool 102 can be activated upon receiving a customer service call. If a customer calls in about a network issue or problem that the IP Tool has already detected, the IVR can activate the Ambush Alert message to intercept the incoming call, inform the customer that an error has been detected, and provide an estimated amount of time before service resumes, etc. When a customer calls in, the IP Tool matches an identification number of the caller, typically a telephone number of the caller, to customer records and accesses a customer database comprising, among others, a data set including customer name, customer address, present status (i.e. whether the account is active or inactive), and any stored Ambush Alerts for the customer. The IP Tool 106 provides the Ambush Alerts to the customer via the customer interface. Alternatively, the IP Tool can call a customer to relay a message proactively to the customer when an issue arises. Additionally, the customer can choose through the IVR to be notified at a later time once the network event is resolved. This option reduces the number of customer service calls.
If the customer is experiencing authentication problems, such that the customer is unable to access the network, the customer can be given an option to reset a password over the phone using the IVR. The same option is available for notification of other network events. An appropriate business decision can be made concerning handling of issues due to connection failure at the telephone company. For example, a telephone company might address customer downtime through a refund policy.
The Possible Network Events section 352 comprises a review of network events impacting service to the customer. The Module Selection section 354 comprises several checkboxes enabling the operator to test various services. In the exemplary embodiment, the operator can activate tests related to IPTV service 340, Internet service 342, VoIP service 344, and Email service 346. It is understood that the IP services displayed in
The Authentication module 702 checks issues dealing with logging into the network, such as an incorrect password being entered at the CPE upon dial-up to the network, or Remote Access Dial-In User Service (RADIUS) and Lightweight Directory Access Protocol (LDAP) records not matching due to incomplete password replication to RADIUS servers, etc. The “Email Can't Send/Receive” module monitors 704 email server problems such as a full email box, a poorly-performing email server, poor connectivity between email server and customer, whether the server is down, etc. The email module tests the transport path from the customer, and verifies that the customer's user ID/Pass can authenticate with the customer POP mail server.
The “Connection/Slow Browse” module 706 tests for slow connectivity speeds between the CPE and the network, verifies the normal functioning of relevant DNS servers, and checks the transport layers of the customer connection for any degradation issues, among others. The “Connection/No Browse” module 708 typically tests whether the customer is connected and is using a valid IP address. These tests verify the level of TCP/IP layer traffic, verify the DNS, and test the speed of the connection.
The “NO sync” module 710 tests for DSLAM synchronization issues. A “Can't connect w/sync” module 712 includes tests that are involved with authentication, as well as the capability to verify the assigned dynamic IP address. PPPoE (Point-to-Point Protocol over Ethernet) testing can be performed. A “Can't connect—with sync (legacy static)” module 714 tests connectivity from the customer to the Telco network and includes ATM pings to test connections from the router to the customer and identifies any virtual path or circuit issues, TCP/IP pings, and DNS testing.
In Box 905, the IP Tool can compare data set values, such as tests results or configuration parameters, comprising an IP address or a Set Top Box identification number, for instance, from the first and second dataset in order to determine any changes or differences in configuration parameters in the two data sets that may relate to network problems. For example, a mismatch in a VoIP telephone number in the first and second dataset can be noted. Alternatively, the first and second datasets can be compared in light of a database of provisioning data sets. Usually, when a change is made in the network configuration, for example, an entry in a provisioning database records the change. If a change in telephone numbers, for example, is recorded in a provisioning database, yet the first and second dataset have the same telephone number, then an operator or customer can be notified as to the potential network problem or issue. Conversely, if a phone number or configuration changes between datasets without a corresponding entry in a provisioning data base, a network issue is indicated and an operator or customer can be notified as to the potential network problem or issue. Alternatively, configuration parameters obtained at a network element can be compared to configuration parameters stored in a customer database to detect network problems or issues. For example, an IP address obtained at a router can be compared to the corresponding IP address stored in the customer database. A mismatch between the two IP addresses can be brought to the attention of the network operator.
Although the invention has been described with reference to several exemplary embodiments, it is understood that the words that have been used are words of description and illustration, rather than words of limitation. Changes may be made within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars disclosed; rather, the invention extends to all functionally equivalent structures, methods, and uses such as are within the scope of the appended claims.
In accordance with various embodiments of the present invention, the methods described herein are intended for operation as software programs running on a computer processor. Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware devices can likewise be constructed to implement the methods described herein. Furthermore, alternative software implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the methods described herein.
It should also be noted that the software implementations of the present invention as described herein are optionally stored on a tangible storage medium, such as: a magnetic medium such as a disk or tape; a magneto-optical or optical medium such as a disk; or a solid state medium such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories. A digital file attachment to e-mail or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the invention is considered to include a tangible storage medium or distribution medium, as listed herein and including art-recognized equivalents and successor media, in which the software implementations herein are stored.
Although the present specification describes components and functions implemented in the embodiments with reference to particular standards and protocols, the invention is not limited to such standards and protocols. Each of the standards for Internet and other packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP) represent examples of the state of the art. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same functions are considered equivalents.