KR101668451B1 - Smart home device with self-diagnosis and Method of doing self-diagnosis by the same device - Google Patents

Abstract

The present invention relates to an apparatus and method for monitoring a call reception disabled state of a terminal itself and restoring the terminal to a normal state when a smart home terminal malfunctions.
According to the present invention, a method for self-diagnosing a failure of a smart home terminal having a call application and a wireless access application includes diagnosing a failure of the terminal by monitoring an operation state of at least one of the call application and the wireless access application ; And restoring the fault by initializing or restarting at least one of the call application and the radio access application according to the fault type of the diagnosed terminal.

Description

[0001] The present invention relates to a smart home terminal having a self-diagnosis function and a self-diagnosis method for such a smart home terminal,

The present invention relates to a smart home terminal having a self-diagnosis and recovery function and a self-diagnosis method of such a smart home terminal, and more particularly to a smart home terminal, To an apparatus and a method capable of restoring the system to a user.

BACKGROUND ART [0002] Recently, various smart home terminals such as a smart home phone and a smart home pad have become popular in the home, so that various applications are executed using a smart home terminal, and in particular, a call service is used by using an internet network.

However, a malfunction of an application installed in a smart home terminal and a case where a call using a smart home terminal can not be received due to various reasons such as an error in interworking with a wireless communication network (e.g., a Wi-Fi network 0) may occur.

Conventionally, when a customer calls a customer center to notify the user of a failure situation in which a call can not be received, the customer remotely solves the problem, but causes considerable inconvenience to the customer.

Accordingly, there is a need for a function that can detect a malfunction that causes a terminal to be in a state of unable to receive a call, and recover the terminal to a normal state.

In order to solve the above problems, the present invention provides a smart home terminal having a fault diagnosis and recovery function, and a fault diagnosis and recovery method in such a smart home terminal.

The present invention also relates to a smart home terminal capable of primarily diagnosing and restoring a fault and secondarily diagnosing and restoring the fault under the control of the server in cooperation with the terminal management server, And to provide a method for diagnosing and recovering faults in the system.

According to an aspect of the present invention, a method for self-diagnosing a failure of a smart home terminal having a call application and a wireless access application monitors the operation state of at least one of the call application and the wireless access application, Diagnosing; And restoring the fault by initializing or restarting at least one of the call application and the radio access application according to the fault type of the diagnosed terminal.

In one embodiment, the method further comprises confirming at least one of whether the terminal is opened during initialization of the terminal and whether the terminal is wirelessly connected.

In one embodiment, the step of confirming whether the terminal is opened during the initialization of the terminal comprises the steps of: transmitting the terminal activation information request message to the call application; Determining whether a terminal activation information response message is received from the call application in response to the request message; And checking whether the terminal is opened by checking whether authentication information for the terminal is included in a message received from the call application.

In one embodiment, the method further comprises restarting the call application if the terminal activation information response message is not received from the call application.

In one embodiment, the method further comprises: transmitting the terminal unacknowledged information to the integrated terminal management server when the terminal is confirmed to be in an uncontrolled state as a result of checking whether the terminal is open; And waiting until a connection completion event is received from the call application.

In one embodiment, the step of checking whether the terminal is wirelessly connected includes a step of waiting until a wireless connection completion event is received from the wireless connection application when the terminal is not wirelessly connected.

In one embodiment, the step of diagnosing a failure of the terminal includes checking whether a Session Initiation Protocol (SIP) registration completion event is received within a predetermined period from the call application.

In one embodiment, diagnosing the failure of the terminal includes periodically transmitting a normal operation check request message to the call application and determining whether a response to the normal operation check request message is received.

In one embodiment, diagnosing the failure of the terminal comprises checking the terminal resource usage of at least one of the call application and the wireless access application.

In one embodiment, the step of diagnosing a fault in the terminal comprises checking a resource usage of the call application, and in the event that the resource usage is abnormal, recovering the terminal may restart the call application .

In one embodiment, the step of diagnosing a failure of the terminal includes: checking the wireless connection status of the terminal when the resource usage is normal; Determining whether the Internet connection is normal if the wireless connection state of the terminal is normal; And confirming a registration status of the call application, wherein when the call application is in an unregistered state, restoring the terminal initializes the call application.

