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

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

A method, system and device for supporting application clients to be permanently online

technical field

The invention relates to the communication field, in particular to a method, system and device for supporting application clients to be permanently online.

Background technique

There are a large number of "permanently online" applications on smart terminals. This type of application periodically establishes a connection with the server and updates the status through the PULL mode initiated by the terminal, which will generate a large number of repeated and short PULL messages, such as Instant message IM, social network SNS, VOIP and other permanent online applications require the client to frequently send "keepalive" messages to notify the online status of the service; another example, IM and SNS applications require the client to frequently update the status of friends to the server; Synchronization, refresh; iAD advertisement push of iphone4, location tracking service all need to consume a lot of communication resources and so on.

In order to keep the 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 firewalls in the middle of the link, and the user's IP address may change. Therefore, it is necessary to maintain the link through frequent heartbeats and obtain user status (shown information).

Generally, when the terminal performs normal data communication, the network allocates a dedicated physical channel to the terminal for uplink and downlink wireless transmission of data. This state is called DCH (Dedicated CHannel Dedicated Channel) state. When there is no data transmission, the terminal can be processed in the Idle state. In the Idle state, all connections are closed at the access layer, and the terminal only monitors paging information. Therefore, in the DCH state and the Idle state, the power consumption of the terminal is very different. Based on the consideration of power saving, the smart terminal generally has no data transmission for 6 to 8 seconds, and the mobile phone performs "quick sleep" and is forced to switch to the Idle state. And "always on" applications often need a heartbeat connection with the server. As a result, the terminal frequently switches between the Idle state and the DCH state. From the Idle state to the DCH active state, the wireless side needs 32 signalings to restore the link. This frequent switching between the states has a significant impact on the signaling on the wireless side.

Contents of the invention

An embodiment of the present invention provides a method for supporting application clients to be permanently online, and establishes an a long link, wherein at least two application clients communicate with one or more application servers (04, 05) respectively through the long link; the user management server (30) located 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 used to provide authentication information to the AOG (20) during the process of establishing the long link.

Preferably, the user management server (30) acquires and stores the corresponding relationship between the terminal identity information and the user identity information, and stores the address of the AOG (20) to which the user identity information belongs; when the AOE (101) sends the mobile terminal When requesting identity information routing information, the user management server (30) sends the AOE (101) a Provide the address of the AOG to which the user identity information belongs; when the AOG (20) sends an authentication information request, the user management server (30) according to the terminal identity information in the authentication information request, and the terminal identity information and The corresponding relationship of the user identity information provides the user identity information to the AOG (20).

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

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

The AOE (101) automatically sends a report message to the user management server (30) when the permanent online engine AOE (101) starts or detects that the ISMI information in the SIM card is different from the information registered last time, and the report message carries The IMSI information and the mobile phone number; the user management server (30) obtains 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; the AOE (101) sends the The user management server (30) sends a routing information request, which carries the IMSI information in the routing information request; the user management server (30) finds the corresponding mobile phone number according to the IMSI information in the routing information request received, and then according to the pre-stored The AOG address to which the mobile phone number belongs, returns the address of the AOG (20) to which the mobile phone number belongs to the AOE (101); the permanent online engine AOE (101) initiates a registration request to the AOG (20) to which the mobile phone number belongs, and the The registration request carries IMSI information; after the AOG (20) receives the registration request of the AOE (101), it judges whether the IMSI information contained therein has been registered in the AOG (20), and if not registered, it will send the IMSI information to the user management server (30 ) sends an authentication information request, and the authentication information request carries the IMSI information in the registration request; after receiving the authentication information request, the user management server (30) returns the corresponding relationship between the mobile phone number and the IMSI information according to the storage. The mobile phone number corresponding to the IMSI information; when the AOG (20) judges that the mobile phone number belongs to the service scope of the AOG (20), the AOG (20) stores the mobile phone number, and returns a registration response to the AOE (101).

Preferably, the reporting message is a short message, and the reporting message carries IMSI information and a mobile phone number specifically including: the content of the short message includes 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.

Another embodiment of the present invention provides a system for supporting application clients to be permanently online, and the system includes: an always-on engine AOE (101), located in a terminal (10), and communicating with at least two application clients; The always-on service gateway AOG (20), located on the network side, communicates with one or more application servers (04, 05) located 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 respectively communicate with the one or more application servers (04, 05) through the long link; the user management server (30), located on the network side, communicates with the The always-on engine AOE (101) communicates with the always-on service gateway AOG (20), and is used to provide routing information to the AOE (101), so that the AOE (101) requests to establish the long link according to the routing information. During the process of establishing a long link between the AOE (101) and the AOG (20), further provide authentication information to the AOG (20).

Preferably, the user management server (30) is specifically used to: acquire and store the corresponding relationship between terminal identity information and user identity information, and store the address of the AOG (20) to which the user identity information belongs; when the AOE (101) When sending a routing information request carrying terminal identity information, according to the corresponding relationship between the terminal identity information and the user identity information, and the address of the AOG (20) to which the user identity information belongs, provide the AOE (101) with The address of the AOG to which the user identity information belongs; when the AOG (20) sends an authentication information request, according to the corresponding relationship between the terminal identity information in the authentication information request and the terminal identity information and the user identity information, to the AOG AOG (20) provides 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 used for: when the permanent online engine AOE (101) starts or detects that the ISMI information in the SIM card and When the last registered information is different, automatically send a report message to the user management server (30), the report message carries the IMSI information and the mobile phone number; send a routing information request to the user management server (30), in the routing information request carry the IMSI information; initiate a registration request to the received AOG (20) to which the mobile phone number belongs, and the registration request carries the IMSI information. The user management server (30) is specifically used to: obtain the IMSI information and the mobile phone number according to the received report message, store the corresponding relationship between the mobile phone number and the IMSI information; Find the corresponding mobile phone number, and then return the address of the AOG (20) to which the mobile phone number belongs to the AOE (101) according to the AOG address of the pre-stored mobile phone number; after receiving the authentication information request, according to the stored AOG address The corresponding relationship between the mobile phone number and the IMSI information returns the mobile phone number corresponding to the IMSI information. The AOG (20) is specifically used to: after receiving the registration request of the AOE (101), determine whether the IMSI information contained therein has been registered in the AOG (20), and if not, send the IMSI information to the user management server (30) Authentication information request, the authentication information request carries the IMSI information in the registration request, and receives the mobile phone number corresponding to the returned IMSI information; when it is judged that the mobile phone number belongs to the service scope of the AOG (20), the AOG (20 ) stores the mobile phone number, and returns a registration response to AOE (101).

In other embodiments, an always-on engine AOE (101), an always-on service gateway AOG (20), and a user management server (30) capable of performing each relevant step of the foregoing method are provided accordingly.

In another embodiment of the present invention, in a system supporting permanent online application clients, the always online engine AOE (101), located in the terminal (10), communicates with at least two application clients, and is used to communicate with the always online service gateway A long link is established between AOG (20); the permanent online service gateway AOG (20), located on the network side, is used to establish the long link with the permanent online engine AOE (101), and initiates a heartbeat message, so as to maintain the A long link; wherein, the at least two application clients communicate with the one or more application servers (04, 05) through the long link.

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

