CN103312766B

CN103312766B - A kind of method, system and device supporting applications client forever online

Info

Publication number: CN103312766B
Application number: CN201310072940.7A
Authority: CN
Inventors: 仲其涛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2011-11-15
Filing date: 2011-11-15
Publication date: 2016-06-29
Anticipated expiration: 2031-11-15
Also published as: CN103312766A

Abstract

A kind of method supporting applications client forever online, the method includes: permanent set up a long-chain between engine AOE (101) and the permanent online service gateway A OG (20) being positioned at network side what be arranged in terminal (10) online and connects, wherein, at least two applications client is connect by described long-chain and communicates with one or more application server (04,05) respectively；In setting up the process that described long-chain connects, the subscriber management server (30) being positioned at network side provides routing iinformation to described AOE (101), provides authentication information to described AOG (20).

Description

Method, system and device for supporting permanent online of application client

Technical Field

The present invention relates to the field of communications, and in particular, to a method, system, and apparatus for supporting permanent online of an application client.

Background

The intelligent terminal is provided with a large number of permanent online applications, the permanent online applications are periodically linked with the server actively in a PULL mode actively initiated by the terminal to update the state, so that a large number of repeated and short PULL messages can be generated, and the permanent online applications such as instant messages IM, social networks SNS, VOIP and the like need the client to frequently send a 'keepalive' message to inform the online state of the service; for another example, IM and SNS applications require a client to frequently update a buddy state with a server Pull message; PushMail requires periodic synchronization and refreshing; iAD advertisement push of iphone4, location tracking service all need to consume a large amount of communication resources, and the like.

In order to maintain an application permanently online, one or more application servers need to maintain at least one permanent link with the user terminal. The link between the terminal and one or more application servers is unstable, for example, there are NAT and firewall in the middle of the link, and the IP address of the user may change, so it is necessary to maintain the link through frequent heartbeat and acquire the user status (presence information).

In general, when a terminal performs normal data communication, a network allocates a dedicated physical channel to the terminal for uplink and downlink wireless transmission of data, and this state is referred to as a DCH (dedicated channel) state. When there is no data transmission, the terminal can process the Idle state, all links are closed in the access layer in the Idle state, and the terminal only monitors the paging information. Thus, the consumption of power by the terminal in the DCH and Idle states is very different. The intelligent terminal is based on the consideration of power saving, no data transmission is generally carried out for 6-8 seconds, and the mobile phone is forced to be switched to an Idle state in a fast dormancy mode. And "permanent online" applications often require a heartbeat connection with the server. Therefore, the terminal is frequently switched between the Idle state and the DCH state, 32 signaling is needed to recover the link when the wireless side is switched from the Idle state to the DCH active state, and the frequent switching between the states causes a significant impact on the signaling of the wireless side.

Disclosure of Invention

One embodiment of the invention provides a method for supporting application client permanent online, which establishes a long link between an AOE (101) located in a terminal (10) and an AOG (20) located on a network side, wherein at least two application clients respectively communicate with one or more application servers (04, 05) through the long link; a user management server (30) positioned on the network side provides routing information to the AOE (101), wherein the AOE (101) requests to establish the long link according to the routing information; the user management server (30) is further configured to provide authentication information to the AOG (20) during the establishment of the long link.

Preferably, the user management server (30) acquires and stores a correspondence between the terminal identity information and the user identity information, and stores an address of the AOG (20) to which the user identity information belongs; when the AOE (101) sends a request carrying terminal identity information routing information, the user management server (30) provides the AOE (101) with the address of the AOG to which the user identity information belongs according to the corresponding relation between the terminal identity information and the user identity information and the address of the AOG (20) to which the user identity information belongs; when the AOG (20) sends an authentication information request, the user management server (30) provides the AOG (20) with the user identity information according to the terminal identity information in the authentication information request and the corresponding relation between the terminal identity information and the user identity information.

Preferably, the terminal identity information is IMSI information, and the user identity information is a mobile phone number.

Preferably, the process of providing the AOE (101) with the routing information and providing the AOG (20) with the authentication information by the user management server (30) on the network side specifically includes:

when the AOE (101) starts the AOE (101) or detects that the ISMI information in the SIM card is different from the information registered last time, the AOE automatically sends a report message to a user management server (30), wherein the report message carries the IMSI information and the mobile phone number; the user management server (30) acquires the IMSI information and the mobile phone number according to the received report message, and stores the corresponding relation between the mobile phone number and the IMSI information; the AOE (101) sends a routing information request to the user management server (30), wherein the routing information request carries the IMSI information; the user management server (30) searches a corresponding mobile phone number according to IMSI information in the received routing information request, and returns the address of the AOG (20) to which the mobile phone number belongs to the AOE (101) according to the pre-stored AOG address to which the mobile phone number belongs; the AOE (101) initiates a registration request to the AOG (20) to which the mobile phone number belongs, wherein the registration request carries IMSI information; after receiving the registration request of the AOE (101), the AOG (20) judges whether IMSI information contained in the AOG (20) is registered in the AOG, if not, an authentication information request is sent to a user management server (30), and the authentication information request carries the IMSI information in the registration request; the user management server (30) returns the mobile phone number corresponding to the IMSI information according to the stored corresponding relation between the mobile phone number and the IMSI information after receiving the authentication information request; when the AOG (20) judges that the mobile phone number belongs to the service range of the AOG (20), the AOG (20) stores the mobile phone number and returns a registration response to the AOE (101).

Preferably, the report message is a short message, and the report message carrying the IMSI information and the mobile phone number specifically includes: the content of the short message comprises the IMSI information, and the sender of the short message is the mobile phone number.

Preferably, the terminal identity information is a terminal device identifier, and the user identity information is a user name or a user identifier.

In another embodiment of the present invention, a system for supporting permanent online of an application client is provided, which includes: the permanent online engine AOE (101) is positioned in the terminal (10) and is in communication connection with at least two application clients; the permanent online service gateway AOG (20) is positioned on the network side and is in communication connection with one or more application servers (04, 05) positioned on the network side; the always-on engine AOE (101) and the always-on service gateway AOG (20) for establishing a long link, wherein the at least two application clients communicate with the one or more application servers (04, 05) via the long link, respectively; and the user management server (30) is positioned on the network side, is in communication connection with the AOE (101) and the AOG (20), and is used for providing routing information to the AOE (101), so that the AOE (101) can establish the long link according to the routing information request, and further provides authentication information to the AOG (20) in the process of establishing the long link between the AOE (101) and the AOG (20).

Preferably, the user management server (30) is specifically configured to: the corresponding relation between the terminal identity information and the user identity information is obtained and stored, and the address of the AOG (20) to which the user identity information belongs is stored; when the AOE (101) sends a request carrying terminal identity information routing information, according to the corresponding relation between the terminal identity information and the user identity information and the address of the AOG (20) to which the user identity information belongs, the AOE (101) is provided with the address of the AOG to which the user identity information belongs; when the AOG (20) sends an authentication information request, the AOG (20) is provided with the user identity information according to the terminal identity information in the authentication information request and the corresponding relation between the terminal identity information and the user identity information.