In one embodiment, the step of diagnosing a failure of the terminal may include checking a wireless connection state of the terminal when the resource usage is normal, checking the resource usage of the wireless access application if the terminal is in an abnormal state, Wherein the step of restoring the terminal, when the resource usage is abnormal, causes the wireless connection application to be restarted.

In one embodiment, the method includes receiving an initialization command for the call application from an integrated terminal management server; Initializing the call application in accordance with the initialization command; And transmitting the SIP registration information based on the SIP registration completion event received from the initialized call application to the integrated terminal management server.

A smart home terminal according to another aspect of the present invention is a smart home terminal having a memory, a processor, and a communication interface for a wireless LAN connection, A wireless access application; And a self-diagnosis application for diagnosing and repairing a failure of the smart home terminal by monitoring an operation state of the call application and the wireless access application.

According to an embodiment of the present invention, the present invention enables self-refresh and recovery of a smart home terminal. In addition, according to the present invention, the smart home terminal primarily performs a fault diagnosis and recovery function on its own, and secondarily operates in conjunction with a Unified Customer Equipment Management System (UCEMS) Diagnosis and recovery can be performed.

FIG. 1 illustrates a communication environment of a smart home terminal according to an embodiment of the present invention.
FIG. 2 illustrates a configuration of a smart home terminal according to an embodiment of the present invention.
3 is a flowchart illustrating a self-diagnosis method of a smart home terminal according to an exemplary embodiment of the present invention.
FIG. 4 is a detailed view illustrating the interactions between a call app, a wireless access app and a self-diagnosis app of a smart home terminal according to an embodiment of the present invention.
5 illustrates a process of initializing call app information by UCEMS and a self-diagnosis app according to an embodiment of the present invention.
FIG. 6 illustrates a process of restarting a call application by UCEMS and a self-diagnosis app according to an embodiment of the present invention.
7 illustrates a process of rebooting a terminal by UCEMS and a self-diagnosis app according to an embodiment of the present invention.
FIG. 8 illustrates a process of changing a call application transport setting by a UCEMS and a self-diagnosis app according to an embodiment of the present invention.

While the present invention has been described in connection with certain exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and similarities. It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In the following description of the present invention, detailed description of known related arts will be omitted when it is determined that the gist of the present invention may be unnecessarily obscured.

In addition, the singular phrases used in the present specification and claims should be interpreted generally to mean "one or more " unless otherwise stated.

Also, the terms "module,""part,"" interface ", and the like used in the present specification generally mean a computer-related object and may mean, for example, hardware, software and combinations thereof.

FIG. 1 illustrates a communication environment of a smart home terminal according to an embodiment of the present invention.

As shown, in one embodiment, the smart home terminals 110a, 110b, and 110c are connected to a Unified Customer Equipment Management System (UCEMS) 120 through a wired / wireless network, 120 are connected to a call application server (call AS 130), a home subscriber server (HSS) 140 and a session boarder controller (SBC) 150 via a wired network.

In one embodiment, the smart home terminal 110a, 110b, or 110c is a terminal that provides various Internet services and a call service through a wired / wireless network, and may be a smart home phone, a smart home pad, a service over IP It can include various types. Basically, the smart home terminal 110a, 110b, or 110c may provide various functions through various applications installed on a specific operating system, and may be provided to a user through a call application and a wireless connection application (e.g., a WiFi connection application) Internet telephone service can be provided. The smart home terminal according to an embodiment of the present invention can self-diagnose a call reception disabled state and perform self recovery processing. The self-diagnosis and recovery of the smart home terminal will be described in detail with reference to FIG. 2 to FIG.

In one embodiment, the integrated terminal management server (UCEMS) 120 manages the non-receivable terminal DB (not shown) and re-authenticates the smart home terminal based on the non-receivable terminal DB, Initialization / re-driving, or re-driving the terminal device itself, it is possible to remotely control the recovery of the terminal from being impossible to receive. In one embodiment, the non-receivable terminal DB includes non-receivable terminal information received from at least one of a call application server (call AS 130), a home subscriber server (HSS) 140 and a SBC (Session Boarder Controller) As shown in FIG.

