Patent Document

CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. provisional application No. 61/706,167, filed Sep. 27, 2012, the contents of which are hereby incorporated by reference herein. 
    
    
     FIELD OF INVENTION 
     This application is related to wireless communication devices, systems, networks and methods of operation. 
     BACKGROUND 
     A log file or simply log is a file that records events taking place in the execution of a system in order to provide an audit trail that can be used to understand the activity of the system and to diagnose problems. The act of keeping a log file is called logging. 
     Logs are essential to understand the activities of complex systems like wireless communication devices, particularly in the case of applications with little user interaction. It may be useful to combine log file entries from multiple sources like network, radio, events and applications. Statistical analysis of these files may yield correlations between seemingly unrelated events which in turn help device manufacturers and network operators improve their product quality and performance. 
     SUMMARY 
     Described herein are a method and system that has the capability to interface with a remote control system and utilize software within wireless devices to activate a debug logger and view and analyze the collected data logs. The general purpose is to have a wide range of measurements with respect to applications, device hardware, device software and network in various simulated and natural environments. 
     The system has the ability to automatically collect data on a 24 hour basis on both test and customer devices. Upon activation, the logging client is deployed and may be left unattended on the wireless device to measure and record information for the duration of the monitoring period. This allows for a comprehensive and accurate picture of the conditions being monitored and the performance of the wireless device in these conditions. 
     The data collected in the log files could be used for improving the quality of the network, the software and applications residing inside the wireless device. It could also be used to communicate and notify an administrator in case of alarm events to take immediate action. 
     The system provides a centralized log service to report all the events that have taken place. It also allows the filtering and recording of log messages to be performed by a separate dedicated subsystem, rather than placing the onus on each application or source to provide its own ad-hoc logging system. The system defines five log sources, namely, system (main), event, radio, global positioning system (GPS) and network. The invention covers log collection, centralized aggregation, long term retention, log analysis in real time and log analysis in bulk after storage as well as log search and reporting. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows an example architecture of a remote control system used for collection of device logs from a wireless device; 
         FIG. 2  shows an example structure of a communication end point gateway or connection proctor; 
         FIG. 3  shows an example architecture of a client software residing on a wireless device; 
         FIG. 4  shows an example structure of a logging module within a device client; 
         FIG. 5  shows an example structure of a logger; 
         FIG. 6  shows an example process of establishing a remote logging session connection; 
         FIG. 7  shows an example flow diagram of an online logging process; 
         FIG. 8  shows an example flow diagram of an offline logging process; and 
         FIG. 9  shows an example high level end to end logging process call flow. 
     
    
    
     DETAILED DESCRIPTION 
     It is to be understood that the figures and descriptions of embodiments have been simplified to illustrate elements that are relevant for a clear understanding, while eliminating, for the purpose of clarity, many other elements. Those of ordinary skill in the art may recognize that other elements and/or steps are desirable and/or required in implementing the embodiments. However, because such elements and steps are well known in the art, and because they do not facilitate a better understanding of the embodiments, a discussion of such elements and steps is not provided herein. 
     Described herein is a method and system that provides a mechanism for collecting wireless device debug output and viewing them in real time on a console user interface and saving the information to a file system. Logs from various applications and portions of the wireless device are collected in a series of native buffers, which can then be viewed and filtered by the file reader of the logging system. 
     The wireless device generally maintains multiple buffers for log messages. Some examples of these buffers are the radio buffer (which is the radio signal of the mobile device which allows you to make phone calls and send messages), events buffer and the system or main buffer. The logging system collects these log messages on a periodic basis or at real time, processes these log messages, formats them into a readable output and then writes the log messages to a server console or database which can be viewed by a remote technician. It also provides the remote technician with an environment where the log messages can be filtered based on its severity and a multitude of attributes. The log messages can be viewed in various different formats and can be saved to a file system. Apart from collecting and presenting device generated log messages, the logging system captures all networks and global positioning system (GPS) related events that occur on the wireless device and presents them to the remote technician. The logging system also has the ability to set alarms to notify the remote technician in case of catastrophic events or errors on the device. The remote technical may also be provided with the ability to specify the time period during which the logs need to be retrieved and whether or not the wireless device needs to be in remote connection with the server during the logging. The logging system also allows for markers to be set on the log messages to help with indexing and easy reading of high volume logs. 
       FIG. 1  is an example overall architecture of a remote logging system which comprises at least a device client residing inside a device (collectively device client and client are referred to as device  10  or device client  10 , as applicable), a control center system  20  and a technician console  30 . The device  10  communicates with the control center  20  through a wireless network  1 , for example. For purposes of readability, block numbers starting with: 1xx relate to the device  10  and its components; 2xx relate to the control center system  20  and its components; and 3xx relate to the technician console  30  and its components. 
     The control center system  20  is responsible for data management, device management, web services, analytics, security management, administrative services and device connectivity. The components of the control center system  20  includes a communication end point gateway (CEG)  200 , an admin and control function or entity  220 , a registration and authentication function module or entity  240 , a data repository  260  and a logging tool  280 . The gateways, modules and/or entities are implemented as or in processors, servers and/or any computing device or system. 
     The CEG  200  manages the device connections within the system. In particular, the CEG  200  provides communication endpoints between the admin and control function module or entity  220  and the device  10 , allows for multiple requests to be serviced within one session from multiple consoles, provides a consistent manner of device connection and tool service in a system with heterogeneous devices running different operating systems, and provides load balancing across multiple connection handlers (as described herein below) on each CEG  200  in order to minimize single point of failure. 
       FIG. 2  shows an example CEG or connection proctor which includes at least a connection monitor  201  and connection handlers  205 . The connection monitor  201  creates and manages connection handlers  205 , creates session IDs for new connection requests and monitors all the scheduled and existing sessions. By default, a connection handler  205  is setup for every CEG, where the number of connection handlers  205  is configurable. All the sessions are load distributed across the connection handlers  205 . Each connection handler  205  handles multiple device sessions. 
     Referring back to  FIG. 1 , the admin and control function or entity  220  administers and manages all types of communication between the control center  20  and the client devices. For example, the admin and control function or entity  220  may include an administrative service that acts as the central administration entity of the system. Through this service, system administrators perform administration, management and instrumentation of all the servers within the system, create and maintain multiple tenants, assign tenant administrator roles, and other like functions. In another example, the admin and control function or entity  220  may have a management service which provides the operational end point to the system and performs load distribution among the CEG, management of device registration, administration of devices and session queuing. A management entity may be included which is responsible for providing the management service with in-memory data storage for key operational data user/group/zone structures, and the like. In another example, the admin and control function or entity  220  may have a service coordinator which is responsible for coordinating the communication between various elements within the system. It provides the database interface to the registration and authentication function  240 . All services register themselves with the service coordinator. The service coordinator is responsible for service discovery. 
     The data repository  260  stores all the information about the devices  10 , server configuration, tasks and status settings. These databases are pivotal to configure and update managed devices and server components. It is also responsible for maintaining the device authentication information. The data repository  260  may comprise three database (DB) elements: an admin DB, operations (Ops) DB, and a reports DB. The admin DB maintains all the system configurations, tenant configuration and management information, system administration and server instrumentation data. This database is accessed by the administrative service. The Ops DB maintains data that is required for the operations of the system such as device enrollment, groups, users, zones, and the like. This database is accessed by the management service and the service coordinator. The reports DB contain historical data of device enrollment, session, audit, report views, and the like. 
     The registration and authentication function  240  provides a single point of entry for all devices for enrollment and authentication services during a session. In an example, the registration and authentication function  240  comprises a registration service. In another example, the registration and authentication function  240  includes an enrollment service, which is responsible for enrolling registered devices with the system. In another example, the registration and authentication function  240  includes a software update module which manages the various client packages in the system. Devices connect to the software update module to request client updates. If an update is available, the software update module will provide the appropriate client download link. 
     The logging tool  280  interfaces with both the technician&#39;s console  30  and the device client  10 . The logging tool  280  receives instructions from the technician to start the logging process. These instructions might include the time period during which the log messages need to collected, the severity of the log messages and filters that need to be applied to the log message in order to reduce the amount of data received for easy reading. The device client  10  is activated by a short message service (SMS) message which initiates a secure communication channel between the console  20  and device client  10 . The logging tool  280  then processes the instructions received from the technician and relays it to the device client  10 . The device client  10  initiates the process of recording and capturing log messages based on the instructions received. These instructions might include various sub commands which specify how and when the log messages need to be collected. In an example, only for log messages containing fatal errors might be requested. In another example, log messages with specific tags or process ids might be requested. The logging tool  280  also performs the function of receiving the log messages from the device client  10 . Once received, the log messages are formatted into a readable output. The logging tool  280  is responsible for transferring the logs received from the device client  10  onto the remote technicians console and displaying it in the desired structure. The logging tool  280  is also responsible for writing the log messages to a database or a file system when desired. 
     The device client  10  includes at least device management modules  100 , application sub-layer  120 , session layer  140  and data link layer  160 . These modules are explained in detail in  FIG. 3 . 
     Referring to  FIG. 3 , the device client module includes a virtual mobile management (VMM) layer or entity  300 , an access control entity  310  and a communication core  320 . The VMM entity  300  includes a VMM manager  301 , VMM modules  302 , a state machine  303 , a tool service coordinator  304 , and a non-volatile data repository  305 . 
     The VMM modules  302  provide a multitude of tool services. The tool services are grouped together to exhibit common functionality such as remote control and log management. The Logging Module  400  which is one of the VMM modules  302  is described in more detail further in the  FIG. 4  and  FIG. 5 . Each tool service maintains an instance of a state machine  303 , which defines a set of shared states that the tool service on the device application shares with the control center  20 . The tool service coordinator  304  maintains the lifetime of all tool services, and is responsible in creating and destroying tool services. 
     The non-volatile data repository  305  stores authentication and authorization specific data that is shared between the VMM application and the control center  20 . The non-volatile data repository  305  also serves the purpose of maintaining tool service configuration as well as VMM configuration data. 
     The access control entity  311  provides a set of functions to the tool services to communicate with the control center  20 . The access control entity  311  provides encapsulation of messages before forwarding it to the communication core layer  320 . It invokes an instance of the communication core layer  320  and provides a state machine  313  that defines the state of the VMM application. 
     The access control entity  311  interacts with an access control interface (ACI)  312 , which provides a set of standard Application Programmer Interfaces (API) to the tool services. These APIs provide a consistent communication platform to facilitate both synchronous as well as asynchronous communication. The state machine  313  identifies the overall state of the VMM application. State transitions within the state machine  313  trigger events that are handled by the VMM layer  300 . The states are open and close and traffic flows through the ACI  312  only in the open state. 
     An authentication entity  316  is responsible for ensuring that the device  10  receives a connection and processes requests from the control center  20  with which it is enrolled. The authentication entity  316  ensures data integrity, security and authentication. 
     A message routing entity  314  is responsible for routing all signal messages destined to tool services to the respective event handlers. 
     A message processing function  315  is a signal message pre-processor and receives signal messages from the session layer  322  destined towards tool services. The message processing entity de-frames these messages prior to forwarding it to the message routing entity  314 , which applies the routing rules. Messages that are destined to the control center  20  from tool services are encapsulated in the message processing entity. 
     The communication core layer  320  setups and maintains a dedicated communication channel with the control center  20 . The communication core layer  320  provides the necessary framework to transport messages between the upper layers  300  and  310  and the control center  20 . The communication core layer  320  provides message encapsulation, framing, fragmentation and packet re-construction of tool service messages. 
     Referring back to  FIG. 1 , the technician console  30  comprises a Graphical User Interface, Communication Engine, Protocol Stack and the Control Center APIs. The technician can use the graphical user interface to initiate the logging process on the device. The technician is also provided with the environment to configure the collection filters. These filters include specifying the log level, log type, process id, tracking id, application name and so on. The technician can also specify the log collection duration and type. The different types of logging are extended logging, periodic logging and offline logging. The log messages received from the device client are parsed and decoded to a readable output. This is then displayed on the graphical user interface and can be viewed by the technician. The log files can also be saved to the database or a remote file system. 
     Referring to  FIG. 4 , a logging module  400  is responsible for pulling the log messages from the device native buffers, recording events related to changes in network and GPS location of the device and relaying the log data back to the control center  20 . In an example, the logging module  400  includes a Log Message Listener entity or module  410 , Logger entity or module  420 , Log Manager entity or module  430 , Log Transporter entity or module  440 , Buffer entity or module  450  and Communication message bearer entity or module  460 . Inside the wireless device operating system, every application runs its own process, each of which runs its own virtual machine. Each virtual machine exposes a unique port that a debugger can attach to. The debugger writes the log messages to a set of native buffers. When the remote technician initiates the logging process, the control center sends a logging command to the device. This logging command includes information about when to start and stop logging, log level, log types and markers, for example. For example, the logging command might be to retrieve all event logs with the log level error and process id x. The Log Message Listener entity or module  410  receives these commands through a bearer channel. The logging command is then parsed and decoded for further action. The Communication message bearer module  460  contains detailed information about each command that might be sent from the control center  20 . Some examples of these bearer commands are Start Logging Request, Start Logging Response, Enable Device Info Logging Request, Disable Device Info Logging Request and so on. The decoded command is then sent to the Logger module  420  which starts pulling log messages from the device native buffers and records events related to location and network change. The log messages that are retrieved are stored in the Buffer  450  in case of online logging and into a file system in case of offline logging. The Log Manager  430  is responsible for pulling all the log messages from the Buffer  450  or file system and composing a log post message. Each log post message includes a pre-determined number of log messages. The log post is then transferred to the control center  20  by the Log Transporter  440  over the communication bearer channel. 
     Referring to  FIG. 5 , The Logger module  420  includes a Device Info module or entity  422 , Debug Monitor module or entity  427  and Marker module or entity  421 . The Device info module or entity  422  is responsible for recording events and changes in the device location and network. The Device info module or entity  422  includes a Location listener  423 , a GPS log record  424 , a Phone State Listener  425  and a Network log record  426 . The Location listener  423  tracks any changes in the wireless device location. When the change occurs, the information is sent to the GPS Log record  424  which composes the log message. The log message has the following information—TimeStamp, Latitude, Longitude and Description. The Description contains provider name, location accuracy, altitude, speed and so on. The Phone State listener  425  tracks any changes to the wireless device data network. When a change occurs, the information is sent to the Network Log Record  426  which composes the log message. The log message contains the following information—Timestamp, Latitude, Longitude, Network Event Type, Network Type, Signal Strength and Description. The Description contains active network, network type, state, operator name, operator code, roaming, signal description, network id, base id and so on. 
     The Debug Monitor function module or entity  427  includes the following components—Device Monitor Service (DMS) Logger  428 , and DMS Log Record  429 . The DMS Logger  428  is responsible for keeping track of the device native buffers and pulling the log messages from the native buffer every time a new log message is written. This log message is sent to the DMS Log Record function  429  which formats the data into a readable output and appends additional information to the log message. The additional information might include the log level, the log type, log filters, message length and so on. The following are some exemplary log levels that might be available. An example log level may be ERROR, which indicates the system is in distress, customers are probably being affected and the fix probably requires human intervention. Another example log level may be WARN, which indicates an unexpected technical event occurred, customers may be affected but probably no immediate human intervention is required. Another example log level may be INFO, which includes system lifecycle events, session lifecycle events and significant boundary events. Another example log level may be DEBUG, which is used for entry/exit of most non-trivial processing, and marking interesting events and decision points. Another example log level may be ALL, which includes extremely detailed and potentially high volume logs. The Log Type specifies which native buffer the log messages were pulled from and may include System, Event and Radio, for example. The log filters help with filtering the log messages to reduce the volume of data that needs to be transferred and helps the remote technician analyze the data conveniently. Some exemplary filters are timestamp, process id, tracking id, tag, application name, and version. The appended information helps the control center  20  filter and categorize the log messages for convenient viewing. 
     The log files usually contain a lot of low level data. During wireless device testing, errors and failures could be caused by a lot of known external factors. Marker function  421  provides the remote technician with the ability to specify event start and event end markers inside the log files when these external factors take effect to reduce the amount of data that need to be analyzed by the remote technician. 
       FIG. 6  describes an example flow of control during a connection establishment. The CEG  200  receives a Control Signal (C-S) link connection request from Technician Console  30 . An Authentication Request is received by CEG  200  from the Technician Console  30  (1) and an Authentication Response is sent by CEG  200  to Technician Console  30  (2). The C-S link is established (3) followed by authentication (4) and acknowledgement (5). A PEER_CONNECT_REQ signal is received by CEG  200  from Technician Console  30  (6). The CEG  200  sends a Mobile Terminated SMS to Device  10  (7). The CEG  200  receives a Data Signal (D-S) link connection request from Device  10  (8). An Authentication Request is received by CEG  200  from Device  10  (9). An Authentication Response (shown as an ACK) is sent by CEG  200  to Device  10  (10). A PEER_CONNECT_REQ signal sent by CEG  200  to Device  10  (11). An acknowledgement (ACK) is received by CEG  200  from Device  10  (12). An ACK is transmitted by CEG  200  to Technician Console  30  (13). A TOOL_SVC_REQ is received by CEG  200  from Device  30  (14). A TOOL_SVC_REQ is relayed by CEG  200  to Logging Tool  40  (15). The CEG  200  receives a Data Bearer (D-B) link connection from Logging Tool  40  (16). The CEG  200  receives an ACK from Logging Tool  40  for the TOOL_SVC_REQ (17). An ACK is relayed by CEG  200  to Technician Console  30  (18). The CEG  200  receives Control Bearer (C-B) link connection request from Technician console  30  (19). At this point, the control plane and bearer plane is (are) established (20). The log data is carried over the bearer channels (21). 
       FIG. 7 , along with  FIG. 5 , describes an example logging process when the wireless device is online and is in remote connection with the control center. The command to start the logging process is sent to the wireless device through the bearer channel ( 705 ). An example of such command could be an Enable DMS logging for Log Level Error and Log Type Radio. Another example could be Enable Device Info Logger for network events. The Log Msg Listener  410  parses and decodes the bearer message ( 710 ). The Logger  420  receives the decoded message and activates the DMS  427  or Device info logger  422  ( 715 ). Taking the above mentioned command as an example, the DMS logger  427  would pull the log messages from the device Radio buffer ( 720 ). The Device info logger  422  records network related events. All the log messages are written to a Buffer  450  within the logging tool ( 725 ). The Log Manager  430  pulls the log messages from the Buffer  450  and composes a log post message ( 730 ). The Log Transporter  440  sends the log post message to the control center  20  over the bearer channel ( 735 ). 
       FIG. 8 , along with  FIG. 5 , describes the logging process when the wireless device is offline or loses data connection. As described above, the command to start the logging process is sent to the wireless device through the bearer channel ( 805 ). The Log Msg Listener  410  parses and decodes the bearer message ( 810 ). The Logger  420  receives the decoded message and activates the DMS  427  or Device Info Logger  422  ( 815 ). The DMS logger  427  pulls the log messages from, for example, the device Radio buffer ( 820 ). All the recorded log messages are written to the Buffer  450  with the logging tool ( 825 ). During this process, if the bearer channel is broken or the device loses data connection, all the log messages in the buffer  450  are transferred to a file system within the device ( 830 ). The Logger  420  continues to write log messages to the file system as long as the device is offline ( 835 ). Once the device comes back online, the bearer channel is reestablished ( 840 ). All the logs in the file system are transferred to the control center  20  in the correct order. Once all the files have been transferred, the Logger  420  continues writing the log messages into the Buffer  450  ( 845 ). 
       FIG. 9 , along with  FIG. 5 , describes the high level end to end logging process. A Technician configures the collection options, as described herein above, on the remote system ( 905 ) and initiates the logging process. An SMS is sent to the device to wake up the device client  10  ( 910 ). Once the device client  10  is awake ( 915 ), it exchanges authentication information with the remote system. The configuration parameters received are then analyzed ( 920 ). The device client  10  begins recording logs from the native buffers and recording GPS and Network related events ( 925 ). The recorded event logs and state information is forwarded to the remote system ( 930 ). The remote system parses and decodes the log messages received ( 935 ). The logs are compressed and stored in the database ( 940 ). Post processed logs are then retrieved and displayed on the graphical user interface on the technician&#39;s console ( 945 ). 
     While detailed embodiments of the instant invention are disclosed herein, it is to be understood that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. Therefore, specific functional and structural details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representation basis for teaching one skilled in the technology to variously employ the present invention in virtually any appropriately detailed structure. 
     Although features and elements are described above in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements.

Technology Category: 5