Preferably, the terminal identity information is IMSI information, and the user identity information is a mobile phone number; the AOE (101) is specifically for: when the AOE (101) is started or the fact that the ISMI information in the SIM card is different from the information registered last time is detected, a report message is automatically sent to a user management server (30), and the report message carries the IMSI information and the mobile phone number; sending a routing information request to the user management server (30), wherein the routing information request carries the IMSI information; and initiating a registration request to the received AOG (20) to which the mobile phone number belongs, wherein the registration request carries IMSI information. The user management server (30) is specifically configured to: acquiring the IMSI information and the mobile phone number according to the received report message, and storing the corresponding relation between the mobile phone number and the IMSI information; finding a corresponding mobile phone number according to IMSI information in the received routing information request, and returning the address of AOG (20) to which the mobile phone number belongs to the AOE (101) according to the pre-stored AOG address to which the mobile phone number belongs; and after receiving the authentication information request, returning the mobile phone number corresponding to the IMSI information according to the stored corresponding relation between the mobile phone number and the IMSI information. The AOG (20) is particularly useful for: after receiving the registration request of the AOE (101), judging whether IMSI information contained in the AOE is registered in the AOG (20), if not, sending an authentication information request to a user management server (30), wherein the authentication information request carries the IMSI information in the registration request, and receiving the mobile phone number corresponding to the returned IMSI information; when the mobile phone number is judged to belong to the service range of the AOG (20), the AOG (20) stores the mobile phone number and returns a registration response to the AOE (101).

In other embodiments, there are provided an always-on engine AOE (101), an always-on service gateway AOG (20), and a subscriber management server (30) that are capable of performing the steps associated with the aforementioned methods.

In another embodiment of the present invention, in a system for supporting application client permanent presence, a permanent presence engine AOE (101), located in a terminal (10), is in communication connection with at least two application clients for establishing a long link with a permanent presence service gateway AOG (20); a permanent online service gateway AOG (20) located at the network side and used for establishing the long link with the permanent online engine AOE (101) and initiating heartbeat messages so as to maintain the long link; wherein the at least two application clients communicate with the one or more application servers (04, 05) over the long link.

Preferably, AOE (101) and AOG (20) may each actively disconnect the long link according to their own judgment.

Preferably, the always-on engine AOE (101) is further configured to actively send a disconnection request to the AOG (20) when it is determined that no other heartbeat request has been received after the heartbeat request is received for more than a certain time threshold; or, when detecting that all application clients managed by the application clients do not run within a certain time threshold, actively initiating a disconnection request to the AOG (20); or, when detecting that the battery power of the terminal 01 is lower than a certain threshold value, actively sending a disconnection request to the AOG (20), wherein the disconnection request is used for disconnecting the long link.

Preferably, the AOG (20) is further configured to actively initiate a disconnection request when it is determined that no data stream sent from the AOE101 is received after a certain time threshold; and actively initiating a disconnection request when judging that the heartbeat request is sent beyond a certain threshold, but the response of the AOE101 is not obtained, wherein the disconnection request is used for disconnecting the long link.

Preferably, the AOG (20) is further configured to modify whether the AOE101 that has disconnected the long link is online or not recorded on the AOG (20) to be offline, and construct an offline notification message to be sent to the application server.

Preferably, AOG (20) is further configured to send a wake-up message to AOE (101) in special cases for waking up a long link that is not yet established or that has been disconnected.

Preferably, the AOE (101) is further configured to, after monitoring and intercepting the wake-up short message, parse the wake-up short message, and trigger establishment of the long link.

In another embodiment of the present invention, in a system for supporting application client permanent presence, a permanent presence engine AOE (101), located in a terminal (10), is in communication connection with at least two application clients for establishing a long link with a permanent presence service gateway AOG (20); wherein the at least two application clients communicate with one or more application servers 04 via the long link; the AOE (101) is further used for pulling up the withdrawn application client when the long link is normal (successfully established) and the application client in the terminal (10) is withdrawn, but the data forwarded by the AOG (20) and sent to the application client is received.

In another embodiment of the present invention, in a system for supporting application client permanent presence, a permanent presence engine AOE (101), located in a terminal (10), is in communication connection with at least two application clients for establishing a long link with a permanent presence service gateway AOG (20); wherein the at least two application clients communicate with one or more application servers 04 via the long link; the AOE (101) is further configured to provide a separate connection to interact with one of the application servers when the application client has a large amount of data to interact with the application server, the original long link may be used primarily to transport control flow related data.

Preferably, when the delivered data reaches the threshold value, a special IP proxy channel is required to be established, and the delivered data is specially transmitted by the channel, and generally, the data is a data stream generated in the process of providing the application.

Preferably, the IP proxy channel can be actively closed at the end of data transfer.

Preferably, for an application client or an application server not actively closing the IP proxy channel, the AOE (101) may set a timeout mechanism, and after no data interaction reaches a threshold (e.g. 60s), the AOE (101) actively disconnects.

In further embodiments of the present invention, there are provided corresponding methods performed by the above-described system, and corresponding AOE (101), terminal (10), and AOG (20).

Through the different embodiments, a system, a method and a device for saving communication resources and supporting the permanent online of an application client are provided from different sides.

Drawings

FIG. 1 is a schematic diagram of an environment in which an embodiment of the present invention is implemented;

FIG. 2a is a system architecture diagram of an embodiment comprising a user management server;

FIG. 2b is a flowchart of a method of an embodiment for establishing long links in a system including a customer care server;

FIG. 3a is a flowchart of a method of an embodiment of establishing a long link, such as in a carrier communication system;

FIG. 3b is a flow diagram of a method of an embodiment of a flow diagram for updating an application client;

FIG. 4a is a system architecture diagram of an embodiment for long link heartbeat maintenance;

FIG. 4b is a method flow diagram of an embodiment of a method for long link heartbeat maintenance;

FIG. 5a is a flowchart of a method of an embodiment for long link heartbeat maintenance, described from the AOE (101) perspective;

FIG. 5b is a flowchart of a method of an embodiment for long link heartbeat maintenance, described from the AOG (20) perspective;

FIG. 6 is a system architecture diagram from an embodiment incorporating extended functionality;

FIG. 7 is a flow diagram of a method of an embodiment for waking up a long link;

FIG. 8 is a flow diagram of a method of an embodiment for waking up an application client;

FIG. 9 is a schematic diagram of a terminal according to an embodiment;

FIG. 10 is a schematic diagram of the structure of one embodiment of AOG (20);

fig. 11 is a schematic configuration diagram of an embodiment of the user management server (30) in the system.

Detailed Description

For the purposes of clarity of the various embodiments of the invention, the terms that may be used are to be construed as follows:

AOG: the AOG (always Online gateway), the always online gateway, through cooperating with the always online engine, can provide the SP with the general PUSH channel, allow SP service side to find the terminal at any time and any place.

AOE (101): AOE (101) (always online engine), a persistent online engine, is middleware deployed on the terminal side that aggregates and proxies the always-on requirements of client application clients.

AOI: aoi (always online infrastructure), an always-on facility, comprising AOE (101), AOG, or further comprising a set of network elements such as a user management server.

Fig. 1 is a schematic diagram of an environment system for implementing an embodiment of the present invention, which includes a plurality of communication devices communicating with each other through a wired or wireless communication network. These communication networks include, but are not limited to, a mobile communication network (mobile telephone network), a wireless local area network (lan), a bluetooth network (bluetooth), an ethernet network (ethernet), a token ring local area network (token ring lan), a wide area network (awidearetwork), the internet (the internet), and the like.

In the system shown in fig. 1, the terminal (10) may include, but is not limited to, a mobile device (mobile device), a portable communication PDA device (integrated PDA), an integrated messaging device (imd)), a personal computer (personal computer) which may be mobile or located on a mobile device such as, but not limited to, a car, truck, taxi, bus, boat, plane, bicycle, motorcycle, etc. the terminal (10) may access one or more application servers 04 via the wireless network and/or the wired network in order to obtain applications provided by the one or more application servers 04.