The call application server (call AS) 130 is a server for performing call service logic control and profile management for a smart home terminal. In one embodiment, the call application server (call AS) 130 may send a call request to the smart home terminal or the smart home terminal that is confirmed as unregistered due to a smart home terminal failure, IP unassignment, temporary loss, (UCEMS) 120, for example, a smart home terminal that is unresponsive within a predetermined period (e.g., 5 seconds).

The HSS 140 is a server for managing subscriber information and service trigger information. In one embodiment, when the SIP registration request is received from the smart home terminal 110a, 110b or 110c, the HSS 140 performs authentication for the corresponding terminal, records information about the terminal that has failed authentication, Server (UCEMS, 120).

The SBC 150 refers to a device that is located at a network boundary and provides various functions in a session-based multimedia service (e.g., VoIP service). The SBC 150 may be located between a user network and a service network, A protection function, a function as a relay server, and a traffic management function. In one embodiment, the SBC 150 monitors whether a Re-Regi Request message is periodically received from the smart home terminal 110a, 110b or 110c and if not, deletes the corresponding subscriber, And provides smart home terminal information of the subscriber to the integrated terminal management server (UCEMS) 120.

FIG. 2 illustrates a configuration of a smart home terminal according to an embodiment of the present invention.

In general, the smart home terminal 200 is a computing device having a memory, a processor, and a communication interface for wireless LAN access. It is assumed that a call application (app) 210 and a wireless connection application (app) 230 for performing a call function through a wireless LAN connection are installed in the memory of the smart home terminal 200. A self-diagnosis application (app) 220 according to an embodiment of the present invention is also installed in the memory to monitor the operation status of the call application 210 and the wireless access app 230 to diagnose a failure of the smart home terminal And can recover.

3 is a flowchart illustrating a self-diagnosis method of a smart home terminal performed in a self-diagnosis app according to an embodiment of the present invention.

In step 310, it is determined whether or not the terminal is opened when the terminal is initialized. In one embodiment, the self-diagnosis app sends a terminal activation information request message to the call application and determines whether a terminal activation information response message is received from the call application in response thereto. When a response message is received from the call application, it can be confirmed whether the terminal is opened by checking whether or not the received message contains authentication information for the terminal. If it is confirmed that the terminal is unstructured as a result of confirming whether the terminal is opened, it transmits terminal unacknowledged information to the integrated terminal management server, and waits until a connection completion event is received from the communication app. On the other hand, if the terminal activation information confirmation response message is not received from the call application, the call application can be restarted.

In step 320, it is determined whether the terminal is wirelessly connected. If it is determined that the terminal is not wirelessly connected, the terminal waits until a wireless connection completion event is received from the wireless access app.

If it is determined through step 310 and step 320 that the terminal has been opened and is wirelessly connected, the terminal is assumed to be in an operating state.

In step 330, during the operation of the terminal, the operation status of at least one of the call app and the wireless access app is monitored to diagnose the failure of the terminal.

In one embodiment, the self-diagnosis app can diagnose a failure of the terminal by checking whether a SIP (Session Initiation Protocol) registration completion event is received within a predetermined period from the call application.

In one embodiment, the self-diagnosis app can diagnose the failure of the terminal by periodically transmitting a normal operation check request message to the call app and determining whether a response to the normal operation check request message is received.

In one embodiment, the self-diagnosing app can diagnose the failure of the terminal by examining the terminal resource usage of the call app and / or the wireless access app.

In one embodiment, the wireless access state of the terminal may be checked if the resource usage of the self-diagnosing application is normal, and if the wireless access state is normal, it may be determined whether the Internet access is normal. It is also possible to determine whether or not the registered application of the call application is in the registered state.

In step 340, at least one of the call app and the wireless access app is initialized or restarted depending on the type of the failure of the terminal, thereby recovering the failure. A concrete restoration method will be described in detail with reference to FIG.

4A and 4B are diagrams illustrating details of a mutual operation between a call app, a wireless access app and a self-diagnosis app of a smart home terminal according to an embodiment of the present invention.

(1) When the smart home terminal is booted, the self-diagnosis app requests the terminal activation information from the calling application in step (401). In one embodiment, the request and response messages are data interworking between intents using sendBroadcast. An example of a request / response intent is shown below.

Request activation information action: com.kt.sip.call.REQUEST_CALL_CONFIG

■ Activation information response action: com.kt.sip.call.RESULT_CALL_CONFIG

