Abstract:
A wireless device and a method for providing remote trap management of the wireless device by which a management server remotely sets a trap whose trigger needs to be monitored. A method for providing remote trap management of a wireless device comprises receiving from a remote device a request to install a trap on the wireless device, installing the trap on the wireless device, generating trap status information upon occurrence of a trap and transmitting the trap status information to the remote device in response to the occurrence of the trap.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application claims the benefit of Provisional Application No. 60/661,507, filed Mar. 15, 2005. 
     
    
     FIELD OF THE INVENTION  
       [0002]     The present invention relates generally to remote trap management and in particular, to a system for programming, monitoring and reporting of the status of trap execution on wireless data terminals.  
       BACKGROUND OF THE INVENTION  
       [0003]     Generally, traps are software interrupts. For example, traps are special instructions that are embedded in programs that cause the program to transfer control to a trap handler routine or which are explicitly called when an exception occurs. Typically, after a trap is triggered, the trap handler routine is, executed and the control is transferred back to the program that caused the trap. Traps can also be explicitly set so as to execute a trap handler when a specific condition is met. Since traps are embedded in programs, they cannot be easily changed by external means.  
         [0004]     In wireless devices, there is a need to set traps to gather information about events due to certain conditions on the device. Not all traps can be set a priori. Some of the traps have to be remotely set, i.e., activated and the conditions for a trap trigger should be remotely programmable. Unlike traditional systems, in wireless systems it does not suffice just to execute a trap handler locally. The result of the execution of the trap handler caused by a trap trigger must be sent to a server for purposes of diagnostics. Since wireless devices are resource constrained and bandwidth is at a premium, not every trap trigger needs to be sent to a management server.  
         [0005]     For the various traps that can be set only a sub set of them needs to be monitored and the results sent to an external management server. Just the execution of the trap handler is not sufficient. A monitoring agent on the device should check if any of the traps have been triggered and then at an appropriate time send the results to the management server.  
         [0006]     Since there are many traps that can be set and monitored, a monitoring agent needs a structured way of enumerating the traps that have triggered. A simple list of possible traps will be too inefficient. The traps have to be organized in a hierarchy of categories so that the management server can specify categories of interest. Within each category, specific traps can be monitored.  
         [0007]     Hence, there is a need to efficiently categorize the traps into several classes, and then monitor traps in each class on a wireless data terminal and the according to a policy send the results of a trigger to a management server.  
       SUMMARY OF THE INVENTION  
       [0008]     The present invention is a wireless device and method by which a management server remotely sets a trap whose trigger needs to be monitored. A monitoring agent on the device traverses a trap definition tree to check for triggered traps. For those traps that are enabled by the remote server, the monitoring agent on the wireless data terminal dynamically transfers the trap status code to a management server under appropriate conditions.  
         [0009]     One aspect of the invention is a method by which the management server enables the trap to be set and enables the trap to be monitored. The wireless data terminal, after verification of the server credentials, can install the trap along with the conditions under which the trap status needs to be sent to a management server. The conditions for sending the results may be temporal, spatial, device dependent, network dependent or any combination there of.  
         [0010]     Another aspect of the invention is the specification of the trap tree. The trap tree indicates a hierarchy of trap categories. The categories can be broadly defined based on device state, network state, application state, device action, network action, or application action. Given the lists of traps implemented on the wireless data terminal, the trap handlers are programmed to enable the node based on the category of the trap. For example, battery low or battery fully charged will be classified as a device state trap. A similar trap that falls under the device state category is a memory full event. Examples of traps based on network action include connection failure or a connection failure to an application specific server.  
         [0011]     Yet another aspect of the invention is the definition of trap node that is named and enabled when the corresponding event is triggered. Within each category the type of trap is a node whose name indicates the type of the trap and within each node the names of the trap administration variables and the trap payload. The trap payload defines the form and structure of the trap status information that will be sent to a management server. An example of a trap node is a “device coverage” node and a trap is triggered when the device goes out of coverage. If the trap is enabled, the monitoring agent on the device will send status information in the trap payload whenever the device goes out of coverage. Another example of a trap node is a “roaming” node and a trap is triggered when the device roams away from the home network. Further, the conditions under which the payload is sent can be programmed as well. Conditions include temporal (e.g., every two hours), spatial (e.g., at a given location) or based on the number of occurrence of trap triggers.  
         [0012]     Yet another aspect of the invention is an efficient structure for the trap payload. The trap status may be sent to the monitoring server in a compact form. The trap name or an identifier from a registry, along with the timestamp and location stamp is sent to the server. Since the status could contain the execution of several traps, the payload contains a chained structure of trap status information. The method further includes a means to store the traps status as a tree structure to mirror the categories of the traps on the device. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0013]     The included drawings illustrate the method and system used in remote trap management. Along with the description, these drawings explain the invention and novelty.  
         [0014]      FIG. 1  is an exemplary diagram showing the overall system architecture that consists of a device agent, trap tree, and a management server  
         [0015]      FIG. 2  is an exemplary diagram illustrating the interaction between the management server and the wireless data terminal to program and set a trap remotely on a wireless data terminal  
         [0016]      FIG. 3  is an exemplary diagram showing the interaction between the device agent and the management server in sending a sample trap payload to the server  
         [0017]      FIG. 4  is an exemplary format of a trap tree according to the present invention.  
         [0018]      FIG. 5  is an exemplary flow diagram of a process of trap management and monitoring. 
     
    
     DETAILED DESCRIPTION  
       [0019]     Trap management includes over the air activation/deactivation of trap monitoring and programming of trap generation conditions by means of commands sent from the monitoring server. Trap monitoring includes checking the status of the set traps and generation of traps. Trap reporting includes packaging the status and attributes of any traps that were set and sending it to the monitoring server. The information about all the traps is maintained in a well-defined Trap management tree data structure. The specification trap sub tree data structure defines the nodes of the tree and the semantics associated with the tree.  
         [0020]     An example of an overall system architecture  100  in which he present invention may be implemented is shown in  FIG. 1 . System  100  includes a device monitoring agent  102 , a trap tree  104 , applications  106 , wireless device  108 , network  110 , and a management server  112 . Monitoring agent  102 , on device  108 , checks if any of the traps have been triggered and then at an appropriate time sends the results to the management server  112  via the network  110 . Since there are many traps that can be set and monitored, monitoring agent  102  needs a structured way of enumerating the traps that have triggered. Trap tree  104  organizes the traps in a hierarchy of categories so that the management server  112  can specify categories of interest. Within each category, specific traps can be monitored. Applications  106  are among the entities that may trigger traps, or which may be interrupted by a trap.  
         [0021]     Traps are status messages that are sent to the management server  112  by the device  108  when trap generation conditions are met on any or all the nodes of the trap management tree. An example of this is shown in  FIG. 3 . Traps are reported immediately after a condition associated with trap becomes true. However, if the trap is enabled, the reporting conditions can be set in such a way that the trap payload is sent to the management server only when certain conditions are satisfied. The conditions that could be set on a trap node could be, for example, a change in the Trap Node Attribute, reporting frequency, aggregate conditions (number of trap status changes configured while setting the trap) or that a dependent trap node status has changed. For example, a trap can be set on ‘Device Coverage Node’ to report status when coverage conditions change, when a number, ‘K’, coverage changes have occurred, or to report all coverage changes every 2 hours. A device agent that is monitoring the conditions will set the trap trigger to be true. A series of traps can be defined, not all of which need to be monitored. The number of traps that are set may be independent of the number of traps that are monitored. A trap-enabled directive can be set by a device agent to indicate that the status of the trap is of interest to the monitoring agent at the server. The specific traps to be monitored are sent as commands from the management server to the device agent as illustrated in  FIG. 2 . In particular, management server  112  transmits commands  202  specifying the traps that are to be monitored by device agent  102  to device  108 , where the information in command  202  is used to populate trap tree  104 .  
         [0022]     An example of a trap tree  400  is shown in  FIG. 4 . Trap tree  400  includes trap nodes  402 , trap administration variables  404 , and trap payload  406 . A trap node  402  defines the type of trap that can be set, the trap administration variables  404  reflect the state of the trap, and the trap payload  406  is used to communicate that status of the trap to the monitoring server.  
         [0023]     Turning to  FIG. 3 , the device agent  102  scans all the trap nodes in trap tree  104  to check for the status of the traps. For those traps that have TRAP 13  enabled property set to true and whose trap trigger has been set, a client event alert  302  is sent to management server  112 . If needed, server  112  can then get the complete state of the system that generated the trap event. Appropriate traps can be set in trap tree  104  that allow for reporting diagnostics and performance information to the server. These include: 
        Device Network Coverage (the states include No Coverage, Emergency, Voice and Voice/Data)     Battery conditions     Memory conditions     SIM card insert/removal     Report on Application Install/Uninstall activity     Track voice calls for termination causes     Track durations of voice calls, voice/data calls     Track Network and Location changes     Install Failure     Download failure     APN Connect Failure     MMS Connect Failure     EMAIL Connect Failure     ROAMING Failure     Traps based on threshold        
 
         [0039]     An example of a process  500  by which the management server enables the trap to be set and by which the trap is monitored is shown in  FIG. 5 . Process  500  begins with step  502 , in which the server sends commands including trap setup information to the wireless device, as shown in  FIG. 2 . In step  504 , the device agent uses the trap setup information to install the specified traps into the trap tree. The device agent, after verification of the server credentials, installs the trap along with the conditions under which the trap status needs to be sent to the management server. The conditions for sending the results may be temporal, spatial, device dependent, network dependent or any combination there of.  
         [0040]     In step  506 , the device agent monitors the state of the device, the state of the network, the location of the device, etc. In step  508 , a trap occurs. The trap tree indicates a hierarchy of trap categories. The categories can be broadly defined based on device state, network state, application state, device action, network action, or application action. Given the lists of traps implemented on the wireless data terminal, the trap handlers are programmed to enable the node based on the category of the trap. For example, battery low or battery fully charged will be classified as a device state trap. A similar trap that falls under the device state category is a memory full event. Examples of traps based on network action include connection failure or a connection failure to an application specific server.  
         [0041]     In step  510 , the device agent determines that the monitored states match one or more specified conditions under which trap result status is to be transmitted to the server. Within each category the type of trap is a node whose name indicates the type of the trap and within each node the names of the trap administration variables and the trap payload. The trap payload defines the form and structure of the trap status information that will be sent to the management server. An example of a trap node is a “device coverage” node and a trap is triggered when the device goes out of coverage. If the trap is enabled, the monitoring agent on the device will send status information in the trap payload whenever the device goes out of coverage. Another example of a trap node is a “roaming” node and a trap is triggered when the device roams away from the home network. Further, the conditions under which the payload is sent can be programmed as well. Conditions include temporal (e.g., every two hours), spatial (e.g., at a given location) or based on the number of occurrence of trap triggers.  
         [0042]     The trap status may be sent to the management server in a compact form. The trap name or an identifier from a registry, along with the timestamp and location stamp is sent to the server. Since the status could contain the execution of several traps, the payload contains a chained structure of trap status information. The method further includes a means to store the traps status as a tree structure to mirror the categories of the traps on the device.  
         [0043]     Although specific embodiments of the present invention have been described, it will be understood by those of skill in the art that there are other embodiments that are equivalent to the described embodiments. Accordingly, it is to be understood that the invention is not to be limited by the specific illustrated embodiments, but only by the scope of the appended claims.