Abstract:
A computer readable storage medium stores a set of instructions executable by a processor. The set of instructions is operable to receive, from a user device, a query relating to a degradation of performance of the device within a network; receive, from a transceiver station, a record relating to a time to send data to the device; and identify the existence of an error in the device based on a determination that the time is greater than a predetermined threshold.

Description:
BACKGROUND 
       [0001]    Fault detection is an important part of the operation and maintenance of wireless networks. However, even once it has been determined that a fault exists, faults must be isolated before they can be addressed and repaired. In particular, it is important to distinguish between faults that exist at the network level and faults in user equipment. 
       SUMMARY OF THE INVENTION 
       [0002]    A computer readable storage medium stores a set of instructions executable by a processor. The set of instructions is operable to receive, from a user device, a query relating to a degradation of performance of the device within a network; receive, from a transceiver station, a record relating to a time to send data to the device; and identify the existence of an error in the device based on a determination that the time is greater than a predetermined threshold. 
         [0003]    A network device includes a memory and a processor. The processor is configured to receive, from a user device, a query relating to a degradation of performance of the device within a network. The processor is further configured to receive, from a transceiver station, a record relating to a time to send data to the device. The processor is further configured to identify the existence of an error in the device based on a determination that the time is greater than a predetermined threshold. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0004]      FIG. 1  shows an exemplary communications network. 
           [0005]      FIG. 2  shows an exemplary method for detecting and isolating faults in a communications network such as the network of  FIG. 1 . 
       
    
    
     DETAILED DESCRIPTION 
       [0006]    The exemplary embodiments may be further understood with reference to the following description and the appended drawings, wherein like elements are referred to with the same reference numerals. The exemplary embodiments describe methods and systems for detecting and isolating the source of network faults. 
         [0007]    Troubleshooting of networks includes both fault detection and isolation of detected faults. In particular, it may be beneficial to isolate faults that are local to user equipment, rather than to network equipment, in order not to dedicate resources to network faults that may not exist, but rather to alert a user to the presence of faults in user equipment and thereby enable fault resolution to occur as quickly as possible. The exemplary embodiments present methods and systems by which faults that are local to user equipment may be detected and isolated in response to a request that has been initiated from the user equipment itself. 
         [0008]      FIG. 1  illustrates an exemplary system  100 . The system  100  includes a user device  110 , which may include, for example, a mobile phone, a smart phone, a palmtop computer, or any other type of user device that may perform and benefit from the exemplary embodiments. The user device  110  may be in communication with a UMTS terrestrial radio access network (“UTRAN”)  120 . The UTRAN  120  may include a plurality of Node B elements  130 ,  132  and  134 , which may be in direct communication with user equipment; in this exemplary embodiment, the user device  110  is currently communicating with the Node B  130 . 
         [0009]    The Node B elements  130 ,  132  and  134  may, in turn, be controlled by one or more radio network controllers (“RNC”), such as RNC  140  and  142 . These may coordinate the flow of data from the user device  110  and other user devices to other points in the network, and vice versa. The RNC  140  and  142  may be in communication with a mobile switching center (“MSC”)  150  and a serving GPRS support node (“SGSN”)  160 , both of which may further coordinate network traffic. The UTRAN  120  may further be operated by a network server  170 , with communications to and from the network server  170  occurring via an IP network  180 . Those of skill in the art will understand that the system  100  is only exemplary and that the broader principles described herein may be applied to any type of network. 
         [0010]      FIG. 2  illustrates an exemplary method  200  by which faults in user equipment may be detected and isolated. The method  200  will be described specifically with reference to the system  100  of  FIG. 1 , but those of skill in the art will understand that the method  200  may also be applicable to other types of user equipment. In step  210 , a query is initiated at the user device  110 . This may occur due to an action by a user of the device in response to a degradation in performance or may be initiated automatically by a device that has detected a similar degradation of performance. In step  220 , the query is received by the Node B  130 , which may be specifically configured to handle such queries, and, in response, forwards the query directly to the network server  170  by using an IP address of the network server  170 . This may be accomplished without forwarding the query to RNC  140  and  142 . 
         [0011]    In step  230 , the network server  170  receives the query that has been forwarded by the Node B  130  in step  220  and, in response, requests, from the Node B  130 , round trip time (“RTT”) measurement reports relating to the querying user device  110 . RTT along the interface between the user device  110  and the Node B  130  may be defined as the time measured between sending a downlink frame to the user device  110  and receiving the appropriate uplink frame from the user device  110 , on the first detected path in the case of multi-path receiving. In step  240 , the Node B  130  sends the requested RTT reports to the network server  170 . RTT reports provided may be, for example, all reports over a most recent predetermined period of time, e.g., the last five minutes. 
         [0012]    In step  250 , the network server  170  calculates an average RTT and determines whether the average RTT is greater than a predetermined threshold value. The threshold value may typically be customizable based on the preferences of a service provider and the characteristics of the network. If the average RTT is greater than the predetermined threshold value, the method continues in step  260 ; if the average RTT is less than the threshold value, the method continues in step  290 , which will be discussed below. 
         [0013]    In step  260 , the network server  170  requests and receives real-time RTT monitoring from the Node B  130 , in order to provide further data that may be used to diagnose the network issues that resulted in the initial query in step  210 . Upon receiving real-time RTT monitoring data, in step  270 , the network server  170  may determine the root cause of the network issues. In one exemplary embodiment, the network server  170  may perform an algorithm to determine the cause of the network issues based on this monitoring. In one embodiment, such an algorithm may involve prompting the Node B  130  to send a test message to the user device  110  and determine whether an acknowledgement is received from the user device  110 . If an acknowledgement is not received, or is received late, the network server  170  may then determine that the failure is localized to the user device  110  or to the link between the user device  110  and the node B  130 , rather than elsewhere within the system  100 . 
         [0014]    If, in step  270 , the network server  170  determines that the root cause of the network issues lies with the user equipment  110 , then, in step  280 , the network server  170  notifies the user device  110 , via the Node B  130  or by other means, that the fault has been isolated to the user device  110  itself. This step may optionally also include automated troubleshooting that may be conducted either remotely by the network server  170 , or locally by the user device  110  in response to receiving a notification of a local issue from the network server  170 . Alternately, if the network server  170  determines that the root cause of the issues lies with the network (e.g., within UTRAN  120 , with the MSC  150 , with the SGSN  160 , with the network server  170 , etc.), then in step  290 , the network server  170  notifies network maintenance personnel about the issues in order that they may be resolved at the network level. After step  280  or step  290 , the method terminates. 
         [0015]    The exemplary embodiments may thus enable a determination to be made, at the network level, as to whether a problem is due to a fault in network equipment or in user equipment. Further, this determination may be made without the use of a network controller, such as RNC  140  and  142  of  FIG. 1 . The exemplary embodiments may also enable automated troubleshooting to proceed upon making a determination that a problem lies with the user equipment. By providing users with notification of a problem that is local to their user devices, and providing automated troubleshooting, a high level of user satisfaction may be achieved. 
         [0016]    It will be apparent to those skilled in the art that various modifications may be made in the present invention, without departing from the spirit or the scope of the invention. Thus, it is intended that the present invention cover modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.