Example) Intent serviceIntent = new Intent ("com.kt.sip.call.REQUEST_CALL_CONFIG");

sendBroadcast (serviceIntent);

(2) In step 402, it is checked whether the terminal activation information is received from the call app. In one embodiment, if the UE-initiating information response message is not received, it can be requested again up to three times at intervals of one minute.

(3) If the terminal activation information response message has not been received even three times, the self-diagnosis app determines whether the call application is initialized (step 403). At this time, it is possible to determine whether the call app is initialized by checking whether the initialization state variable (sendJ & Treset) of the call app is true or false. If the calling app is not in an initialized state, it enters a waiting state (step 406). If the calling app is already initialized, it restarts the calling app (step 412).

(4) When the terminal access information response message is received, it may be determined whether the terminal is opened based on the terminal access information response message (step 404). In one embodiment, if at least one of the following required field values in the VoIP config sync response is null, it can not be registered in the server, and therefore, the call app is judged to be in the 'unacknowledged state'.

① "USER_ID": phone number

② "SBC_ADDR": primarySBC server address

③ "SBC_PORT": primary SBC server port

④ "AUTH_ID": Authentication ID

⑤ "AUTH_PASSWORD": Password

(5) When the call application is in the 'unopened state', the self-diagnosis app transmits the unopened information of the terminal to the integrated terminal management server (step 405). In one embodiment, the unacknowledged information is transmitted to the integrated terminal management server in the form of TR-069 Inform. The history of the untested terminal is transmitted to the terminal management server so that the manager can confirm the history and perform necessary remote control. In one example, the terminal unacknowledged information transfer uses the InternetGatewayDevice.DeviceInfo object interface and the transfer key information is as follows.

■ SerialNumber: Terminal MAC Address

■ ProvisioningCode: "Not-Registered"

(6) The self-diagnosing app that transmitted the 'uncooked state' information is in a standby state. At this time, the status of the self-diagnosis app becomes "SIP not provisioned". When receiving a SIP-Registered event from the calling application, the standby state is canceled (step 408). When the call application is completed, the self-diagnosis app transmits the completion event. The self-diagnosis app recognizes that the terminal is normally opened when receiving a connection completion event from the calling application.

(7) It is determined whether the terminal is wirelessly connected (step 407). In one embodiment, the isConnected () method of the 'android.net.NetworkInfo' class is used to determine the WiFi connection state.

(8) If the WiFi connection is not established, the mobile terminal enters a standby state (step 408). The waiting state is released when receiving an IP information delivery intent sent from a wireless access app. When the wireless access application obtains normal IP information, it broadcasts an intent message as follows. When the self-answering app receives the message, the terminal recognizes that the wireless connection is normally established.

■ IP information delivery intent Action com.kt.wifi.notification ExtraParameter "TYPE "IP_INFORM "IP" "xxx.xxx.xxx.xxx" "STATICIP boolean "AUTOCONN boolean "NOT_SIPNCHECK boolean

(9) Steps 409 to 411 are a process for monitoring for fault diagnosis and action of the terminal. In one embodiment, whether or not the registration completion event of step 409 is received and the normal operation check of the call application in steps 410 and 411 can be simultaneously performed. In one of these two conditions, if the normal monitoring condition fails, the call app's resource usage check can proceed.

(10) Check whether the registration completion event from the calling application is received within a certain period (for example, 2 minutes and 30 seconds). When the call app sends a SIP REGISTER request message through the wireless network, it sends a registration completion event to the call app. The self-diagnosis app will monitor the registration completion event message and if not received for 2 minutes 30 seconds (150 seconds), it will proceed with the scenario to check the abnormal state of the calling app.

Details of SIP registration completion event message are as follows

Action com.kt.sip.call.action.REGISTRATION ExtraParameter

(11) The self-diagnosis app transmits a health check request message for checking whether the call app is operating normally (step 410), and monitors whether a response is normally received from the call app (step 411). The request message for the operation status check is transmitted at a predetermined time interval (e.g., 10 minutes), and can be retried at intervals of one minute upon non-response.

(12) When the self-diagnosis app does not receive the registration completion event message from the calling application or does not receive the response to the operation status check message, the self-diagnosis application executes the diagnosis of the terminal resource usage of the calling application (step 412). In one embodiment, it is possible to diagnose whether a call app is normal based on CPU usage and memory usage. For example, if the CPU usage is more than 80% or the memory usage is 50% (measured as averaged over a 10-second interval, for example), then the calling app is abnormally occupied It can be judged.