The communication device may implement communication procedures based on various transmission technologies, including but not limited to code division multiple access (cdma), global system for mobile communications (gsm), universal mobile telecommunications system (umts), time division multiple access (tdma), frequency division multiple access (fdma), transmission control protocol/internet protocol (TCP/IP), short message service (short messaging service), multimedia messaging service (mms), e-mail, instant messaging service (instant messaging service), Bluetooth (ims), IEEE802.11, and so on.

Fig. 2a is a schematic diagram of an architecture of an embodiment of a system for supporting permanent online of an application client, where the system includes:

an AOE (101), located in the terminal (10), and linked with at least two application clients in communication;

a permanent online service gateway AOG (20) located on the network side and communicatively linked to one or more application servers (04, 05) located on the network side;

-said always-on engine AOE (101) and said always-on service gateway AOG (20) for establishing a long link, wherein said at least two application clients communicate with said one or more application servers (04, 05) via said long link, respectively;

a user management server (30) located on the network side, communicatively linked with the AOE (101) and the AOG (20), and providing routing information to the AOE (101), wherein the AOE (101) requests to establish the long link according to the routing information; the user management server (30) is further configured to provide authentication information to the AOG (20) during the establishment of the long link.

The one or more application servers mentioned above may include, but are not limited to, servers that provide one or any combination of the following applications: PUSHMail, weather forecast, VOIP, advertising, location services, business office, lifestyle services, and the like.

The long link mentioned above may be a long link conforming to a Transmission Control Protocol (TCP), or may be a long link conforming to a User Datagram Protocol (UDP);

the user management server (30) can be used as a management node of permanent online service user data, and provides routing information to the AOE (101), so that the AOE (101) can request to establish the long link according to the routing information; and providing authentication information to said AOG (20) during establishment of a long link between said AOE (101) and said AOG (20). The above scheme may enable the always-on engine AOE (101) and the always-on service gateway AOG (20) to establish the long link easily and securely. It should be noted that, the inside of the user management server (30) may be clustered or distributed; can be co-located with any possible device on the network side or can be located independently, but can be distinguished from other devices for the AOG, and there may be more AOGs in the above-mentioned system.

In a preferred embodiment, the authentication information is user identity information, such as a mobile phone number, a user identifier or a user name, which facilitates various application servers to authenticate their users, and in a specific embodiment, the AOG (20) may proxy the authentication process. However, generally, the terminal (01) carries terminal identity information, such as IMSI information, or device identification, which, if used as authentication information, needs to perform complex authentication interaction with one or more devices such as an application server in advance. It should be noted that, the above-mentioned routing information is the address of the AOG (20) to which the user identity information belongs, and in a specific embodiment, for the entire network, there may be multiple AOGs (20), and an AOG that explicitly provides a proxy service for a certain user identity information is required.

Referring to fig. 2b, which is a flow chart of a preferred embodiment, the system of fig. 2 performs the following method:

201. a user management server (30) (such as a registration management module (3011)) acquires and stores a corresponding relation between terminal identity information and user identity information, and stores an address of an AOG (20) to which the user identity information belongs;

202. when AOE (101) (such as a link management module (1011)) sends a routing information request, a user management server (30) (such as a routing information module (3012)) provides the AOE (101) with the address of the AOG to which the user identity information belongs according to the terminal identity information in the routing information request and the corresponding relation between the terminal identity information and the user identity information;

203. when the AOG (20) sends an authentication information request, a user management server (30) (such as an authentication information module (3013)) provides user identity information to the AOG (20) according to the terminal identity information in the authentication information request and the corresponding relation between the terminal identity information and the user identity information.

Specifically, the process of acquiring and storing the corresponding relationship between the terminal identity information and the user identity information may be implemented by using other possible communication channels, such as a circuit domain communication channel or a short message channel, before the long link is not established. Specifically, the method may include, but is not limited to, reporting to the user management server (30) by the terminal (10), or forwarding to the user management server (30) by another network device, or obtaining by the user management server (30) in a manner of requesting from the terminal (10) or another network device.

Referring to fig. 3a, preferably, taking a communication system provided by an operator as an example, and specifically taking terminal identity information as IMSI information and user identity information as a mobile phone number as an example, in the process of establishing a long link, a user management server (30) located on a network side provides routing information to an AOE (101), and a process of providing authentication information to an AOG (20) specifically includes:

301, the AOE (101) (e.g. a link management module (1011) on the AOE (101)) automatically sends a report message to a subscriber management server (30) when the online persistent engine AOE (101) starts or detects that the ISMI information in the SIM card is different from the last registered information, where the report message carries the IMSI information and the mobile phone number.

The report message is information that can be sent without establishing the link between the AOE (101) and the AOG (20), for example, information of a circuit domain or information of a non-data link. More specifically, the notification may be a short message, or an online Radius notification forwarded by the AAA server, or the like. If the short message is the short message, the system sets the default of the sender as the mobile phone number only by carrying the IMSI information in the content, thereby further saving the data communication resource.

302, the subscriber management server (30) (such as the aforementioned registration management module (3011)) acquires the IMSI information and the mobile phone number according to the received report message, and stores the corresponding relationship between the mobile phone number and the IMSI information.

303, optionally, since the report message may be delayed, in order to ensure that the user management server (30) performs the subsequent processing procedure after receiving the report message, the AOE (101) may perform a certain delay.

304, AOE (101) (e.g. link management module (1011)) sends a routing information request to the subscriber management server (30), the routing information request carrying the IMSI information.

305, a user management server (30) (such as a routing information module (3012)) searches for a corresponding mobile phone number (specifically, the registration management module (3011)) according to IMSI information in a received routing information request, and returns an address of an AOG (20) to which the mobile phone number belongs to the AOE (101) according to a pre-stored AOG address to which the mobile phone number belongs.

And 306, after obtaining the attributive AOG information, the AOE (101) (such as a link management module (1011)) initiates a registration request to the attributive AOG (20), wherein the registration request carries IMSI information.

Preferably, the registration request may also carry, but is not limited to: information of the application clients already registered in AOE (101), such as the identity of the application, the model number of the terminal, the access network APN, the operating system version, and the version of AOE (101), etc.

307, after receiving the registration request, the AOG (20) determines whether the IMSI information included therein is already registered in the AOG (20) after receiving the registration request of the AOE (101).

308. If not, the AOG (20) sends an authentication information request to a user management server (30), wherein the authentication information request carries IMSI information in the registration request.

309, after receiving the authentication information request (specifically, for example, the terminal information module 301), the user management server (30) returns the terminal information mobile phone number corresponding to the IMSI information to the AOG (20).

At 310, AOG (20) (e.g. link management module (2011)) determines whether the mobile phone number is the service scope of AOG (20), and if not, the registration is returned to fail, and the process ends. The AOG (20) (e.g. link management module (2011) therein) stores the cell phone number if it belongs to the service scope of the AOG (20). Preferably, other information carried in the aforementioned registration information, such as the terminal model, the registered application client, and the like, may also be stored.

At 311, after successful registration at 310, AOG (20) (e.g., link management module (2011) therein) returns a registration response to AOE (101) (e.g., link management module (1011)).

To this end, AOE (101) successfully establishes the aforementioned long link with the home AOG (20). The process utilizes the trusted terminal information and the user information in the system to establish the long link, does not need the system to generate a unique equipment ID for each terminal (10) through complex interaction, and utilizes the unique equipment ID to establish the long link, thereby simplifying the process and improving the safety of the long link.

