Patent Application
20080317006
The present invention relates to communication technologies, in particular, to a method for managing a communication terminal device, a communication terminal and a communication system.
At present, the number of mobile phone users approaches 200 million in China. As the user requirements become more and more diversified and individualized, the innovation of Chinese telecommunication becomes deeper and deeper, and as fixed phones and mobile phones are reassembled and perfected, the service providers begin to provide more and more abundant services to users, such as Broadcast (BCAST) service, Voice over Internet Protocol (VoIP) service, Push-to-Talk Over Cellular (PoC) service, etc.
VoIP is a technology that is implemented mainly based on IP (Internet Protocol) phone and that provides corresponding value-added services. With VoIP, transferring of service information including voice, fax, video and data, such as storing and forwarding of a virtual phone, Internet call management, television conference and various information may be implemented on an IP network at low cost.
A VoIP system that is suitable for a Mobile Terminal (MT) is defined by the PoC service. By using the packet switching capability of the wireless data network, the Poc service is unlimited by geographic locations.
The Open Mobile Alliance (OMA) is working on the standardization of PoC service. The OMA's PoC solution is based on the Session Initiation Protocol (SIP) and RealTime Transfer Protocol (RTP) defined by the Internet Engineering Task Force (IETF).
With the development of communication technologies, the scale of network becomes larger and larger, and its architecture becomes more and more complex. To improve the Quality of Service (QoS) and lower the operation cost, an effective network management system needs to be established. As a result, Telecommunications Management Networks (TMN) emerge as the times require.
TMN provides a policy and a method for planning, supervising, designing and controlling telecommunication resources, network activities, services and managements, and it provides a system with telecommunication network Operation Administration Maintenances (OAM) functions for operators/managers and terminal users. By employing a management network over all the telecommunication networks, not only an overall and effective supervision and management on the network resources may be realized, but also the network systems may be interconnected, so that it is possible to open a service over multiple management regions.
The realization of TMN may be divided into two parts: Part 1, a system for monitoring and controlling telecommunication resources below the network layer is established, so that interface communication may be realized between sub-networks, thus a transparent controlling and monitoring may be realized on local network, access network and Synchronous Digital Hierarchy (SDH); Part 2, a decision-supporting system of the telecommunication network is established on the network layer, so that management services facing the 21st century may be developed, such as user management, network provision management, labor force management, billing, charging and accounting management, QoS and network performance management, traffic measurement and analysis management, maintenance management, security management, log management, etc.
Most of the TMN system configuration information models employ the hierarchical structure of a tree to describe the hierarchical structure of the configuration model, which is referred to as a configuration information model tree.
In the so called information models, the network resources are divided into many small units that need to be managed from the viewpoint of management, then these small units are abstracted so as to generate Management Objects (MOs). In brief, the information model is an MO set abstracted from the resources managed by the network management system. Resource management is implemented indirectly by processing these resource abstract entities, MOs. A manager that is responsible for issuing a command and an agent that is responsible for executing the command are needed, so as to accomplish a management operation by using the MOs exchange information. To accomplish the command, the agent should know the object to be processed, such as its name, attribute, subordination, etc. All of such information is obtained from a Manager Information Base (MIB). The information in the MIB is organized organically according to a rule. By employing the method of information models, the MIB arranges the abstracted MOs logically from top to bottom according to a rule of subordination and derivation, so that a tree structure is formed. In other words, the above information model tree that facilitates searching is established.
In the OMA Device Management (DM) specification, a TMN technology for managing, diagnosing and maintaining a terminal is worked out, and a server may perform management operations, such as firmware update, application download, diagnostic and monitoring, backup and restore and so on, for a terminal via the DM management tree. The terminal may be a mobile phone, a Personal Digital Assistant (PDA), a NoteBook computer, a embedded device, an on-board system, etc.
The existing OMA DM specification provides a software component management technology, i.e., a mechanism for a DM server to manage the software component on the terminal.
The software component may be an executable application, a dynamic link library, a user interface (UI) and so on. The management operation may be terminal parameter configuration, firmware update, fault diagnostic, backup or restore, as well as the query, installation, update, activation or removal of the software component.
The overall structure described by the DM specification is as shown in
In the DM specification, the method for managing software component is as shown in
In Step 201, a DM server queries the inventory of the installed software components from a terminal.
In Step 202, the terminal requests authorization from the user.
In Step 203, the user confirms the authorization.
In Step 204, the terminal sends a software component inventory to the DM server.
In Step 205, the DM server initiates a software component downloading and installation operation to the terminal.
In Step 206, the terminal returns the confirmation to the DM server.
During the research, the inventor finds that the above solution has the following disadvantages: only the static state, such as the adding, removing and modifying of the software component, can be controlled; to effectively receive the service distributed by the network side all the time, the terminal has to keep its service function, such as service receiver, in Running state, and when no service is to be received, a service function in Running state may cause the corresponding hardware resources to consume unnecessary electric energy, thus the power consumption of the communication terminal may be great, and meanwhile, the resources such as the Central Processing Unit (CPU) of the terminal may be occupied. As a result, waste may be caused.
An embodiment of the invention provides a method for managing communication terminal device, which includes: sending a device management command, which comprises a control instruction for an activity state of a designated function, to a terminal; and performing, by the terminal, an operation on the activity state of the designated function according to the control instruction.
An embodiment of the invention further provides a corresponding communication terminal, which includes: a function module, adapted to provide a function; a device management agent, adapted to receive and resolve a device management command, wherein the device management command comprises a control instruction on the activity state of a designated function; and a device management service function client, adapted to perform an operation on the activity state of the designated function according to the control instruction.
An embodiment of the invention further provides a communication system, which includes a communication terminal and a DM server, the device management server is adapted to send a device management command, which comprises a control instruction for an activity state of a designated function, to the communication terminal; and the communication terminal is adapted to perform an operation on the activity state of the designated function according to the control instruction.
It may be found by comparison that: in the technical solution of the invention, DM technology is reinforced, so that it may have the function of remotely controlling the activity state of an application, for example, controlling the start, stop or suspend and resume of an application.
Before carrying out a service, an application related to the service may be started remotely on a terminal by a DM server in advance, so that it can be guaranteed that the service may operate normally. Because the related application may be started in time before a service needs to be carried out, the application no longer needs to be run on the terminal all the time. Therefore, the precious electric energy of the terminal may be saved.
When a service is being carried out, an application related to the service that is running on the terminal may also be suspended remotely by the DM server, so that the CPU resources of the terminal occupied by the application may be decreased when the application does not need to be run, and meanwhile the electric energy of the terminal may be saved. When the application needs to be run again, because the resources occupied by the application, except for the CPU, are not released, the Running state of the application may be resumed rapidly by sending a remote resume instruction to the terminal via the DM server. As a result, the user experience may be reinforced.
Additionally, the related application may also be started immediately when a service is carried out, or the related service function may be started at predetermined service distribution time according to a pre-established service distribution plan. The requirements of different services can be better met by using these two modes flexibly.
To make the objects, technical solutions and advantages of the invention more apparent, the invention will now be further described in detail in conjunction with the drawings.
In the invention, the service provider sends a message which includes a control instruction on the activity state of a designated function, to a terminal, and the terminal performs the corresponding control operation on the designated function according to the control instruction contained in the message. The control operation includes operations of start, stop, suspend, resume and so on.
The so-called function in the present specification is a general term, which may be a software executable in the execution environment of the terminal, a segment of a program, a procedure, a segment of a script language (such as XML) and so on. For example, the function may be a diagnostic process, a Trap function or a Scheduling Component, etc.
In the embodiments of the invention, a state transition of the function is as shown in
Additionally, the service provider may also send a message which includes an instruction to suspend or resume a designated function, to the terminal via the DM server, and the terminal suspends or resumes the designated function according to the instruction contained in the message. It is possible to perform the suspend operation only when the function is in Running state.
The method for starting or stopping a communication terminal function according to the first embodiment of the invention is as shown in
In Step 401, when a service needs to be carried out for a terminal, a service provider first submits a query request to a DM server. For example, a service server on the network side instructs the DM server to query whether the function of the service on the terminal is started, i.e., whether the function is in Running state.
Specifically, the main command of the query is as follows:
In Step 402, the DM server issues a device management command and queries the current state of the function from the terminal. The DM server and the DM Agent of the terminal interact with each other via the standard OMA DM protocol.
In Step 403, the terminal returns a query result:
It is supposed that the result obtained is that the function is in Stopped state.
In Step 404, the DM server returns the query result to the service server.
In Step 405, according to the query result, if the service function that needs to be started is not started, the service server sends a message to the DM server and delivers an operation instruction to start the function in the message.
In Step 406, the DM server forwards the message to the DM Agent of the terminal, and issues a management command to start a Diagnostic Function on the terminal:
In Step 407, after receiving the DM command, the DM Agent determines whether the source of the DM command is valid. If it is valid, the DM Agent interprets the message and obtains the operation instruction contained in the message; otherwise, the DM Agent rejects the DM command.
As for the problems of security, privacy and so on, the DM Agent further sends an enquiry message to the user via the UI of the terminal according to the operation instruction, and requests the user to determine whether to accept the service.
If the user has configured a default operation on the service, the DM Agent does not need to perform the process for obtaining the confirmation from the user. Instead, the DM Agent processes the command issued by the DM server directly according to the default operation configured, and then turns to Step 409.
In Step 408, the user may confirm the service via the UI. If the user does not want to accept the service or if it is inconvenient for the user to accept the service, the user may perform a cancellation operation. If the user accepts the service, an admission operation is performed. If the user neither performs a cancellation operation nor performs an admission operation, a default processing mode may be configured. For example, it may be regarded that the user rejects the service.
The confirmation message (accept or reject), for example, which indicates that the user accepts the service, is returned to the DM Agent via the UI of the terminal.
The above Step 407 and Step 408 are optional. The user may preset a policy to trigger user confirmation in the terminal. For example, when the server sends a command to control the function for the first time, the user needs to confirm, but afterwards, the server may send a command directly to control the function.
In Step 409, the terminal executes the command sent by the DM server and starts the function of the service based on the user admission. A DM tree may be stored in the terminal, which includes a node for starting a function and a node for stopping a function. If the two nodes are both executable nodes, the DM Agent directly triggers the corresponding executable node according to the control instruction included in the command sent by the DM server, so as to perform the corresponding start or stop operation on the designated function via an enabler module of a DM service function client. If the two nodes are both indication nodes in the DM tree, the DM Agent modifies the value of the corresponding indication node according to the instruction in the command sent by the DM server, and the terminal performs the corresponding start or stop operation on the designated function by monitoring the change in the value of the indication node.
After the corresponding start (or stop) operation is performed, the operation result is reported to the DM server.
If the user rejects the service according to the determination, the DM server is notified to terminate the service request.
In Step 410, the DM server notifies the service server of the operation result.
In Step 411, when the received operation result indicates that the terminal service is started, the service server establishes a contact with the terminal and begins to distribute a service to the terminal or manage the service. If the returned operation result indicates that the terminal service is stopped, the connection with the terminal is disconnected, and the distribution or management operation on the service for the terminal is stopped.
According to the above method, the related function may be started in time before a service needs to be carried out, and the function no longer needs to be run on the terminal all the time, so that the precious electric energy of the terminal may be saved. Additionally, the function that is started or stopped remotely may be a diagnostic function, and the network side may thereby obtain information such as whether other functions are normal, the state of a designated function and so on. Thus, the working state of the terminal may be monitored flexibly.
The method for starting or stopping a communication terminal function according to the second embodiment of the invention is as shown in
In Step 501, a service server sends a start instruction of the function needed by a service to a DM server.
From Step 502 to Step 504 are similar with from Step 406 to Step 408 respectively.
In Step 505, after obtaining the user admission, the DM Agent executes or ignores the start instruction according to the state of the designated function in the terminal. For example, if the designated function is in Running state, the instruction to start the designated function in the DM command is ignored.
If the designated function in the terminal is in not-Running state, the instruction to start the designated function in the DM command is executed.
Then, the operation result, i.e., the function is in Running state currently, is reported to the DM server. Additionally, if the user confirmation message is Reject, the DM server is notified to terminate the service request.
Step 506 and Step 507 are similar to Step 410 and Step 411 respectively, so they will not be described again here.
The method for starting or stopping a communication terminal function according to the third embodiment of the invention is as shown in
In Step 601, a service server makes a service distribution plan or a service management plan. The plan may be based on time. For example, the BCAST server may broadcast a service to the terminal at 10:00-11:00 and 16:00-17:00 every day according to a timetable, and instructs the terminal to start the BCAST client according to the time segment in the timetable. The plan may also be based on the event on the terminal. For example, the terminal is instructed to stop the function automatically when the automatic update of the function is finished.
Then, the service server submits the service distribution plan to the DM server via a Web Service Interface (WSI) of the DM server. The service distribution plan includes the function ID, time or condition, and so on.
In Step 602, the DM server generates a Scheduling according to the service distribution plan submitted by the service server. The Scheduling includes a trigger condition and a predetermined operation. For example, the trigger condition is 10:00 AM, and the predetermined operation is to start a BCAST function on the client.
Then, the DM server sends the Scheduling generated to the DM Agent of the terminal via the standard OMA DM protocol.
In Step 603, the DM Agent requests the user to determine whether to install the Scheduling via the UI of the terminal.
If the user sets a default operation for the service, the DM Agent does not need the user confirmation, and directly processes the Scheduling according to the default operation, and turns to Step 606.
In Step 604, the user may confirm the Scheduling via the UI. If the user does not want to accept the service or if it is inconvenient for the user to accept the service, the user performs a cancellation operation. If the user accepts the service, he performs an admission operation. If the user neither performs a cancellation operation nor performs an admission operation, a default processing may be performed. For example, it may be regarded that the user rejects the service.
The confirmation message (accept or reject), for example, which indicates that the user accepts the service, is returned to the DM Agent via the UI of the terminal. Additionally, the user may also modify the Scheduling via the UI. For example, the user may modify the timetable, so that the broadcast is received only in the time segment of 10:00-11:00.
The DM Agent instructs the terminal to install the Scheduling and run the Scheduling according to the user admission or modification. If the user confirmation message is Install Rejected, the Scheduling is cancelled.
In Step 605, when the trigger condition of the Scheduling is met, for example, when the time reaches 10:00 or the function update is completed, the user is requested to confirm whether to perform the start or stop operation of the function corresponding to the Scheduling, for example, whether to begin to receive the broadcast service.
However, a default operation may also be configured, and the default operation may be performed accordingly, rather than requesting the user to confirm.
Step 606 is similar to Step 408.
In Step 607, the DM Agent performs the predetermined operation in the Scheduling based on the user admission, and starts the function that is in activated state currently (or stops the function, for example the DM Agent performs a stop operation at 11:00), and returns an operation result to the DM server.
If the function is in Running state when the terminal performs the start (or stop) operation, the start (stop) instruction in the DM command is ignored.
Step 608 is similar to Step 410, so it will not be described again here.
In Step 609, the service server establishes a contact with the terminal and starts the service distribution or service management if the operation result returned is Start. If the returned operation result is Stop, the connection with the terminal is interrupted, and the service with the terminal or the management operation is stopped.
The related service function may be started immediately when the service is carried out, or may be started at a predetermined service started time according to a pre-established service started plan. The requirements of different services can be better met by using these two modes flexibly.
The structure of the communication terminal according to the fourth embodiment of the invention is as shown in
Taking the function of the BCAST service and PoC service as an example, the structure of the system for implementing communication among the communication terminal 30, the DM server 40 and the service server is as shown in
the DM Agent 32 interprets the device management command issued by the DM server 40 and provides the control instruction therein to the DiagMon client 330.
The DiagMon client 330 mainly includes the following modules:
a state query module 3301, which is adapted to support the DM server 40 to query the state of a function on the terminal;
a start/stop enabling module 3302, which is adapted to support the start and stop of the software. The terminal may realize the start and stop of a function by controlling the related executable node via the start/stop enabling module after a command sent by the DM server 40 is received. The start/stop enabling module is a logic function module, which may lie in the DM service function client, or in other position.
The DM service function server 4 mainly includes the DM server 40, the DM server is adapted to send a management instruction to a terminal and receive a message returned by the terminal.
The Service server 5 and the server 4 interact with each other via a WSI interface.
The user interface 34 is adapted to send an authorization request to a user and accept an authorization from the user when the DiagMon client 330 executes a control instruction.
The DiagMon client 330 may also interact with other DM service function clients 331, such as the application management client, Scheduling client, etc.
The DM Agent may provide a control instruction to the DM service function client by operating the node of the DM tree. Corresponding to
<Interior Node/x>
<Interior Node> means interior node, which is the root node of the service function MO. The MO may be a ScoMO, a DiagMon MO, a Scheduling MO or an Application Management MO, etc.
<x> is a placeholder, the specific information and the related executable operation of the function installed is stored under this node.
For convenience, <Interior Node/x> is replaced by <./x> in the description below.
Specifically, <./x/ID> (ID)
The software ID is stored in this node.
<./x/StateValue> (State)
This node indicates the state of the software. The value of the node may be as follows:
<./x/Operations> (Operation)
This node is the father node of a series of executable nodes.
<./x/Operations/Start> (Start Operation)
This node is an executable node, which is adapted to start a function or a process. For example, 0 indicates the initial state or the completion of an operation, and 1 indicates that the function needs to be started.
<./x/Operations/Stop> (Stop Operation)
This node is an executable node, which is adapted to stop a function or a process. For example, 0 indicates the initial state or the completion of an operation, and 1 indicates that the function or process needs to be stopped.
The Start and Stop node may also be referred to as Run node, Exit node etc. The specific interpretation and execution are accomplished by a service function module of the terminal.
<./x/Operations/Remove> (Remove Operation)
This node is an executable node, which is adapted to uninstall a function or a process. For example, 0 indicates the initial state or the completion of an operation, and 1 indicates that the function should be removed.
<./x/Operations/Ext> (Extensible Operation)
This node is reserved for future extension.
In the above embodiments, although the Start node and Stop node are defined in each service function MO, the start and stop of a function may also be implemented by invoking these nodes in the Scheduling mode, as shown in
Mode 1: The communication terminal receives a predetermined task, which includes a command (instruction) to start or stop a terminal function. The terminal starts the Scheduling client 332, and invokes the corresponding DM service function client, such as the DiagMon client 330, when the condition is met. The executable node that is adapted to start or stop a function is executed, so as to start or stop the designated function. However, other DM service function clients 334 may also be invoked according to a specific control instruction.
Mode 2: The communication terminal receives a predetermined task, which includes a segment of a code or a function, for starting or stopping a terminal function. The terminal starts the Scheduling client 332, and a bottom-layer operating system executes the segment of the code or the function in the predetermined task to start or stop the designated function when the condition is met.
Additionally, an interface may also be provided on the basis of the above embodiment, so that the user may configure whether it needs to prompt to the user for confirmation before the function is started. For example, the user may configure as follows: when the server sends a command to start the function for the first time, the user needs to confirm; but afterwards, the function may be directly started without the confirmation of the user. Thus, unnecessary confirmation may be avoided in a specific application environment, and the service experience of the user may be improved.
The method for suspending or resuming a communication terminal function according to the fifth embodiment of the invention is as shown in
Specifically, the suspend operation may only be performed on a function when the function is in Running state, so that the function may turn to Suspended state; and the resume operation may only be performed on the function when the function is in Suspended state, so that the function may turn to Running state.
From Step 1201 to Step 1204 are similar with from Step 401 to Step 404.
In Step 1205, the service server analyzes the current state of the designated function received and determines whether to send an instruction to suspend or resume a designated function to the terminal. Because the suspend operation may be performed on the function only when the function is in Running state, and the resume operation may be performed on the function only when the function is in Suspended state, if the designated function is in Running state when a suspend instruction is to be sent, or if the designated function is in Suspended state when a resume instruction is to be sent, Step 1206 is executed; otherwise, the process ends.
In Step 1206, the service server sends a suspend request or a resume request, which includes an instruction to suspend or resume a designated function, to the terminal. By suspending the designated function that is in Running state, the CPU resources of the terminal occupied by the function may be reduced when it is not necessary to run the function, and meanwhile, the electric energy of the terminal may be saved.
In Step 1207, the DM server sends the corresponding suspend or resume command to the DM Agent in the terminal according to a request from the service server.
In Step 1208, after the DM Agent receives the DM command from the DM server, if the node for suspending and resuming a function in the DM tree of the terminal is an executable node, the DM Agent triggers the corresponding executable node directly according to the control instruction contained in the DM command, and the designated function is suspended or resumed by the enabling module in the DM service function client. If the node for suspending and resuming a function in the DM tree of the terminal is an indication node, the DM Agent modifies the value of the corresponding suspend indication node or resume indication node according to the instruction in the DM command, and then the terminal suspends or resumes the function correspondingly by monitoring the change in the value of the indication node.
If the designated function is suspended, the function does not occupy the CPU resources of the terminal, but still keeps the occupation of other resources. When it is required to run the function again, the Running state of the function may be resumed rapidly by sending a remote resume instruction via the DM server, because the resources of the terminal occupied by the function, except for CPU resources, are not released. Therefore, the user experience may be reinforced.
Step 1209 and Step 1210 are similar to Step 409 and Step 410, so they will not be described again here.
The structure of the system for suspending and resuming a function according to the sixth embodiment of the invention is as shown in
The DM service function server 7 mainly includes a DM server 70. The DM server is adapted to send a management command to the terminal 60 and receive a message returned by the terminal 60.
The service server 8 and the server 7 interact with each other via a WSI interface.
The terminal 60 includes a function module 61, a DM Agent 62, a DM service function client 63 and a user interface 64.
The function module 61 provides a function and an execution environment thereof, and is responsible for controlling the actual execution of the operation, such as start, stop, suspend and so on. The execution environment may be Java or a local application platform.
The DM Agent 62 is responsible for interpreting and executing the fundamental DM protocol between the DM Agent 62 and the DM server 70, and obtaining a control instruction related to the function management, including operation, command and so on. The DM Agent 62 is also responsible for maintaining a DM tree, such as DiagMon MO. Relevant information of diagnostic functions, such as the function ID, name, operation, is stored on a DiagMon management tree. The operation includes start, stop, suspension, resume and so on.
The DM service function client 63 is adapted to control the activity state of the designated function according to the control instruction obtained by the DM Agent 62. The DM service function client 63 mainly includes a state query enabling module 6301 and a start/stop enabling module 6302, the functions of which are similar to those of the modules with the same name modules in the fourth embodiment. The DM service function client 63 further includes a suspend/resume enabling module 6303, which is adapted to support suspending and resuming a function in Running state.
The user interface 64 is adapted to send an authorization request to a user and accept an authorization admission from the user when the DM service function client 63 executes a control command.
The DM Agent may provide a control instruction to the DM service function client by operating a node of the DM tree. Corresponding to
A partial structure of the DM tree is as shown in
<./x/Operations/Suspend>
This node is adapted to indicate the operation of suspending a function or a process. For example, 0 indicates the initial state or the completion of a suspend operation, and 1 indicates that the function or process needs to be suspended.
<./x/Operations/Resume>
This node is adapted to indicate the restart of a function, i.e., a resume operation. For example, 0 indicates the initial state or the completion of a resume operation, and 1 indicates that the function needs to be resumed.
Additionally, if the source information of the operation command needs to be stored, the information may be stored in the <Ext> extension node or in the attribute of the node.
The structure of the DM tree is not limited to the structure as described above. For example, as shown in
In another example, the structure of the DM tree is as shown in
In the above embodiments, similar to the start and stop node, the Suspend and Resume nodes may also be defined in the SCoMO, which will not be described again here. Additionally, the Suspend and Resume nodes may also have other names.
Additional advantages and modifications will readily occur to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details and representative embodiments shown and described herein. Accordingly, various modifications and variations may be made without departing from the spirit or scope of the invention as defined by the appended claims and their equivalents.
| Number | Date | Country | Kind |
|---|---|---|---|
| 200610023603.9 | Jan 2006 | CN | national |
| 200610074245.4 | Apr 2006 | CN | national |
This application is a continuation of PCT application No. PCT/CN2007/000063 filed Jan. 8, 2007, which claims the priorities of CN Application No. 200610023603.9 filed on Jan. 24, 2006, titled “METHOD FOR MANAGING A COMMUNICATION TERMINAL DEVICE, AND A COMMUNICATION TERMINAL”, and CN Application No. 200610074245.4 filed on Apr. 4, 2006, titled “METHOD FOR MANAGING A COMMUNICATION TERMINAL DEVICE, AND A COMMUNICATION TERMINAL”, all of which are incorporated herein by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2007/000063 | Jan 2007 | US |
| Child | 12178820 | US |