(13) If it is determined in step 412 that the communication application is abnormal, the communication application process is restarted (step 427). In one embodiment, a rebooting notification window may be displayed to the user, and the user may proceed to restart the process by selecting "Restart ".

(14) If it is determined in step 412 that the communication application is normal, the wireless access state of the terminal can be determined (step 413)

(15) If the wireless connection of the terminal is good, it can be checked through the DNS query command whether the Internet connection is normal (step 414). Obtains the DNS server address of the terminal and transmits a DNS query command using a specific domain name. In one embodiment, up to three attempts may be made at intervals of one minute.

(16) If it is determined that the Internet connection of the terminal is abnormal, a WifFi reconnection is attempted (step 415). If the WiFi reconnect event is in the WiFi connection state and the DNS query fails, the wireless access application is informed that the connected wireless connection is in an abnormal state and can be instructed to reconnect after making the disconnect state. In one embodiment, the WLAN connection is set to the " DISCONNECT "state via the " LINKERROR" message among the APIs provided by the wireless access app, and the WLAN is reconnected through the "RECONNECT" message.

■ Wireless LAN connection request tent Action com.kt.sip.notification ExtraParameter "TYPE" "COMMAND" "CMD" "LINKERROR" Action com.kt.sip.notification ExtraParameter "TYPE" "COMMAND" "CMD" "RECONNECT"

(17) If the Internet connection of the terminal is normal, it is confirmed whether the calling application is executing the call service (step 416). In one embodiment, the CallState value of the Line object can be used to determine whether the calling application is in the call service state. If the received CallState value is "Calling", "Ringing", "Connecting", "InCall", "Hold", "Disconnecting"

(18) If the calling app is not busy, the registration status of the calling app can be checked at step 417. In one embodiment, the checking of the registration status of the call app can use the status value of the Line object. The state values of the Line object are as follows.

status









"Up",: Registration completion status (normally registered status)
"Initializing",: Initialize the registration state
"Registering",: Registration attempt (RREGISTER)
"Unregistering",: Disabling the properties
"Error",: Registration attempt failed
"Testing",: terminal self test mode
"Quiescent "," Quiescent "," Quiescent ",&
"Disabled",: Unable to register (unconfigured information, network abnormal)
Service registration successful: Up
Service registration failure: Error
Service Information Not Set (Initial Value): Disabled

(19) If it is confirmed that the calling application is unregistered as a result of the checking of the registered state of the calling application, a reset command is transmitted to the calling app (step 428), and the self-diagnosis application internally transmits a reset command to the calling app. Quot; sendJ & Treset "indicating the initialization state is recorded as 'true' (step 418). Thereafter, the self-diagnosis app is switched to an initialization state (step 419). If sendJ & Treset value is true and the self-diagnostics app is in the initialization state and the self-diagnosis app receives a terminal activation information response message from the calling app, "sendJ & Treset = false" will be set.

(20) In one embodiment, the Call Application Reset command may be delivered in the same Intent message as the existing TR-069 Reset command. The intent message details are as follows. The self-diagnostic app broadcasts the following intent.

■ Reset call application information (Intent) Action com.kt.sip.call.SET_LINE_CONFIG ExtraParameter "SEND_MSG" "Action_TR_RESET"

(21) If it is determined in step 413 that the wireless connection of the terminal is abnormal, the self-diagnosis app transmits an operation check request message to the wireless access app to check whether the wireless access app is operating normally (step 421) , And monitors whether the response is normally received (step 422). In one embodiment, if an operation check response message is not received from the wireless access app, it may be repeated two more times in 1 minute increments. In one embodiment, for operational state check, use the "STATUSEX" event and the message details are as follows.

■ intent for operation check Action com.kt.sip.notification ExtraParameter "TYPE" "COMMAND" "CMD" "STATUSEX"

(22) When an operation check response message is received from the wireless access app, the wireless access app is determined to be in normal operation and is in a self-diagnosis wait state (step 424).