Fig. 3a illustrates a process of establishing a connection when the terminal (10) is started or detects that the ISMI information in the SIM card is different from the last registered information (i.e. the SIM card in the terminal is replaced, which can be understood as a new terminal (10)), specifically, the process includes registering the terminal information on the AOG (20) and registering the application information on the AOG (20). In other cases, it may happen that after the terminal (10) registers with the AOG (20), some applications are additionally installed or deleted, and a similar method is required for updating the application information. Referring to fig. 3b, a schematic flow chart of updating the application is shown, in which the AOG (20) is a system composed of the AOG of the home of the terminal (10) and the AOG of the access place of the application server. In a specific example, the process includes:

301b, installing (or uninstalling) an application client supporting interaction with AOE (101) to realize AOI function on the terminal;

302b, after the application client is installed (or uninstalled), calling an application registration interface of the SDK for registration (uninstalling is regarded as calling an application logout interface of the SDK for logout);

303b, the AOE (101) calls a REG interface and sends an application adding request (an application deleting request when unloading) to the terminal attribution AOG;

304b, the terminal attribution AOG updates and stores the application information corresponding to the terminal;

305b, the terminal attribution AOG returns a registration response (un-logout response when uninstalling) to the AOE (101);

305b, the terminal attribution AOG constructs an INFO online notification message according to the application ID reported by the terminal, and sends the INFO online notification message to the application attribution AOG gateway, wherein the online notification message carries the mobile phone number. (offline notification messages when unloaded).

307b, the application server accesses the AOG of the place and converts the mobile phone number into a pseudo code.

308b, the application server accesses the AOG of the ground, and forwards the online notification message (the offline notification message when unloading) to the application server, wherein the message carries the pseudo code.

309b, the application server returns a notification response.

310b, the AOG of the access place of the application server forwards the notification response to the AOG gateway of the original notification initiator.

Specifically, when the terminal home AOG gateway and the application home AOG gateway are the same gateway, the forwarding process of the messages in the 306b and 310b steps between the gateways in the above flow is not required.

If the terminal attribution AOG gateway and the application attribution AOG gateway are not the same gateway and effective connection is not established between the two gateways, before forwarding the message, the terminal attribution AOG gateway actively completes the REG registration login process to the application attribution AOG gateway, and then message forwarding is carried out.

In order to simplify the processing flow of the REG message inside the AOG gateway, in the application installation flow, AOG02 may not distinguish what type of registration message (or logout message), after receiving the message, it still can confirm whether the IMSI digest exists in the AOG according to the first registration flow, if not, it inquires the mobile phone number on the user management server 03, and according to whether the mobile phone number belongs to the range of the AOG service, it confirms the content of the message returned to the AOE (101). In a simple application installation process, the IMSI must exist, the number must belong to the AOG, and the number cannot go to another branch.

Fig. 4a is a schematic diagram of an architecture of an embodiment of a system for supporting permanent online of an application client, where the system includes:

at least two application clients located in the terminal (10) and communicatively connected to said always-on engine AOE (101); (ii) a

A permanent presence engine AOE (101), located in the terminal (10), in communication connection with at least two application clients, for establishing a long link with the permanent presence service gateway AOG (20);

a permanent online service gateway AOG (20) located at the network side for establishing the long link with the permanent online engine AOE (101);

one or more application servers (04, 05) located on the network side and communicatively connected to the AOG (20);

wherein the at least two application clients communicate with the one or more application servers 04 through the long link to respectively implement the application services provided by the one or more servers (04, 05); in the system, the maintenance of the long link is taken care of by the AOG (20) on the service side, that is, between the terminal (10) and the AOG (20), a heartbeat message is initiated by the AOG (20) in order to maintain the long link. The application client is used for providing application services to users, and the application server 04 is used for providing various application services, such as one or any combination of the following applications: PUSHMail, weather forecast, VOIP, advertising, location services, business office, lifestyle services, and the like.

As shown in fig. 4a, with this way of maintaining long links, compared to the way of initiating heartbeats by the terminal side, on one hand, the terminal (including each application client therein) does not need to send a large number of heartbeat messages to one or more application servers, thereby reducing signaling pressure on the terminal side, and on the other hand, AOE (101) in the terminal does not need to perform special processing such as filtering/discarding on the heartbeats, thereby reducing signaling consumption sent outside by the terminal and further reducing signaling consumption inside the terminal (10); in addition, when the AOG (20) initiates heartbeat, the heartbeat interval can be adjusted according to the network condition, and the heartbeat parameter is automatically controlled, so that the heartbeat is most consistent with the network condition, the process of actively detecting the network parameter by a terminal side is avoided, and the waste of communication resources is further reduced.

Referring to fig. 4b, in a preferred embodiment, AOE (101) and AOG (20) may each actively disconnect the long link according to their own judgment, so as to further save communication resources of the network, the terminal, the server, etc., and certainly save power consumption of each device, especially the terminal (10). When needed, the AOG (20) can actively wake up the connection with the terminal side again.

Referring to fig. 5a, a schematic diagram of an embodiment of heartbeat maintenance on long links from the AOE (101) perspective. Referring to fig. 5a, after establishing a long link, AOE (101) is a schematic diagram of a preferred method of maintaining a long link, comprising:

optionally, AOE (101) (e.g. link management module (1011)) receives a disconnection request (e.g. BYE) actively sent by AOG (20), and disconnects the long link.

Optionally, after receiving the heartbeat message, AOE (101) (e.g. heartbeat time module (1012)) refreshes the timer, and if the timer does not receive other heartbeat messages when exceeding a certain time threshold, sends a disconnection request (e.g. BYE) to AOG (20) to close the long link. For example, the time threshold is set to 5 minutes, 10 minutes, or 30 minutes, etc.

Optionally, AOE (101) (e.g. application management module (1012) therein) detects that all application clients managed by AOE are not running within a certain time threshold, and actively initiates a disconnection request (e.g. BYE request), so as to disconnect the long link. For example, the time threshold is set to 5 minutes, 10 minutes, or 30 minutes, etc.

Optionally, AOE (101) (e.g. battery monitoring module (1014) therein) monitors the battery power of terminal (10), and when the battery power is less than a certain threshold (e.g. only 10% of battery power remains, or 5%), if a long link exists, actively sends a disconnection request, e.g. BYE), optionally, a tag may be added to the disconnection request, indicating that the long link is disconnected because of low battery.

Through the possible implementation manner, after the long-chain connection is disconnected, the AOE (101) enters a dormant state (can wait for the AOG (20) to be awakened through the short message), and the electric quantity of the terminal (10) can be saved. Various ways of actively initiating disconnection of the long link by the AOE (101) further reduce unnecessary signaling waste, for example, after disconnection, the AOG (20) on the network side does not need to send heartbeat messages again, and in addition, battery power on the terminal (10) is further saved.

It should be noted that, when a long link exists between AOE (101) and AOG (20), the operating system of the terminal (10) needs to be prohibited from entering a sleep state to ensure normal connection of the long link, and when the long link with AOG is disconnected, the sleep mechanism of the operating system can be resumed.

Referring to fig. 5b, it is illustrated from the AOG (20) perspective how the long link is maintained. It should be noted that, in the actual application process, the AOG (20) depicted in fig. 5b may be a single server, and may be divided into an AOG (20) to which the terminal (10) (specifically, the AOE (101)) belongs and an AOG (20) to which one or more application servers belong according to needs. Optionally, for the latter (case of two AOGs), a communication connection is performed between the AOG (20) to which the terminal (10) belongs and the AOG (20) to which one or more application servers belong, the AOG (20) to which the terminal (10) belongs is responsible for interacting with the AOE (101) in the terminal (10), and the AOG (20) to which one or more application servers belong is responsible for interacting with one or more application servers. More specifically, from the internal structure of AOG (20), 501 to 504 shown in fig. 5b may be performed by terminal management module (1021), and terminal management module (1021) may be located on AOG (20) to which terminal (10) belongs; steps 500, 505 and 508 may be performed by an application management module (1022), which application management module (1022) may be located on the AOG (20) to which the application server belongs.