Preferably, the permanent online engine AOE (101) is further used to actively send a disconnection request to the AOG (20) when it is determined that no other heartbeat requests have been received when a certain time threshold is exceeded after receiving the heartbeat request; Or, when it detects that all the application clients it manages are not running within a certain time threshold, it actively initiates a disconnection request to the AOG (20); or, when it detects that the battery power on the terminal 01 is lower than a certain threshold , then actively send a disconnection request to the AOG (20), the disconnection request is used to disconnect the long link.

Preferably, AOG (20) is further used to actively initiate a disconnection request when it is determined that the data stream sent from the AOE101 has not been received beyond a certain time threshold; when it is determined that the heartbeat request is sent beyond a certain threshold, but When there is no response from the AOE 101, a disconnection request is actively initiated, and the disconnection request is used to disconnect the long link.

Preferably, the AOG (20) is further used to modify the online status recorded on the AOG (20) by the AOE101 that has disconnected the long link to offline, and construct an offline notification message and send it to the application server to send to the application server.

Preferably, the AOG (20) is further used to send a wake-up short message to the AOE (101) under special circumstances, so as to wake up a long link that has not been established or has been disconnected.

Preferably, the AOE (101) is further used to monitor and intercept the wake-up message, analyze the wake-up message, and trigger the establishment of a long link.

In another embodiment of the present invention, in a system supporting permanent online application clients, the always online engine AOE (101), located in the terminal (10), communicates with at least two application clients, and is used to communicate with the always online service gateway A long link is established between AOG (20); wherein, the at least two application clients communicate with one or more application servers 04 through the long link; AOE (101) is further used When establishing), the application client in the terminal (10) has exited, but when the data sent to the application client forwarded by the AOG (20) is received, the exited application client is pulled up.

In another embodiment of the present invention, in a system supporting permanent online application clients, the always online engine AOE (101), located in the terminal (10), communicates with at least two application clients, and is used to communicate with the always online service gateway A long link is established between the AOG (20); wherein, the at least two application clients communicate with one or more application servers 04 through the long link; the AOE (101) is further used when the application client has a large amount of data to communicate with When one of the application servers interacts, a separate connection is provided to interact with the application server, and the original long link can be mainly used to transmit data related to the control flow.

Preferably, when the transmitted data reaches the threshold, a dedicated IP proxy channel needs to be established, and the channel is used to specifically transmit the transmitted data. Generally, these data are data streams generated during the process of providing applications.

Preferably, the IP proxy channel can be actively closed when the data transmission ends.

Preferably, if the application client or application server does not actively close the IP proxy channel, the AOE (101) can set a timeout mechanism, and after no data interaction reaches a threshold (for example, 60s), the AOE (101) will actively disconnect.

In some other embodiments of the present invention, a corresponding method executed by the above system, and a corresponding AOE (101), terminal (10), and AOG (20) are provided.

Through the above-mentioned different implementation modes, a system, method and device that saves communication resources and supports permanent online application clients are provided from different aspects.

Description of drawings

FIG. 1 is a schematic diagram of an application environment of an embodiment of the present invention;

Fig. 2a is a system architecture diagram of an embodiment including a user management server;

Fig. 2b is a method flow chart of the embodiment of establishing a long link in a system including a user management server;

FIG. 3a is a flow chart of a method for an implementation of establishing a long link, taking an operator's communication system as an example;

Fig. 3b is a method flow diagram of an embodiment of a schematic flow diagram of updating an application client;

Figure 4a is a system architecture diagram of an implementation of long link heartbeat maintenance;

Fig. 4b is a method flow chart of an embodiment of a long link heartbeat maintenance method;

FIG. 5a is a flow chart of a method described from the perspective of AOE (101) about the implementation of long link heartbeat maintenance;

FIG. 5b is a flow chart of a method described from the perspective of AOG (20) about the implementation of long link heartbeat maintenance;

FIG. 6 is a system architecture diagram of an embodiment including extended functions;

FIG. 7 is a flow chart of a method for waking up a long link implementation;

FIG. 8 is a flow chart of a method for waking up an implementation of an application client;

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

FIG. 10 is a schematic structural diagram of an embodiment of an AOG (20);

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

detailed description

In order to clarify the embodiments of the invention, each possible term is explained as follows:

AOG: AOG (AlwaysOnlineGateway), an always-on gateway, through cooperation with the always-online engine, can provide a general PUSH channel for the SP, allowing the SP service side to find terminals anytime and anywhere.

AOE (101): AOE (101) (AlwaysOnlineEngine), an always-online engine, is a middleware deployed on the terminal side, which aggregates and acts as an agent for the always-online requirements of the client application client.

AOI: AOI (AlwaysOnlineInfrastructure), an always-on facility, including AOE (101), AOG, or a collection of various network elements such as a user management server.

FIG. 1 is a schematic diagram of an application environment system of an embodiment of the present invention. The system includes multiple communication devices that communicate with each other through a wired or wireless communication network. These communication networks include but are not limited to mobile communication network (mobiletelephonenetwork), wireless local area network (wirelessLocalAreaNetwork (LAN)), Bluetooth network (Bluetoothpersonalareanetwork), Ethernet (EthernetLAN), token ring local network (atokenringLAN), wide area network (awideareanetwork) , Internet (theInternet,) and so on.