(23) When a response to the operation check request is not received from the wireless access app, the wireless access app is diagnosed to use the terminal resource (step 423). In one embodiment, the diagnosis is based on CPU usage and memory usage. If the CPU usage is more than 80% or the memory usage is more than 50% and it is maintained for a certain period of time (eg, measured as averaged value sampled every 10 seconds for 1 minute), the wireless access app abnormally seizes resources . You can use the totalPss value of the MemoryInfo class to determine memory usage. This resource usage threshold selection criterion is WiFi on-off repetition, and the monitoring result is based on the result of wireless apps recording about 5% CPU usage and less than 1% memory usage.

(24) If the resource usage of the wireless access app is normal, the WiFi is restarted (step 425). WiFi re-driving means that the connected WiFi is turned off and then on. This behavior can be achieved using the setWifiEnabled (arg) method of the android.net.wifi.WifiManager class.

(25) If it is determined that the wireless access app is abnormally occupied by the terminal resource, if WiFi is ON, WiFi is turned off and then turned on (step 426).

In the above-described embodiment, the self-diagnosis application self-diagnoses the failure type of the terminal in the smart home terminal and restores the failure type. However, in another embodiment, the self-diagnosis app is interlocked with the integrated terminal management server (UCEMS) It can also be recovered. Hereinafter, with reference to FIG. 5 to FIG. 8, a process of restoring a terminal failure by interlocking with the integrated terminal management server (UCEMS) and the self-diagnosis application will be described.

5 illustrates a process of initializing call app information by UCEMS and a self-diagnosis app according to an embodiment of the present invention.

1) The operator can send a Reset Call Application Information command via UCEMS (510).

2) The call application information initialization command is transmitted to the terminal in the form of TR-069, and the self-diagnosis app of the terminal receives these commands (520).

3) The self-diagnosis app delivers the call application information initialization request to the call application (530). Accordingly, the call app will perform an initialization operation.

4) When the call application completes the SIP registration after performing the initialization operation, the SIP application transmits the SIP registration completion event to the self diagnosis app (530).

5) The self-diagnosis application receiving the SIP registration completion event transmits the SIP registration information to UCEMS (540). The operator checks the SIP registration information received from the terminal and determines that the terminal is restored to the normal state.

FIG. 6 illustrates a process of restarting a call application by UCEMS and a self-diagnosis app according to an embodiment of the present invention.

The UCEMS forwards the Restart command to the terminal determined to be unreceivable (610).

2) The recommended app sends a normal operation check request message to each app to confirm the normal state of the calling application and the wireless access application, and confirms the response. If the result of the normal operation check on the call app and the wireless access app is normal, the UCEMS transmits status information on the app for the call app (620).

3) On the other hand, if a response is not received from the two applications as a result of the normal operation check for the call application and the wireless access application, the call application is restarted and information of the restarted call application is transmitted (630).

7 illustrates a process of rebooting a terminal by UCEMS and a self-diagnosis app according to an embodiment of the present invention.

1) The operator can send a terminal reboot command through UCEMS (710).

2) The terminal reboot command is received by the self-diagnosis app of terminal in TR-069 format, and the self-diagnosis app reboots the terminal by using reboot () method of PowerManager class.

3) Upon completion of the terminal reboot, the self-diagnosis app transmits the boot or bootstrap information to UCEMS (720).

4) The operator checks BOOT or BootStrap information received from the terminal and determines that the terminal is restored to a normal state.

FIG. 8 illustrates a process of changing a call application transport setting by a UCEMS and a self-diagnosis app according to an embodiment of the present invention.

1) UCEMS transmits a TR069 message for changing the transport setting of the call application to the self-diagnosis app of the terminal (810). In one embodiment, '0' may be a value for setting UDP, and '1' may be a value for setting TCP in setting a transport of a call application.

2) The self-diagnostics app sends a transport configuration change message to the calling app (820).

3), if the transport information request is received from the UCEMS 830, the self-diagnosis app delivers the corresponding request message to the calling application 840, and transmits the transport information received from the calling app to the UCEMS 850 , 860).

A method of self-diagnosis of a smart home terminal according to an embodiment of the present invention may be implemented in the form of a program command which can be executed through various computer means and recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, and the like, alone or in combination.