Specifically, the embodiment shown in fig. 5b includes the following steps:

500-. The method comprises the steps that the AOE (101) and the AOG of the terminal attribution complete the REG registration process (501), and the REG registration process comprises information of the terminal and information of an application client on the terminal. Accordingly, one or more application servers also need to have successfully registered with AOG (20) (step 500), so that AOE (101) (i.e. terminal (10)) can subsequently be notified of the offline notification to the one or more application servers.

502, after the AOE (101) and the AOG (20) successfully establish the long link, the AOG (20) actively initiates an ACK heartbeat message to the terminal so as to maintain the long link. In a preferred embodiment, the time interval for sending the heartbeat message, that is, the heartbeat interval, the timeout time control, and the like, may be configured according to the condition of the network;

AOE (101) replies with an ACKRSP response indicating the active state AOE (101) is in.

AOG (20) maintains long links according to several conditions, including but not limited to:

5041 when AOG (20) receives the disconnection request actively sent by AOE (101), disconnecting the long link and no longer sending heartbeat message; in particular, reference may be made to the flow shown in fig. 5 a.

5042, when AOG (20) determines that the data stream transmitted from the terminal (10) (AOE (101)) is not received for more than a certain time threshold, it actively initiates a disconnection request (e.g. BYE) and no longer transmits the heartbeat message. In preferred embodiments, the time threshold may be configurable, for example, to default to 5 minutes, 10 minutes, or 30 minutes.

5043, when the AOG (20) determines that after sending the heartbeat message ACT, if the response of the AOE (101) is not obtained, the response exceeds a certain threshold, actively initiating a disconnection request (for example, BYE), and no longer sending the heartbeat message. In preferred embodiments, the threshold number of times may be configurable, for example, default to 3 times, 4 times, or 5 times, etc.

5054, not shown in the figure, after 502, if the disconnection request sent by AOE (101) is not received and the disconnection request is not actively sent to AOE (101), according to the heartbeat time interval, a heartbeat message is regularly sent to AOE (101) so as to maintain the long link.

In a preferred embodiment, based on the foregoing maintenance for long links, AOG (20) (e.g., application management module (2012)) may further manage the online status of AOE (101) and the application client on AOE (101). For example, optionally 505, if AOG (20) disconnects the long link according to the conditions of steps 5041, 5042, 5043, etc., it is determined that AOE (101) is offline, and the online status of locally stored AOE (101) is updated to be: off-line.

Optionally, 506, AOG (20) queries registered permanently online application client information on AOE (101), and if interaction with one or more application servers is required using pseudo code, AOG (20) (e.g., application management module (2012)) converts the cell phone number of AOE (101) stored on AOG (20) into pseudo code for communication between AOG (20) and application servers as user identity information. Here, the pseudo code is a unique identification of a user for an application within the system.

Specifically, in order to protect the privacy of the user, some applications cannot disclose the mobile phone number to the application Server (SP), and other identifiers are required to replace the mobile phone number. It is common practice to digest the information, such as the phone number and other random numbers, and the computed digest is referred to as the pseudo-code. The mobile phone number and the pseudo code are in one-to-one correspondence, and the mapping relation can be reserved at the server side. The algorithm is one-way, i.e. the associated random parameter is not sent to the application Server (SP), and the application Server (SP) cannot deduce the mobile number back by means of pseudo-code. When one or more application Servers (SP) send downlink messages, the users can be identified through pseudo codes, and the corresponding mobile phone numbers can be inquired by the pseudo codes on the server side, so that the messages can be routed to the correct users.

More specifically, the pseudo-code is application-level and may specify that some applications enable pseudo-code functionality and some applications disable pseudo-code functionality. If the application management module (2012) specifies that the pseudo code needs to be transmitted in the control attribute of the application, the pseudo code needs to be generated for the mobile phone number interacting with the application, and the corresponding relation between the mobile phone number of the user and the pseudo code is maintained. In one example, the method of generating the pseudo code is as follows: a pseudo code ═ HASH (MSISDN, Time, APPID, Random) where: HASH is a HASH algorithm, for example, using MD5 algorithm; MSISDN is the mobile phone number of the user; time: a timestamp, for example in YYYYMMDDHH24MISS format; APPID is an application identifier; random is a Random number. For a specified mobile phone number and a certain application, the pseudo code is generated in the system only once, and is effective all the time. Specifically, when the mobile phone number needs to be converted into the pseudo code, the system firstly carries out combined query on a local database according to the mobile phone number and the application ID, if the pseudo code cannot be found, the application is proved to be used for the first time, and then the pseudo code is generated by using the algorithm. When the conversion from the pseudo code to the mobile phone number is required, the AOG (20) queries a local database, and if the query fails, the application-specified pseudo code is proved to be wrong. And when the inquiry is successful, matching the APPID in the application message with the APPID of the local pseudo code database, and if the matching is successful, considering that the pseudo code verification is successful.

Optionally, 507 the AOG (20) constructs an offline notification message to the one or more application servers, where the offline notification message includes the pseudo code.

Accordingly, 508, one or more application servers may return a notification response upon receiving the offline notification message.

Specifically, if the AOG (20) is a server, the AOG (20) itself performs the above steps 506, 507; if the AOG (20) is a system consisting of the AOG (20) to which the AOE (101) belongs and the AOG (20) to which one or more application servers belong, the AOG (20) to which the AOE (101) belongs sends an offline notification message containing the mobile phone number to the AOG (20) to which the one or more application servers belong, the AOG (20) to which the one or more application servers belong converts the mobile phone number into a pseudo code, and the offline notification message containing the pseudo code is sent to the one or more application servers.

Based on the above various possible embodiments, after the long link is disconnected, the AOE (101) may wait for the AOG (20) to wake up through the short message, and reestablish the long link. Specifically, the system can be implemented by the system shown in fig. 6, for example, "short message pushing module (2015)" in AOG (20), "short message processing module (1013)" in AOE (101), "application waking module (1015)", and so on.

Specifically, fig. 7 is a schematic flow chart of an embodiment of waking up a long link when the long link is disconnected. The method comprises the following steps:

701, a short message pushing module (2015) in the AOG (20) sends a 'wake-up short message' to the AOE (101) under special conditions, and the 'wake-up short message' is used for waking up a long link which is not established or is disconnected.

Specifically, the wake-up message is not a normal text message, but a binary message with a special format, and is agreed between AOG (20) and AOE (101), and it can be understood that other network devices are invisible. The binary short message for waking up the long link may include an application ID to be woken up, a downlink message sender identifier, a destination user identifier, a summary of the message, and the like.

702, after a short message processing module (1013) in the AOE (101) monitors and intercepts a 'wake-up short message', analyzing the 'wake-up short message' to trigger a link management module (1011) in the AOE (101) to establish a long link; specifically, the monitoring is to monitor that the wake-up short message exists, and the interception means that the wake-up short message is not transmitted downwards any more, and other applications do not receive the contents of the wake-up short message any more.

703-.

In another preferred embodiment, referring to fig. 8, a flowchart of an embodiment of a method for waking up an application client is shown, when a long link has been established or has been woken up, but an application client in a terminal (10) has exited, but receives data sent to the application client and forwarded by AOG (20) (801), the application wake-up module (1015) in AOE (101) may also pull up the exited application client (802).