In the system shown in Fig. 1, terminal (10) can include but not limited to, mobile device (mobiledevice), the PDA device (acombinationPDAandmobiletelephone) of mobile communication, PDA, integrated information device (integratedmessagingdevice (IMD)), personal computer (personalcomputerand Notebook computer. These terminals can be mobile or located on a mobile device, such as but not limited to cars, trucks, taxis, buses, ships, airplanes, bicycles, motorcycles, etc. The above-mentioned terminal (10) can access one or more application servers 04 through the wireless network and/or the wired network, so as to obtain the applications provided by the one or more application servers 04. One or more application servers include But not limited thereto, the above network may include other communication devices of various types.

The above communication devices can realize the communication process 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 TimeDivisionMultipleAccess (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol TransmissionControlProtocol/InternetProtocol (TCP/IP), Short Message Service ShortMessaGIngService (SMS), Multimedia Information Service MultimediaMessagingService (MMS), e-mail, Instant Messaging Service (IMS), Bluetooth, IEEE802.11, etc. Different media resources can be used between the above communication devices, including but not limited to, radio (radio), infrared (infrared), laser (laser) , cable (cableconnection), and so on.

As shown in Figure 2a, it is a schematic diagram of the architecture of a system implementation that supports application clients to be permanently online. The system includes:

The always-on engine AOE (101), located in the terminal (10), communicates with at least two application clients;

The permanent online service gateway AOG (20), located on the network side, communicates with one or more application servers (04, 05) located on the network side;

The always-on engine AOE (101) and the always-on service gateway AOG (20) are configured to establish a long link, wherein the at least two application clients communicate with the one or more Application server (04,05) communication;

The user management server (30), located on the network side, communicates with the always-on engine AOE (101) and the always-on service gateway AOG (20), and provides routing information to the AOE (101), wherein the 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 process of establishing the long link.

The one or more application servers mentioned above may include but not limited to servers providing one or any combination of the following applications: PUSHMail, weather forecast, VOIP, advertisement, location service, enterprise office, life service, and so on.

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

The above-mentioned user management server (30) may serve as a management node of permanent online service user data, and provide routing information to the AOE (101), so that the AOE (101) requests to establish the long link according to the routing information; and , providing authentication information to the AOG (20) during the process of establishing a long link between the AOE (101) and the AOG (20). The above solution can enable the always-on engine AOE (101) and the always-on service gateway AOG (20) to easily and safely establish the long link. It should be noted that the user management server (30) can be clustered or distributed internally; it can be co-located with any possible device on the network side, or set independently, but it can be connected with other devices for AOG To distinguish, there may be multiple AOGs in the above system.

In a preferred embodiment, the above-mentioned authentication information is user identity information, such as mobile phone number, user ID or user name, which is convenient for various application servers to perform authentication on their users. In a specific embodiment, AOG(20) Proxy the authentication process. However, in general, the terminal (01) carries terminal identity information during the communication process, such as IMSI information, or device identification. If this information is used as authentication information, it needs to carry out complicated transactions with one or more application servers and other devices in advance. Authentication interaction. In addition, it should be noted that the above-mentioned routing information is the address of the AOG (20) to which the user identity information belongs. In a specific implementation, for the entire network, there may be multiple AOGs (20), which need to be specified as a certain user identity information AOG that provides proxy services.

Referring to Fig. 2b, it is a flow chart of a preferred embodiment, and the system in Fig. 2 mentioned above executes the following method:

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

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

203. When the AOG (20) sends the authentication information request, the user management server (30) (such as the authentication information module (3013)) according to the terminal identity information in the authentication information request, and the terminal identity information and the user identity information Corresponding relationship, provide user identity information to AOG (20).

Specifically, the above-mentioned process of obtaining and storing the corresponding relationship between terminal identity information and user identity information can be realized by using other possible communication channels, such as circuit domain communication channels or short message channels, before the aforementioned long link is established. Specifically, it 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 other network devices, or it may be that the user management server (30) reports to the terminal (10) Or obtained by other network device requests.

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

301, when the AOE (101) (for example, the link management module (1011) on the AOE (101)) starts the always-on engine (101) or detects that the ISMI information in the SIM card is different from the last registered When the information is different, a report message is automatically sent to the user management server (30), and the report message carries the IMSI information and the mobile phone number.

The aforementioned reporting message is information that can be sent without establishing the aforementioned link between the AOE (101) and AOG (20), such as circuit domain information or non-data link information. More specifically, it may be a short message, or an online Radius notification forwarded by the AAA server, and the like. If it is a short message, it only needs to carry the IMSI information in the content, and the system defaults the sender to the mobile phone number, which further saves data communication resources.

302. The user management server (30) (such as the above-mentioned registration management module (3011)) obtains the IMSI information and the mobile phone number according to the received reporting message, and stores the corresponding relationship between the mobile phone number and the IMSI information .

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

304. The AOE (101) (for example, the link management module (1011)) sends a routing information request to the user management server (30), where the routing information request carries the IMSI information.

305, the user management server (30) (such as the routing information module (3012)) finds the corresponding mobile phone number according to the IMSI information in the received routing information request (specifically, refers to searching the above-mentioned registration management module (3011)), Then, according to the AOG address to which the mobile phone number belongs, the address of the AOG (20) to which the mobile phone number belongs is returned to the AOE (101).

306. After the AOE (101) (for example, the link management module (1011)) acquires the information of the AOG to which it belongs, it initiates a registration request to the AOG (20) to which it belongs, and the registration request carries IMSI information.

Preferably, the registration request may also carry but not limited to: information about the registered application client in the AOE (101), such as the application identifier, terminal model, access network APN, operating system version, and AOE ( 101) version and so on.

307. After receiving the registration request, the AOG (20) judges whether the IMSI information included in the registration request of the AOE (101) has been registered in the AOG (20).

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

309. After receiving the authentication information request (specifically, such as 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).

310. The AOG (20) (for example, the link management module (2011)) judges whether the mobile phone number is within the service scope of the AOG (20). If not, return registration failure, and the process ends. If it belongs to the service scope of the AOG (20), the AOG (20) (such as the link management module (2011) therein) stores the mobile phone number. Preferably, other information carried in the aforementioned registration information can also be saved, such as terminal model, registered application clients, and other information.

311. After successful registration in 310, the AOG (20) (for example, the link management module (2011) therein) returns a registration response to the AOE (101) (for example, the link management module (1011)).

So far, the AOE (101) has successfully established the aforementioned long link with the AOG (20) to which it belongs. This process utilizes trusted terminal information and user information in the system to establish a long link, and does not require the system to generate a unique device ID for each terminal (10) through complex interactions, and use the unique device ID to establish a long link. This improves the security of long links while simplifying the process.

The aforementioned Figure 3a shows that when the terminal (10) is started or when it is detected that the ISMI information in the SIM card is different from the information registered last time (that is, the SIM card in the terminal is replaced, it can be understood as a new terminal (10) ), specifically, includes registration of terminal information on the AOG (20) and registration of 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 added or deleted, and a similar method needs to be adopted to update the application information. Referring to FIG. 3 b , it is a schematic flow chart of updating an application, wherein the AOG ( 20 ) is a system composed of the AOG where the terminal ( 10 ) belongs and the AOG where the application server is accessed. In a specific example, the process includes:

301b, install (or uninstall) on the terminal an application client that supports interaction with the AOE (101) to implement the AOI function;

302b. After the application client is installed (or uninstalled), call the application registration interface of the SDK to register (uninstallation is regarded as calling the application registration interface of the SDK to logout);

303b, AOE (101) invokes the REG interface, and sends a request to add an application to the AOG where the terminal belongs (a request to delete an application when uninstalling);

304b. The AOG at which the terminal belongs updates the application information corresponding to the terminal into the database;

305b, the AOG where the terminal belongs returns a registration response to the AOE (101) (no deregistration response during uninstallation);

305b. The terminal's home AOG constructs an INFO online notification message according to the application ID reported by the terminal, and sends it to the application's home AOG gateway. The online notification message carries the mobile phone number. (When uninstalling, it is an offline notification message).

307b, the AOG at the access location of the application server converts the mobile phone number into a pseudo code.

308b. The AOG where the application server is connected forwards the online notification message (the offline notification message when uninstalling) to the application server, and the message carries a pseudo code.

309b, the application server returns a notification response.

310b. The AOG where the application server is connected forwards the notification response to the original notification initiator AOG gateway.

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

If the AOG gateway to which the terminal belongs is not the same gateway as the AOG gateway to which the application belongs, and there is no effective connection between them, before forwarding the message, the AOG gateway to which the terminal belongs actively completes REG registration with the AOG gateway to which the application belongs process before message forwarding.

In order to simplify the processing flow of REG messages inside the AOG gateway, in the application installation process, AOG02 does not need to distinguish the type of registration message (or deregistration message). After receiving the message, it can still follow the first registration process to confirm that the IMSI digest is in the Whether this AOG exists, if do not exist, query mobile phone number on user management server 03, and according to whether mobile phone number belongs to the scope of this AOG service, confirm the content of returning message to AOE (101). It's just that in the simple application installation process, the IMSI must exist, and the number must belong to this AOG, and it will not go to another branch.

As shown in Figure 4a, it is a schematic diagram of the architecture of a system implementation mode that supports application clients to be permanently online, and the system includes:

At least two application clients, the application clients are located in the terminal (10) and communicated with the always-on engine AOE (101);

The always-on engine AOE (101), located in the terminal (10), communicates with at least two application clients, and is used to establish a long link with the always-on service gateway AOG (20);

The permanent online service gateway AOG (20), located on the network side, is used to establish the long link with the permanent online engine AOE (101);

One or more application servers (04, 05), located on the network side, communicate with the permanent online service gateway AOG (20);

Wherein, the at least two application clients communicate with the one or more application servers 04 through the long link, so as to realize the application services provided by the one or more servers (04, 05); in the system, the long The maintenance of the link is in charge of the AOG (20) on the service side, that is, between the terminal (10) and the AOG (20), the AOG (20) initiates a heartbeat message, so as to maintain the long link. The application client is used to provide user-oriented application services, and the application server 04 is used to provide various application services, such as one or any combination of the following applications: PUSHMail, weather forecast, VOIP, advertisement, location service, enterprise office, Living Services, etc.

As shown in Figure 4a, using this method of maintaining long links, compared with the method of initiating heartbeats from the terminal side, on the one hand, the terminal (including each application client in it) does not need to send a large number of heartbeats to one or more application servers messages to reduce the signaling pressure on the terminal side. On the other hand, the AOE (101) in the terminal does not need to perform special processing such as filtering/abandoning these heartbeats. While reducing the signaling consumption sent by the terminal, further The internal signaling consumption of the terminal (10) is greatly reduced; in addition, when the AOG (20) initiates a heartbeat, the heartbeat interval can be adjusted according to the network situation, and the heartbeat parameters can be automatically controlled to make the heartbeat most suitable for the network situation, thereby avoiding active detection on the terminal side The process of network parameters further reduces the waste of communication resources.

Referring to Fig. 4b, in a preferred implementation manner, AOE (101) and AOG (20) can each actively disconnect the long link according to their own judgment, thereby further saving communication resources of the network, terminal, server, etc., Of course, the power consumption of each device, especially the terminal (10) is also saved. When necessary, the AOG (20) can actively wake up the connection with the terminal side again.

Referring to FIG. 5 a , it is a schematic diagram of an embodiment of heartbeat maintenance for long links from the perspective of the AOE ( 101 ). Referring to Fig. 5a, after the long link is established, AOE (101) is a schematic diagram of a better method for maintaining the long link, including:

Optionally, the AOE (101) (eg, the link management module (1011) therein) disconnects the long link after receiving a disconnection request (eg, BYE) actively sent by the AOG (20).

Optionally, after the AOE (101) (for example, the heartbeat time module (1012)) receives the heartbeat message, it refreshes the timer, and if the timer has not received other heartbeat messages when it exceeds a certain time threshold, it sends a message to the AOG ( 20) Send a disconnection request (for example, BYE) to close the long link. For example, set the time threshold as 5 minutes, 10 minutes, or 30 minutes and so on.

Optionally, when the AOE (101) (such as the application management module (1012)) detects that all the application clients it manages are not running within a certain time threshold, it actively initiates a disconnection request (such as a BYE request), then Disconnect the long link. For example, set the time threshold as 5 minutes, 10 minutes, or 30 minutes and so on.

Optionally, the AOE (101) (such as the battery monitoring module (1014) therein) monitors the battery power of the terminal (10), and when the power is less than a certain threshold (for example, only 10% or 5% of the power is left), if If there is a long link, a disconnection request (such as BYE) is actively sent. Optionally, a tag can be added to the disconnection request, indicating that the long link is disconnected due to low power.

Through the foregoing possible implementation manners, after the long link is disconnected, the AOE (101) enters a dormant state (waiting for the AOG (20) to be awakened by a text message), which can save the power of the terminal (10). Among them, various ways initiated by the AOE (101) to disconnect the long link further reduce unnecessary signaling waste. For example, the AOG (20) on the network side does not need to send heartbeat messages after disconnection, Further saving the battery power on the terminal (10).

In addition, it should be noted that when the long link between AOE (101) and AOG (20) exists, it is necessary to prohibit the operating system of the terminal (10) from entering the sleep state to ensure the normal connection of the long link. When the long-term connection is disconnected, the hibernation mechanism of the operating system can be resumed.

Referring to Fig. 5b, how to maintain the long link is described from the perspective of AOG (20). It should be noted that the AOG (20) described in FIG. 5b may be a single server in an actual application process, and may be divided into AOG ( 20) and the AOG (20) to which one or more application servers belong. Wherein, optionally, for the latter (the 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, and the terminal (10) The belonging AOG (20) is responsible for interacting with the AOE (101) in the terminal (10), and the AOG (20) belonging to one or more application servers is responsible for interacting with one or more application servers. More specifically, from the perspective of the internal structure of the AOG (20), 501 to 504 shown in Figure 5b can be executed by the terminal management module (1021), and the terminal management module (1021) can be located in the AOG to which the terminal (10) belongs (20); steps 500, 505-508 can be executed by the application management module (1022), and the application management module (1022) can be located on the AOG (20) to which the application server belongs.

Specifically, in the embodiment shown in Figure 5b, the following steps are included:

500-501, AOE (101) and AOG (20) successfully established a long link. It includes the AOE (101) completing the REG registration process (501) with the terminal's home AOG, including terminal information and application client information on the terminal. Correspondingly, one or more application servers also need to be successfully registered with the AOG (20) (step 500), so that the AOE (101) (that is, the terminal (10)) offline notification can subsequently notify one or more applications server.

502. After the AOE (101) and the AOG (20) successfully establish a long link, the AOG (20) actively sends an ACK heartbeat message to the terminal, so as to maintain the long link. In a preferred embodiment, the time interval for sending heartbeat messages can be configured according to the network conditions, that is, the heartbeat interval, and the timeout control can be configured;

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

504, AOG (20) maintains long links according to the following situations, including but not limited to:

5041. When the AOG (20) receives the disconnection request actively sent by the AOE (101), it disconnects the long link and does not send a heartbeat message; for details, refer to the process shown in FIG. 5a.

5042. When the AOG (20) judges that the data stream sent from the terminal (10) (AOE (101)) has not been received beyond a certain time threshold, it actively initiates a disconnection request (such as BYE), and no longer sends a heartbeat message. In a preferred implementation manner, the time threshold is configurable, for example, 5 minutes, 10 minutes or 30 minutes by default.

5043, when the AOG (20) judges that after sending the heartbeat message ACT, the situation of not getting a response from the AOE (101) exceeds a certain number of thresholds, initiate a disconnection request (for example, BYE), and no longer send the heartbeat message. In a preferred implementation manner, the number of times threshold is configurable, for example, the default is 3 times, 4 times or 5 times and so on.

5054, not shown in the figure, after 502, if neither the disconnection request sent by AOE (101) nor the initiative to send a disconnection request to AOE (101) is received, then according to the heartbeat time interval, the AOE (101) is regularly sent ) to send a heartbeat message in order to maintain the long link.

In a preferred embodiment, on the basis of the aforementioned maintenance for long links, the AOG (20) (such as the application management module (2012)) can further check the online status of the AOE (101), and the AOE (101) Managed by the application client on the . For example, optionally, 505, if the AOG (20) disconnects the long link according to steps 5041, 5042, or 5043, etc., then confirm that the AOE (101) is offline, and update the online status of the locally stored AOE (101) For: Offline.

Optionally, 506, the AOG (20) queries the information of the permanently online application client registered on the AOE (101), and if it needs to use pseudo-code to interact with one or more application servers, then the AOG (20) (for example The application management module (2012)) converts the mobile phone number of the AOE (101) stored on the AOG (20) into a pseudocode, which is used to transmit between the AOG (20) and the application server as user identity information. Here, the pseudo code is a user's unique identity for a certain application within the system.

Specifically, in order to protect user privacy, some applications cannot disclose the mobile phone number to the application server (SP). At this time, other identifiers need to be used instead of the mobile phone number. The general practice is to make a summary based on the information of the mobile phone number and other random numbers, and the calculated summary can be called a pseudocode. There is a one-to-one correspondence between the mobile phone number and the pseudo code, and the mapping relationship can be kept on the server side. But the algorithm is one-way, that is to say that the relevant random parameters will not be sent to the application server (SP), so the application server (SP) cannot deduce the mobile phone number back by the pseudocode. When one or more application servers (SPs) send downlink messages, users can be identified by pseudo codes. On the server side, for example, the corresponding mobile phone numbers can be queried by pseudo codes, and the messages can be routed to the correct users.

More specifically, the pseudo-code is at the application level, and some applications can be designated to enable the pseudo-code function, and some applications can disable the pseudo-code function. If the application management module (2012) specifies in the control attribute of the application that the pseudo-code needs to be transmitted, it needs to generate a pseudo-code for the mobile phone number that interacts with the application, and maintain the correspondence between the user's mobile phone number and the pseudo-code. In an example, the method of the generated pseudo-code is: pseudo-code=HASH(MSISDN, Time, APPID, Random) wherein: HASH is a hash algorithm, such as using the MD5 algorithm; MSISDN is the user's mobile phone number; Time: a timestamp, such as The format is YYYYMMDDHH24MISS; APPID is the application ID; Random is a random number. For a specified mobile phone number and an application, the pseudo code is only generated once in the system and is valid for a lifetime. Specifically, when it is necessary to convert the mobile phone number into a pseudo code, the system first performs a joint query of the local database based on the mobile phone number and the application ID. If no pseudo code is found, it proves that the application is used for the first time, and the above algorithm is used to generate a pseudo code. When the conversion from pseudocode to mobile phone number is required, AOG (20) queries the local database, and if the query fails, it proves that the pseudocode specified by the application is wrong. When the query is successful, match the APPID in the application message with the APPID in the local pseudocode database. If the match is successful, the pseudocode verification is considered successful.

Optionally, 507 AOG (20) constructs an offline notification message and sends it to one or more application servers, and the offline notification message includes a pseudocode.

Correspondingly, at 508, one or more application servers may return a notification response after 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 the AOG (20) to which the AOE (101) belongs and one or more application servers A system composed of the belonging AOG (20), then the AOG (20) belonging to the AOE (101) sends an offline notification message containing the mobile phone number to the AOG (20) belonging to one or more application servers, and one or more application servers The AOG (20) to which the server belongs converts the mobile phone number into a pseudocode, and sends an offline notification message containing the pseudocode to one or more application servers.

Based on the various possible implementations above, after the long link is disconnected, the AOE (101) can wait for the AOG (20) to be woken up by a text message, and re-establish the long link. Concretely can be realized by the system as shown in Figure 6, for example is " SMS push module (2015) " in AOG (20), " SMS processing module (1013) " in AOE (101), " application wake-up module ( 1015)" and so on to achieve.

Specifically, refer to FIG. 7 , which is a schematic flowchart of an implementation manner of waking up the long link when the long link is disconnected. include:

701, the SMS push module (2015) in the AOG (20) sends a "wake-up SMS" to the AOE (101) under special circumstances to wake up the long link that has not been established or has been disconnected.

Specifically, the wake-up message is not an ordinary text message, but a binary message in a special format, agreed between the AOG (20) and the AOE (101), the two are understandable and invisible to other network devices. The binary short message used to wake up the long link may include the ID of the application to be woken up, the ID of the sender of the downlink message, the ID of the destination user, and a summary of the message.

702. After the short message processing module (1013) in the AOE (101) monitors and intercepts the "wake-up text message", the "wake-up text message" is parsed to trigger the link management module (1011) in the AOE (101) to establish a long link; specifically, Monitoring is to detect the presence of wake-up messages, and interception means that the wake-up messages are no longer passed down, and other applications will no longer receive the wake-up message content.

703-704, the link management module (1011) in the AOE (101) initiates a registration request to the AOG (20) according to the prompt of the SMS processing module (1013), and receives the registration response returned by the AOG (20), and correspondingly establishes the For a long link, the AOG (20) sends the downlink message sent by the application server to the AOE (101) through the aforementioned re-established long link.

In another preferred embodiment, referring to FIG. 8 , it is a schematic flowchart of a method for waking up an application client. After the long link has been established or has been awakened, but the application client in the terminal (10) has exited, but When the data sent to the application client forwarded by the AOG (20) is received (801), the application wake-up module (1015) in the AOE (101) can also pull up the exited application client (802).

Specifically, the application client and the AOE (101) are two independent processes on the terminal (10). When the application starts, it needs to register with the AOE (101), and inform the AOE (101) of its program installation location, operating parameters and other information. The AOE (101) can monitor the running status of the application client on the terminal. When the application client exits (probably actively exiting according to the user's instruction), and there is a downlink message to be notified to the application client, the AOE (101) re-runs the client program according to the previous registration information, thereby pulling up the application The client then notifies the application client of the received downlink message through an internal API interface or message interface.

In other implementations, different further implementations that can be combined with the above-mentioned implementations can be provided. Referring to FIG. 6, optionally, AOE (101), AOG (20), user management server (30 ) contains a variety of possible modules, and unless there is logical exclusion between the modules, any combination can be made to form a better implementation. Each device and each module in the device will be introduced one by one below.

Fig. 9 is a schematic structural diagram of an embodiment of a terminal (10) in the system. The terminal (10) generally includes at least one processor (102) (such as CPU), at least one network interface (105) or other communication interfaces, memory (106), and at least one communication bus (103), used to realize the communication between connections. The processor (102) is used to execute the executable module stored in the memory, such as a computer program; the terminal (10) optionally includes a user interface (104), including but not limited to a display, a keyboard, and a pointing device (such as a mouse, track Ball (trackball), touch-sensitive board or touch-sensitive display screen. Memory (106) may comprise high-speed Ram memory, also may also comprise non-volatile memory (non-volatile memory), for example at least one disk memory. Through at least one network interface (can It is wired or wireless) to realize the communication connection between the terminal (10) and at least one other computer, and Internet, wide area network, local network, metropolitan area network, etc. can be used.

The memory (106) may optionally include at least one storage device (such as an external storage device) located away from the aforementioned CPU 801 . In some embodiments, the memory (106) stores the following elements, executable modules or data structures, or a subset thereof, or an extension thereof:

The operating system (106) is used for, including various programs, for realizing various basic services and processing tasks based on hardware;

At least two application clients (108) are used for the communication connection of the always-on engine AOE (101), and are used to provide application services to users respectively;

The always-on engine AOE (101), communicates with at least two application clients (108) located in the terminal (10), communicates with the always-on service gateway AOG (20) located on the network side, and communicates with an Or a plurality of one or more application servers 04 are communicated through the permanent online service gateway AOG (20);

Include but not limited to one of following modules or its combination in this permanent online engine AOE (101):

Link management module (1011), application management module (1012), short message processing module (1013), data forwarding module (1014), application wake-up module (1015), IP proxy module (1016), heartbeat time module (1017), or , battery monitoring module (1018), API interface and so on.

In a specific embodiment, the link management module (1011) can be used to establish a long link between the AOE (101) and the permanent online service gateway AOG (20), wherein the at least two application clients pass The long link communicates with one or more application servers (04, 05) respectively; obtains routing information from a user management server (30), and requests to establish the long link according to the routing information. Specifically, the process of obtaining routing information includes: sending a routing information request containing terminal identity information to the user management server (30), receiving the user management server (30) according to the stored correspondence between the terminal identity information and user identity information, and the user Address of the AOG to which the identity information belongs returns the address of the AOG. 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 user identifier. Specifically, the above process may refer to the implementation manners shown in FIGS. 2b, 3a, and 3b.

Optionally, the permanent online engine AOE (101) provides an API interface, and the application client can communicate with it through the API interface. In this way, each application client does not directly establish a long link with the application provider, but through the permanent online engine AOE (101) Establish a long link.

Optionally, the AOE (101) includes an application management module (2013), which manages the application clients registered on the permanent online engine AOE (101), including but not limited to program registration, deregistration, and program running , Exit the report of the running status

Optionally, the always-online engine AOE (101), for example, further includes a data forwarding module (1014), which can be used to receive data from different application clients, and then send it out through the aforementioned "long link"; "Link" to obtain data, and according to the application ID in the data to determine which application client the message belongs to, and then forward the message to the application client. Specifically, the uplink message sent by the application client is forwarded to the permanent online service gateway 102, so as to be forwarded to one or more application servers; The downlink message sent by an application server is forwarded to the application client.

In another preferred embodiment, when the application client has a large amount of data and needs to interact with one or more application servers, the AOE (101), such as the IP proxy module (1016), can provide a separate connection with one or more Application server interaction. Preferably, when the transmitted data reaches a threshold, an IP proxy channel needs to be established, and the IP proxy channel is used to exclusively transmit the data. Preferably, the IP proxy channel can be actively closed at the end of the data transmission. Preferably, if the application client or one or more application servers do not actively close the IP proxy channel, AOE (101) can set a timeout mechanism, and after no data interaction reaches a threshold (for example, 60s), AOE (101) will actively Disconnect.

Fig. 10 is a schematic structural diagram of an embodiment of the always-on gateway AOG (20) in the system. It should be noted that as mentioned above, it can be set as two separate devices that are not in the same physical location as required, that is, the AOG (20) to which the terminal (10) belongs and the AOG (20) to which the application server belongs. The communication completes related functions together, and its structure is similar, but the application module may contain different modules according to its location.

The AOG (20) is located on the network side, and communicates with the always-on engine AOE (101) located in the terminal (10), and the always-on engine AOE (101) communicates with at least two application clients located in the terminal (10); Communicatively connected with one or more one or more application servers (04, 05) located on the network side.

The AOG (20) generally includes at least one processor (202) (such as a CPU), at least one network interface or other communication interface (205), memory (206), and at least one communication bus (203), for implementing these means communication between connections. The processor (202) is used to execute executable modules, such as computer programs, stored in the memory. The AOG (20) optionally also includes a user interface (904), including but not limited to a display, keyboard, and pointing device (e.g., mouse, trackball (trackball), touch pad, or touch-sensitive display. Memory (906) may include High-speed Ram memory may also include non-volatile memory (non-volatilememory), such as at least one disk memory. Realize between this AOG (20) and at least one other computer by at least one network interface (can be wired or wireless) The communication connection can use Internet, wide area network, local network, metropolitan area network and so on.

The memory (206) may optionally include at least one storage device (such as an external storage device) located away from the aforementioned CPU. In some embodiments, the memory (206) stores the following elements, executable modules or data structures, or a subset thereof, or an extension thereof:

The operating system (207) is used to include various programs for realizing various basic services and processing hardware-based tasks; and, one or any combination of the following modules:

Terminal management module (2011), application management module (2012), routing management module (2013), cache management module (2014), SMS push module (2015), IP push module (2016), protocol conversion module (2017), or , Upgrade Management Module (2018).

In a specific embodiment, the terminal management module (2011) is configured to establish a long link between the permanent online engine AOE (101) and the AOG (20), wherein at least two application clients pass the long link communicate with the one or more application servers (04, 05) respectively; and obtain authentication information from the user management server (103) during the process of establishing the long link. Specifically, the terminal management module (2011) is configured to: send an authentication information request carrying terminal identity information to the user management server (30), and receive an authentication information request carried by the user management server (30) based on the terminal identity information and the user identity Correspondence of information, returned 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 at the same time, in a preferred embodiment, optionally, the terminal management module (2011) in the permanent online service gateway AOG (20) can also be used to realize the management of the terminal (10), for example, manage the registration to The information of the AOE (101) in the system, such as the IMSI summary, the user agent (UserAgent, UA) information of the AOE (101), and the application information registered on the AOE (101), such as the current The identity of the installed app or its version. Optionally, the terminal management module (2011) can also authenticate the identity of the AOE (101), register the registration information, and store it in the system. For the specific process, reference may be made to the implementation manners shown in 2b, 3a, 3b and so on. Preferably, the terminal management module (2011) can also manage the long link between the AOE (101) and the AOG, such as sending heartbeat messages, maintaining long link state information, such as established state, disconnected state, etc.

Optionally, the application management module (2012) in the permanent online service gateway AOG (20) can manage the application, for example, manage all application information connected to the AOG (20), including the application server to which the application belongs ( Or the application provider (SP) and its information provide functions such as access authentication and usage authority control to one or more accessed application servers. In a preferred implementation manner, management of pseudo codes is performed for specific applications, and so on. For a specific process, reference may be made to each implementation manner shown in FIG. 5b.

Optionally, the routing management module (2013) in the permanent online service gateway AOG (20) can implement routing management: for uplink and downlink messages, the AOG can correctly route to the corresponding network element.

Optionally, the cache management module (2014) in the permanent online service gateway AOG (20) can implement cache management. Specifically, according to application requirements, the data message delivered to the AOE (101) by the application fails to be delivered. , the message is cached. Specifically, the cached message should be retried, and a success status report should be returned to the application after the retry succeeds.

Optionally, the SMS push module (2015) in the AOG (20) can send a "wake-up SMS" to the AOE (101) under special circumstances to wake up the long link that has not been established or has been disconnected; the application server will send The downlink message is sent to the AOE (101) through the aforementioned re-established long link. For a specific process, reference may be made to the implementation manner shown in FIG. 7 .

Optionally, the IP push module (2016) in the AOG (20) can realize the function of IP data push (IPPUSH). For the technical solution, another solution can be adopted: that is, for the downlink message that the application server needs to send, directly establish an IP data channel, send it to the permanent online engine AOE (101) through the IP data channel, and pass the AOE (101) sent to the application client. Preferably, when the amount of downlink message data that the application server needs to send is large (for example, greater than a set threshold), an IP data channel is directly established to push downlink data; when the amount of downlink message data that the application server needs to send is relatively large Hours (for example, less than or equal to the set threshold), the long link can be woken up by SMS, and the downlink data can be pushed through the long link.

Optionally, when an internal protocol is adopted between the permanent online service gateway AOG (20) and the permanent online engine AOE (101), and an open protocol is adopted between the AOG (20) and one or more application servers, the permanent online service gateway The protocol conversion module (2017) in AOG (20) can convert messages between these two protocols.

Optionally, the upgrade management module (2018) in the AOG (20) can manage the versions of all permanent online engines AOE (101), and can trigger automatic upgrade updates of the permanent online engines.

Fig. 11 is a schematic structural diagram of an embodiment of the user management server (30) in the system. As mentioned above, the user management server (30) is located on the network side and communicates with the permanent online engine AOE (101) and the permanent online service gateway AOG (20). Links communicate with said one or more application servers (04, 05) respectively. This user management server (30) generally includes at least one processor (302) (such as CPU), at least one network interface or other communication interface (305), memory (306), and at least one communication bus (303), for realizing Connection communication between these devices. The processor (302) is used to execute executable modules, such as computer programs, stored in the memory. The user management server (30) optionally includes a user interface (304), including but not limited to a display, keyboard, and pointing device (e.g., mouse, trackball (trackball), touch pad or touch-sensitive display screen. Memory (306) may include High-speed Ram memory, may also include non-volatile memory (non-volatilememory), such as at least one disk memory. Realize this user management server (30) and at least one other computer by at least one network interface (can be wired or wireless) The communication connection between can use Internet, wide area network, local network, metropolitan area network and so on.

The memory (306) may optionally include at least one storage device (such as an external storage device) located away from the aforementioned CPU. In some embodiments, the memory (306) stores the following elements, executable modules or data structures, or a subset thereof, or an extension thereof:

The operating system (307) is used to include various programs for realizing various basic services and processing hardware-based tasks; and, one or any combination of the following modules:

Routing information module (3012), authentication information module (3013).

Specifically, the routing information module (3012), configured to provide routing information to the AOE (101), so as to request to establish the long link according to the routing information; the authentication information module (3013), configured to During the process of establishing a long link with the AOG (20), the AOE (101) provides authentication information to the AOG (20).

Preferably, it may further include a registration management module (3011), which is used to obtain and store the corresponding relationship between terminal identity information and user identity information, and store the address of the AOG (20) to which the user identity information belongs; the routing information module (3012), specifically used to: send the AOE ( 101) Provide the address of the AOG to which the user identity information belongs; the authentication information module (3013), specifically for: when the AOG (20) sends an authentication information request, according to the terminal identity information in the authentication information request , and the corresponding relationship between the terminal identity information and the user identity information acquired and stored by the registration management module, and provide the user identity information to the AOG (20). 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 the different modules mentioned, if it is not stated that they cannot be implemented together, they can be combined arbitrarily to achieve more beneficial effects, and are not limited by form. The device embodiments described above are only illustrative, and the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in One place, or it can be distributed to multiple network elements. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. It can be understood and implemented by those skilled in the art without any creative efforts.

Through the above description of the implementations, those skilled in the art can clearly understand that each implementation can be implemented by means of software plus a necessary general hardware platform, and of course also by hardware. Based on this understanding, the essence of the above technical solution or the part that contributes to the prior art can be embodied in the form of software products, and the computer software products can be stored in computer-readable storage media, such as ROM/RAM, magnetic discs, optical discs, etc., including several instructions to make a computer device (which may be a personal computer, server, or network device, etc.) execute the methods described in various embodiments or some parts of the embodiments.

The implementation methods described above do not limit the protection scope of the technical solution. Any modifications, equivalent replacements and improvements made within the spirit and principles of the above embodiments shall be included in the protection scope of the technical solution.

Claims (29)

1. A system supporting permanent online application clients, comprising: a permanent online engine AOE (101), located in a terminal (10), communicating with at least two application clients on the terminal (10), for Establish a long link with the permanent online service gateway AOG (20); The always-on service gateway AOG (20), located on the network side, is used to establish the long link with the always-on engine AOE (101), and initiate a heartbeat message, so as to maintain the long link; wherein, the at least two An application client communicates with one or more application servers (04, 05) through the long link via the AOG (20). 2. The system according to claim 1, wherein the AOG (20) is further used to adjust heartbeat intervals according to network conditions and automatically control heartbeat parameters. 3. The system of claim 1, The AOE (101) is further used to actively disconnect the long link according to its own judgment; or, The AOG (20) is further used to actively disconnect the long link according to its own judgment. 4. The system according to claim 3, the AOE (101) is further configured to enter a sleep state after the long link is disconnected. 5. The system according to claim 4, the AOG (20) is further used for: if neither the disconnection request sent by the AOE (101) is received nor the disconnection request is actively sent to the AOE (101) request, then regularly send heartbeat messages to the AOE (101) according to the heartbeat time interval, so as to maintain the long link. 6. The system according to claim 3, Wherein, the AOE (101) actively disconnects the long link according to its own judgment specifically includes: It is used to actively send a disconnection request to the AOG (20) when it is determined that other heartbeat requests have not been received after exceeding a certain time threshold after receiving the heartbeat request; or, when it detects that all application clients managed by it When the terminal is not running within a certain time threshold, it will actively initiate a disconnection request to the AOG (20); The AOG (20) sends a disconnection request; the disconnection request is used to disconnect the long link; Wherein said AOG (20) actively disconnects the long link according to its own judgment specifically includes: When it is judged that the data stream sent from the AOE (101) has not been received beyond a certain time threshold, a disconnection request is initiated; In response to (101), actively initiate a disconnection request; the disconnection request is used to disconnect the long link. 7. according to the system according to any one of claim 1-6, described AOG (20) is further used in that the AOE (101) that has disconnected described long link records on described AOG (20) whether the online status is revised as Offline, and construct an offline notification message to send to the application server. 8. The system of claim 7, The AOG (20) is further used to send a wake-up message to the AOE (101) to wake up a long link that has not yet been established or has been disconnected; The AOE (101) is further configured to monitor and intercept the wake-up message, analyze the wake-up message, and trigger the establishment of a long link. 9. A communication method supporting application clients to be permanently online, a long link is established between the always-on engine AOE (101) located in the terminal (10) and the always-on service gateway AOG (20) located on the network side, wherein , at least two application clients located in the terminal (10) respectively communicate with one or more application servers (04, 05) via the long link via the AOG (20); the method includes: the permanent The online service gateway AOG (20) initiates a heartbeat message in order to maintain the long link. 10. The method according to claim 9, further comprising: The AOG (20) adjusts the heartbeat interval according to network conditions, and automatically controls heartbeat parameters. 11. The method according to claim 9, further comprising The AOE (101) actively disconnects the long link according to its own judgment; or, The AOG (20) actively disconnects the long link according to its own judgment. 12. The method according to claim 11, further comprising, the AOE (101) enters a dormant state after the long link is disconnected. 13. The method according to claim 11, Wherein, the AOE (101) actively disconnects the long link according to its own judgment specifically includes: When the always-on engine AOE (101) judges that no other heartbeat requests have been received after receiving the heartbeat request beyond a certain time threshold, it will actively send a disconnection request to the AOG (20); or, when the When the always-online engine AOE (101) detects that all application clients managed by it are not running within a certain time threshold, it will actively initiate a disconnection request to the AOG (20); or, when the always-online engine AOE (101) 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 to disconnect the long link; The AOG (20) actively disconnecting the long link according to its own judgment includes: The AOG (20) is further used to actively initiate a disconnection request when it is determined that the data stream sent from the AOE (101) has not been received beyond a certain time threshold; when it is determined that the heartbeat request is sent beyond a certain threshold , but does not get a response from the AOE (101), actively initiate a disconnection request; the disconnection request is used to disconnect the long link. 14. The method according to any one of claims 11-13, further comprising: the AOG (20) recording the online status of the AOE (101) that has disconnected the long link on the AOG (20) It is modified to be offline, and an offline notification message is constructed and sent to the application server. 15. The method of claim 14, further comprising: The AOG (20) sends a wake-up message to the AOE (101) to wake up the long link that has not been established or has been disconnected; After the AOE (101) monitors and intercepts the wake-up message, it parses the wake-up message and triggers the establishment of a long link. 16. A terminal (10) supporting permanent online application clients, comprising: a permanent online engine AOE (101) and at least two application clients; The always-on engine AOE (101) communicates with the at least two application clients on the terminal (10), and is used to establish a long-term connection with the always-on service gateway AOG (20) on the network side. link; receive the heartbeat message initiated by the permanent online service gateway AOG (20), so as to maintain the long link; The at least two application clients are used to communicate with one or more application servers (04, 05) on the network side via the long link via the AOG (20). 17. A terminal (10) according to claim 16, The AOE (101) is further used to actively disconnect the long link according to its own judgment; or, The AOE (101) includes a link management module (1011) configured to disconnect the long link upon receipt of a disconnection request actively sent by the AOG (20). 18. The terminal (10) according to claim 17, the AOE (101) is further configured to enter a sleep state after the long link is disconnected. 19. A terminal (10) according to claim 17, Described permanent online engine AOE (101) specifically comprises: The heartbeat time module (1012) is used to actively send a disconnection request to the AOG (20) when it is determined that other heartbeat requests have not been received when a certain time threshold is exceeded after receiving the heartbeat request; or, An application management module (1012), configured to actively initiate a disconnection request to the AOG (20) when it detects that all application clients managed by it are not running within a certain time threshold; or, A battery monitoring module (1014), configured to actively send a disconnection request to the AOG (20) when detecting that the battery power on the terminal (01) is lower than a certain threshold; The disconnect request is used to disconnect the long link. 20. The terminal (10) according to any one of claims 16-19, said AOE (101) further comprising a short message processing module (1013) and a link management module (1011), said short message processing module (1013) being used for monitoring and After intercepting the wake-up short message, analyze 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 to set up a long link according to the triggering situation . 21. A permanent online service gateway AOG (20) that supports permanent online application clients, comprising: A terminal management module (2011), configured to establish a long link between the permanent online engine AOE (101) located in the terminal (10) and the AOG (20), and initiate a heartbeat message, so as to maintain the long link ; Wherein, at least two application clients on the terminal (10) respectively communicate with one or more application servers (04, 05) through the long link and via the AOG (20). 22. The AOG (20) according to claim 21, comprising: an adjustment module, configured to adjust heartbeat intervals according to network conditions, and automatically control heartbeat parameters. 23. The AOG (20) according to claim 22, the disconnection module is configured to actively disconnect the long link according to its own judgment. 24. According to the AOG (20) according to any one of claims 21-23, the terminal management module (2011) is further used for: if neither a disconnection request sent by the AOE (101) is received nor a disconnection request is actively sent to the AOE (101) Open request, then according to the heartbeat time interval, regularly send heartbeat messages to AOE (101), so as to maintain the long link. 25. AOG (20) according to claim 23, Wherein the disconnection module is specifically used for: when judging that the data flow sent from the AOE (101) has not been received beyond a certain time threshold, actively initiate a disconnection request; After the heartbeat request, but no response from the AOE (101), initiate a disconnection request; the disconnection request is used to disconnect the long link. 26. The AOG (20) according to claim 24, the terminal management module (2011) is further used to record the online status of the AOE (101) that has disconnected the long link on the AOG (20) It is modified to be offline, and an offline notification message is constructed and sent to the application server. 27. The AOG (20) according to claim 26, said AOG (20) further comprising a short message push module (2015), for sending a wake-up short message to said AOE (101), for waking up an unestablished or disconnected open long links. 28. The always-on service gateway AOG (20) according to claim 21, further comprising: An application management module (2012), configured to inquire about the permanently online application client information registered on the AOE (101), if the application client needs to interact with one or more application servers using pseudocode, then The mobile phone number of the terminal where the AOE (101) is stored on the AOG (20) is converted into a pseudocode, and the pseudocode is used for transmission between the AOG (20) and the application server as user identity information. 29. AOG (20) according to claim 28, The application management module (2012) includes: The first module is used to send the pseudo code to the application server according to the pseudo code corresponding to the mobile phone number calculated by using the mobile phone number and the random number, or, The second module is used to generate pseudocode according to the following method: pseudocode=HASH(MSISDN, Time, APPID, Random), wherein: HASH is a hash algorithm, MSISDN is a user mobile phone number, Time is a timestamp, and APPID is an application ID; Random is a random number.