Program instructions to be recorded on a computer-readable medium may be those specially designed and constructed for the present invention or may be available to those skilled in the computer software arts. Examples of computer-readable media include magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Includes hardware devices specifically configured to store and execute program instructions such as magneto-optical media and ROM, RAM, flash memory, and the like. The above-mentioned medium may also be a transmission medium such as a light or metal wire, wave guide, etc., including a carrier wave for transmitting a signal designating a program command, a data structure and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like.

The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

The embodiments of the present invention have been described above. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

Claims (15)

A method for self-diagnosing a fault in a smart home terminal having a call application and a wireless access application,
Confirming at least one of whether the terminal is opened and whether the terminal is wirelessly connected when the terminal is initialized;
Monitoring the operation status of at least one of the call application and the wireless access application to diagnose the failure of the terminal; And
And restoring the fault by initializing or restarting at least one of the call application and the radio access application according to the fault type of the diagnosed terminal,
Wherein the step of confirming whether the terminal is turned on when the terminal is initialized comprises:
Transmitting a terminal activation information request message to the calling application;
Determining whether a terminal activation information response message is received from the call application in response to the request message; And
And checking whether the terminal is opened by checking whether or not the terminal authentication information response message received from the call application includes authentication information for the terminal
A method for self-diagnosis of a smart home terminal.
delete delete The method as claimed in claim 1, further comprising restarting the call application if the terminal activation information response message is not received from the call application.
The method as claimed in claim 1, further comprising: transmitting terminal unacknowledged information to the integrated terminal management server when the terminal is confirmed to be in an uncontrolled state as a result of checking whether the terminal is open; And
Waiting until a connection completion event is received from the call application
Further comprising the steps of:
The method according to claim 1,
Wherein the step of checking whether the terminal is wirelessly connected comprises:
Waiting until the wireless connection completion event is received from the wireless connection application when the terminal is not wirelessly connected
The method comprising the steps of:
The method of claim 1, wherein the diagnosing a fault of the terminal comprises checking whether a Session Initiation Protocol (SIP) registration completion event is received within a predetermined period from the call application.
The method of claim 1, wherein diagnosing a fault of the terminal comprises periodically transmitting a normal operation check request message to the call application and determining whether a response to the normal operation check request message is received.
9. The method of claim 8, wherein diagnosing a failure of the terminal comprises checking at least one terminal resource usage of the call application and the wireless access application.
9. The method of claim 8, wherein diagnosing a failure of the terminal comprises checking resource usage of the call application, and when the resource usage is abnormal, recovering the terminal comprises: A self-diagnosis method of a smart home terminal that drives a smart home terminal.
10. The method of claim 9, wherein diagnosing a failure of the terminal comprises: checking a wireless connection state of the terminal when the resource usage is normal; Determining whether the Internet connection is normal if the wireless connection state of the terminal is normal; And confirming a registration status of the call application, wherein, when the call application is in an unregistered state, restoring the terminal initializes the call application.
The method of claim 9, wherein the step of diagnosing a failure of the terminal comprises the steps of: checking a wireless connection state of the terminal when the resource usage is normal; and determining a resource usage of the wireless access application if the wireless connection state is abnormal. Wherein the step of restoring the terminal, when the resource usage is abnormal, restarts the wireless access application. The method of claim 1, further comprising: receiving an initialization command for the call application from an integrated terminal management server;
Initializing the call application in accordance with the initialization command; And
Transmitting SIP registration information based on a SIP registration completion event received from the initialized call application to the integrated terminal management server
Further comprising the steps of:
A smart home terminal having a memory, a processor and a communication interface for wireless LAN access,
Currency application;
A wireless access application; And
The mobile terminal monitors at least one of whether the terminal is connected to the terminal and whether the terminal is wirelessly connected to the terminal at the initialization of the terminal and monitors the operation state of the communication application and the wireless access application to diagnose the failure of the smart home terminal, And a self-diagnosis application for restoring the fault by initializing or restarting at least one of the call application and the radio access application according to a fault type of the terminal,
The self-diagnosis application transmits a terminal activation information request message to the call application, determines whether a terminal activation information response message is received from the call application in response to the request message, and transmits a terminal activation information response message By checking whether authentication information for the terminal is included in the authentication information
Smart home terminal.
A smart home terminal equipped with a self-diagnosis application including a command for performing a self-diagnosis method of a smart home terminal according to any one of claims 1 to 13.

Images