Specifically, the application client and the AOE (101) are two independent processes on the terminal (10), and when the application is started, the application needs to register with the AOE (101) to inform the AOE (101) of information such as program installation position and operation parameters, so that the AOE (101) can monitor the operation state of the application client on the terminal. When the application client quits (may quit actively according to the instruction of the user) and a downlink message needs to be notified to the application client, the AOE (101) re-runs the program of the client according to the previous registration information, thereby pulling up the application client, and then notifies the application client of the received downlink message through an internal API interface or message interface.

In other embodiments, different further embodiments may be provided, which may be combined with any of the above embodiments, and referring to fig. 6, optionally, AOE (101), AOG (20), and user management server (30) contain a plurality of possible modules, and the modules may be combined arbitrarily unless there is a logical exclusion between them, so as to form a more preferable embodiment. Each device, and each module in the device, will be described one by one.

Fig. 9 is a schematic structural diagram of an embodiment of the terminal (10) in the system. The terminal (10) generally includes at least one processor (102) (e.g., CPU), at least one network interface (105) or other communication interface, memory (106), and at least one communication bus (103) for enabling communications among the devices. A processor (102) for executing an executable module, such as a computer program, stored in a memory; the terminal (10) optionally includes a user interface (104) including, but not limited to, a display, a keyboard, and a pointing device (e.g., a mouse, trackball, touch pad, or touch sensitive display screen. the memory (106) may include high-speed Ram memory and may also include non-volatile memory (e.g., at least one disk memory.) the communication connection between the terminal (10) and at least one other computer may be via at least one network interface (wired or wireless) and may use the internet, a wide area network, a local network, a metropolitan area network, etc.

The memory (106) may optionally include at least one memory device (e.g., an external memory device) located remotely from the aforementioned CPU 801. In some embodiments, the memory (106) stores elements, executable modules or data structures, or a subset thereof, or an expanded set thereof as follows:

an operating system (106) for containing various programs for implementing various underlying services and for handling hardware-based tasks;

at least two application clients (108) for the persistent presence engine AOE (101) communication connection for respectively providing application services to users;

an AOE (101) connected to at least two application clients (108) in the terminal (10), connected to AOG (20) on the network side, and connected to one or more application servers (04) on the network side through said AOG (20);

the online persistent engine AOE (101) includes, but is not limited to, one or a combination of the following modules:

the system comprises a link management module (1011), an application management module (1012), a short message processing module (1013), a data forwarding module (1014), an application awakening module (1015), an IP proxy module (1016), a heartbeat time module (1017), or a battery monitoring module (1018), an API (application programming interface) and the like.

In one embodiment, the link management module (1011) may be configured to establish a long link between the AOE (101) and the AOG (20), wherein the at least two application clients respectively communicate with one or more application servers (04, 05) through the long link; routing information is obtained from a subscriber management server (30) and the long link is requested to be established according to the routing information. Specifically, the process of acquiring the routing information includes: sending a routing information request containing terminal identity information to a user management server (30), and receiving an address of the AOG returned by the user management server (30) according to the stored corresponding relation between the terminal identity information and the user identity information and the address of the AOG to which the user identity information belongs. In one example, the terminal identity information is IMSI information, and the user identity information is a mobile phone number; in another example, the terminal identity information is a terminal device identifier, and the user identity information is a user name or a user identifier. In particular, the above process may refer to the embodiments shown in fig. 2b, 3a, 3 b.

Optionally, the online persistent engine AOE (101) provides an API interface, through which the application clients can communicate, such that each application client does not establish a long link directly with the application provider, but rather establishes a long link through the online persistent engine AOE (101).

Optionally, the AOE (101) includes an application management module (2013), and functions of managing the application clients registered on the always-on engine AOE (101) include, but are not limited to, registration and deregistration of programs and reporting of running and running-out states of programs

Optionally, the online persistent engine AOE (101), for example, further comprises a data forwarding module (1014), which can be configured to receive data from different application clients, and then send the data out through the aforementioned "long link"; meanwhile, data can be obtained from the long link, the message of which application client the message belongs to is judged according to the application ID in the data, and then the message is forwarded to the application client. Specifically, the upstream message sent by the application client is forwarded to the always-on service gateway 102 so as to be forwarded to one or more application servers; and receiving the downlink message sent by one or more application servers and forwarded by the permanent online service gateway AOG (20) to the application client.

In another preferred embodiment, when an application client has a large amount of data to interact with one or more application servers, the AOE (101), such as the IP proxy module (1016), may provide a separate connection to interact with one or more application servers. Preferably, when the transmitted data reaches the threshold value, an IP proxy channel needs to be established, and the IP proxy channel is used for specially transmitting the data. Preferably, the IP proxy channel can be closed actively when the data transmission is finished. Preferably, for an application client or one or more application servers not actively closing the IP proxy channel, the AOE (101) may set a timeout mechanism, and after no data interaction reaches a threshold (e.g. 60s), the AOE (101) actively disconnects.

Fig. 10 is a schematic structural diagram of an embodiment of an AOG (20). It should be noted that, as described above, two separate devices that are not in the same physical location may be provided as required, that is, AOG (20) to which terminal (10) belongs and AOG (20) to which application server belongs, and they communicate with each other to perform related functions, and their structures are similar, but application modules may include different modules according to their locations.

The AOG (20) is positioned at the network side and is in communication connection with an AOE (101) which is a permanent online engine positioned in the terminal (10), and the AOE (101) is in communication connection with at least two application clients positioned in the terminal (10); is connected with one or more application servers (04, 05) in communication with the network side.

The AOG (20) generally includes at least one processor (202) (e.g., CPU), at least one network interface or other communication interface (205), memory (206), and at least one communication bus (203) for enabling connectivity communications between the devices. The processor (202) is for executing an executable module, such as a computer program, stored in the memory. The AOG (20) optionally also includes a user interface (904) including, but not limited to, a display, a keyboard, and a pointing device (e.g., a mouse, trackball (trackball), touch-sensitive pad, or touch-sensitive display screen. the memory (906) may include high-speed Ram memory, and may also include non-volatile memory (e.g., at least one disk memory).

The memory (206) may optionally include at least one memory device (e.g., an external memory device) located remotely from the aforementioned CPU. In some embodiments, the memory (206) stores elements, executable modules or data structures, or a subset thereof, or an expanded set thereof as follows:

an operating system (207) for containing various programs for implementing various basic services and for processing hardware-based tasks; and, one or any combination of the following modules:

the system comprises a terminal management module (2011), an application management module (2012), a routing management module (2013), a cache management module (2014), a short message pushing module (2015), an IP pushing module (2016), a protocol conversion module (2017) or an upgrading management module (2018).

In a specific embodiment, the terminal management module (2011) is configured to establish a long link between the online persistent engine AOE (101) and the AOG (20), wherein at least two application clients communicate with the one or more application servers (04, 05) through the long link respectively; in the process of establishing the long link, authentication information is acquired from a user management server (103). Specifically, the terminal management module (2011) is configured to: and sending an authentication information request carrying terminal identity information to the user management server (30), and receiving the user identity information returned by the user management server (30) according to the corresponding relation between the terminal identity information and the user identity information. In one example, the terminal identity information is IMSI information, and the user identity information is a mobile phone number; in another example, the terminal identity information is a terminal device identifier, and the user identity information is a user name or a user identifier.

Referring to fig. 6, in a preferred embodiment, optionally, the terminal management module (2011) in the always-on service gateway AOG (20) may also be configured to implement management of the terminal (10), for example, to manage information of the AOE (101) registered in the system, such as an IMSI digest, User Agent (UA) information of the AOE (101), and the like, and further include application information registered on the AOE (101), such as an identifier of an application currently installed on the AOE (101) or a version thereof. Optionally, the terminal management module (2011) may further authenticate the identity of the AOE (101), register the registration information, and store the registration information in the system. Specific procedures can be referred to the embodiments shown in 2b, 3a, 3b, etc. Preferably, the terminal management module (2011) may further manage long links between the AOE (101) and the AOG, for example, sending a heartbeat message, and maintaining long link status information, for example, an established status, a disconnected status, and the like.

Optionally, the application management module (2012) in the always-on service gateway AOG (20) may manage applications, for example, manage all application information accessed to the AOG (20), including an application server (or application provider SP) to which the application belongs and information thereof, and provide functions of access authentication, usage right control, and the like for one or more accessed application servers. In a preferred embodiment, pseudo code management is performed for specific applications, and so on. The specific process can refer to the embodiments shown in fig. 5 b.

Optionally, the route management module (2013) in the always-on service gateway AOG (20) may implement route management: for the uplink and downlink messages, the AOG can be correctly routed to the corresponding network element.

Optionally, the cache management module (2014) in the online service gateway AOG (20) may implement cache management, specifically, according to application requirements, a data message issued to the AOE (101) by the application is cached when the issuance is unsuccessful. Specifically, the cached message should be retried, and a successful status report is returned to the application after the retry is successful.

Optionally, the short message pushing module (2015) in the AOG (20) may send a "wake-up short message" to the AOE (101) in a special case, for waking up a long link that is not yet established or has been disconnected; and sending the downlink message sent by the application server to the AOE (101) through the reestablished long chain. The specific process can refer to the embodiment shown in fig. 7.

Optionally, the IP push module (2016) in the AOG (20) may implement an IP data push function (IPPUSH), and specifically, when the long link is disconnected, compared with the technical scheme of waking up the long link with the short message, another scheme may be further adopted: that is, for downlink messages that the application server needs to send, an IP data channel is directly established, and the downlink messages are sent to the online persistent engine AOE (101) through the IP data channel and sent to the application client through the AOE (101). Preferably, when the amount of downlink message data to be sent by the application server is large (for example, larger than a set threshold value), an IP data channel is directly established to push downlink data; when the amount of the downlink message data that the application server needs to send is small (for example, less than or equal to a set threshold), the long link can be woken up by using a short message wake-up method, and then the downlink data is pushed through the long link.

Optionally, when an internal protocol is used between the always-on service gateway AOG (20) and the always-on engine AOE (101) and a public protocol is used between the AOG (20) and one or more application servers, the protocol conversion module (2017) in the always-on service gateway AOG (20) may convert messages between the two protocols.

Optionally, an upgrade management module (2018) in the AOG (20) may manage versions of all persistent online engines AOE (101), and may trigger an automatic upgrade update of the persistent online engines.

Fig. 11 is a schematic configuration diagram of an embodiment of the user management server (30) in the system. As mentioned above, the user management server (30), located on the network side, is communicatively connected to the persistent online engine AOE (101) and the persistent online service gateway AOG (20), and at least two application clients communicate with the one or more application servers (04, 05) via the long links, respectively. The user management server (30) generally includes at least one processor (302) (e.g., CPU), at least one network interface or other communication interface (305), memory (306), and at least one communication bus (303) for enabling connected communication between these devices. The processor (302) is for executing an executable module, such as a computer program, stored in the memory. The user management server (30) optionally includes a user interface (304) including, but not limited to, a display, a keyboard, and a pointing device (e.g., a mouse, trackball, touch pad, or touch sensitive display screen. the memory (306) may include high speed Ram memory, and may also include non-volatile memory (e.g., at least one disk memory).

The memory (306) may optionally include at least one memory device (e.g., an external memory device) located remotely from the aforementioned CPU. In some embodiments, the memory (306) stores elements, executable modules or data structures, or a subset thereof, or an expanded set thereof as follows:

an operating system (307) for containing various programs for implementing various basic services and for handling hardware-based tasks; and, one or any combination of the following modules:

a routing information module (3012) and an authentication information module (3013).

Specifically, the routing information module (3012) is configured to provide routing information to the AOE (101) so as to establish the long link according to the routing information request; an authentication information module (3013) configured to provide authentication information to the AOG (20) during establishment of a long link between the AOE (101) and the AOG (20).

Preferably, the terminal may further include a registration management module (3011) configured to obtain and store a correspondence between the terminal identity information and the user identity information, and store an address of an AOG (20) to which the user identity information belongs; the routing information module (3012) is specifically configured to: providing the AOE (101) with the address of the AOG to which the user identity information belongs according to the terminal identity information in the routing information request sent by the AOE (101) and the corresponding relationship between the terminal identity information and the user identity information, which is acquired and stored by the registration management module; the authentication information module (3013) is specifically configured to: when the AOG (20) sends an authentication information request, the AOG (20) is provided with the user identity information according to the terminal identity information in the authentication information request and the corresponding relation between the terminal identity information and the user identity information acquired and stored by the registration management module. In one example, the terminal identity information is IMSI information, and the user identity information is a mobile phone number; in another example, the terminal identity information is a terminal device identifier, and the user identity information is a user name or a user identifier.

It should be noted that, in the above embodiments, especially different modules are mentioned, and if it is not stated that they cannot be implemented cooperatively, any combination may be performed to achieve further beneficial effects, and the present invention is not limited by form. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.

The above-described embodiments do not limit the scope of the present invention. Any modification, equivalent replacement, and improvement made within the spirit and principle of the above-described embodiments should be included in the protection scope of the technical solution.

Claims

1. A system for supporting an application client to stay online, comprising: an always-on line engine AOE (101), located in the terminal (10), in communication connection with at least two application clients on said terminal (10), for establishing a long link with the always-on line service gateway AOG (20);

a permanent online service gateway AOG (20) located at the network side and used for establishing the long link with the permanent online engine AOE (101) and initiating heartbeat messages so as to maintain the long link; wherein the at least two application clients communicate with one or more application servers (04, 05) via the AOG (20) over the long link.

2. The system according to claim 1, said AOG (20) further adapted to automatically control heartbeat parameters by adjusting heartbeat intervals based on network conditions.

3. The system of claim 1, wherein the first and second sensors are disposed in a common housing,

the AOE (101) is further used for actively disconnecting the long link according to the judgment of the AOE; or,

said AOG (20) is further arranged to actively break the long link according to its own judgement.

4. A system according to claim 3, said AOE (101) further being adapted to enter a dormant state after said long link is broken.

5. The system of claim 4, the AOG (20) further to: and if the disconnection request sent by the AOE (101) is not received and is not actively sent to the AOE (101), regularly sending heartbeat messages to the AOE (101) according to a heartbeat time interval so as to maintain the long link.

6. The system of claim 3, wherein the first and second optical elements are selected from the group consisting of,

wherein actively disconnecting the long chain junction by the AOE (101) according to the judgment of the AOE comprises:

the system is used for actively sending a disconnection request to the AOG (20) when judging that other heartbeat requests are not received when a certain time threshold value is exceeded after the heartbeat request is received; or, when detecting that all application clients managed by the application clients do not run within a certain time threshold, actively initiating a disconnection request to the AOG (20); or, when detecting that the battery power on the terminal (10) is lower than a certain threshold, actively sending a disconnection request to the AOG (20); the disconnection request is used for disconnecting the long link;

wherein actively disconnecting the long link connection by the AOG (20) according to the judgment thereof comprises:

when judging that the data stream sent from the AOE (101) is not received after a certain time threshold value, actively initiating a disconnection request; or actively initiating a disconnection request when judging that the number of times of sending the heartbeat request exceeds a certain threshold value but no response of the AOE (101) is obtained; the disconnect request is for disconnecting the long link.

7. The system according to any of claims 1-6, said AOG (20) further configured to modify to offline the presence status recorded on said AOG (20) by the AOE (101) that has broken said long link, and to construct an offline notification message to send to said application server.

8. The system of claim 7, wherein the first and second sensors are arranged in a single package,

the AOG (20) is further used for sending a wake-up short message to the AOE (101) for waking up a long link which is not established or disconnected;

and the AOE (101) is further used for monitoring and intercepting the awakening short message, analyzing the awakening short message and triggering to establish a long link.

9. A communication method for supporting permanent presence of application clients, establishing a long link between an AOE (101), which is a permanent presence engine, located in a terminal (10), and an AOG (20), which is a permanent presence service gateway, located on the network side, wherein at least two application clients located in the terminal (10) communicate with one or more application servers (04, 05) respectively via said AOG (20) through said long link; the method comprises the following steps: the always-on service gateway AOG (20) initiates heartbeat messages to facilitate maintenance of the long link.

10. The method of claim 9, further comprising:

and the AOG (20) adjusts the heartbeat interval according to the network condition and automatically controls the heartbeat parameters.

11. The method of claim 9, further comprising

The AOE (101) actively breaks the long chain connection according to the judgment of the AOE; or,

the AOG (20) actively breaks the long link at its discretion.

12. The method of claim 11, further comprising the AOE (101) entering a dormant state after the long link is broken.

13. The method according to claim 11, wherein said step of treating,

when the AOE (101) judges that other heartbeat requests are not received when a certain time threshold value is exceeded after the heartbeat request is received, the AOE actively sends a disconnection request to the AOG (20); or, when the always-on engine AOE (101) detects that all application clients managed by the AOE do not run within a certain time threshold, actively initiating a disconnection request to the AOG (20); or, when said always-on engine AOE (101) detects that the battery level on said terminal (10) is lower than a certain threshold, then actively sending a disconnection request to said AOG (20); the disconnection request is used for disconnecting the long link;

wherein said AOG (20) actively breaking said long link according to its own judgment comprises:

the AOG (20) is further used for actively initiating a disconnection request when judging that the data stream sent from the AOE (101) is not received after a certain time threshold value is exceeded; actively initiating a disconnection request when judging that the number of times of sending the heartbeat request exceeds a certain threshold value but no response of the AOE (101) is obtained; the disconnect request is for disconnecting the long link.

14. The method according to any of claims 11-13, further comprising: the AOG (20) modifies whether the online state recorded on the AOG (20) by the AOE (101) which has disconnected the long link is offline, and constructs an offline notification message to be sent to the application server.

15. The method of claim 14, further comprising:

the AOG (20) sends a wake-up short message to the AOE (101) for waking up a long link which is not established or disconnected;

and after monitoring and intercepting the awakening short message, the AOE (101) analyzes the awakening short message and triggers the establishment of a long link.

16. A terminal (10) supporting an application client to stay online, comprising: an always-on engine AOE (101) and at least two application clients;

said always-on engine AOE (101), in communication connection with said at least two application clients on said terminal (10), for establishing a long link with the always-on service gateway AOG (20) located on the network side; receiving a heartbeat message initiated by the always-on service gateway, AOG, (20) to facilitate maintaining the long link;

the at least two application clients are used for communicating with one or more application servers (04, 05) on the network side via the AOG (20) over the long link.

17. The terminal (10) according to claim 16,

said AOE (101) further configured to actively break said long link according to its own judgment; or,

the AOE (101) comprises a link management module (1011) for disconnecting the long link when receiving a disconnection request actively sent by the AOG (20).

18. Terminal (10) according to claim 17, said AOE (101) further being adapted to enter a sleep state after said long link is disconnected.

19. The terminal (10) according to claim 17,

the always-on engine AOE (101) specifically comprises:

a heartbeat time module (1012) for actively sending a disconnection request to the AOG (20) when judging that other heartbeat requests have not been received after the heartbeat request exceeds a certain time threshold; or,

an application management module (1012) for actively initiating a disconnection request to the AOG (20) when it is detected that all application clients it manages are not running within a certain time threshold; or,

a battery monitoring module (1014) for actively sending a disconnect request to the AOG (20) when it is detected that the battery level on the terminal (01) is below a certain threshold;

the disconnect request is for disconnecting the long link.

20. The terminal (10) according to any one of claims 16-19, wherein the AOE (101) further comprises a short message processing module (1013) and a link management module (1011), and the short message processing module (1013) is configured to monitor and intercept a wake-up short message, parse the wake-up short message, and trigger the link management module (1011) in the AOE (101) to establish a long link; the link management module (1011) is used for establishing a long link according to a trigger condition.

21. An always-on service gateway, AOG, (20) supporting always-on of application clients, comprising:

-a terminal management module (2011) for establishing a long link between an always-on engine, AOE, (101) located in the terminal (10) and said AOG (20), and initiating heartbeat messages in order to maintain said long link;

wherein at least two application clients on the terminal (10) communicate with one or more application servers (04, 05), respectively, via the AOG (20) over the long link.

22. AOG (20) according to claim 21, comprising: and the adjusting module is used for adjusting the heartbeat interval according to the network condition and automatically controlling the heartbeat parameters.

23. AOG (20) according to claim 22, a disconnection module for actively disconnecting the long link according to its own judgment.

24. AOG (20) according to any one of claims 21-23, the terminal management module (2011) is further configured to: and if the disconnection request sent by the AOE (101) is not received and is not actively sent to the AOE (101), regularly sending heartbeat messages to the AOE (101) according to the heartbeat time interval so as to maintain the long connection.

25. AOG (20) according to claim 23,

wherein the disconnection module is specifically configured to: when judging that the data stream sent from the AOE (101) is not received after a certain time threshold value, actively initiating a disconnection request; or, when judging that the number exceeds a certain threshold value and a heartbeat request is sent, but no response of the AOE (101) is obtained, actively initiating a disconnection request; the disconnect request is used to disconnect the long link.

26. AOG (20) according to claim 24, said terminal management module (2011) being further adapted to modify the presence status recorded on said AOG (20) by said AOE (101) that has broken the long link to offline, and to construct an offline notification message to send to said application server.

27. AOG (20) according to claim 26, the AOG (20) further comprising a short message push module (2015) for sending a wake-up short message to the AOE (101) for waking up a long link that has not been established or has been disconnected.

28. The always-on service gateway AOG (20) according to claim 21, further comprising:

the application management module (2012) is configured to query information of the permanently online application client registered on the AOE (101), and if the application client needs to interact with one or more application servers by using a pseudo code, convert the mobile phone number of the terminal where the AOE (101) is located, which is stored on the AOG (20), into a pseudo code, where the pseudo code is used to be transmitted between the AOG (20) and the application servers as user identity information.

29. AOG (20) according to claim 28,

the application management module (2012) comprises:

a first module, configured to calculate a pseudo code corresponding to the mobile phone number according to the mobile phone number and the random number, and send the pseudo code to the application server, or,

a second module for generating pseudo code according to the following method: HASH (MSISDN, Time, APPID, Random), where: HASH is a HASH algorithm, MSISDN is a user mobile phone number, Time is a timestamp, and APPID is an application identifier; random is a Random number.