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 on gateway), the always on gateway, through cooperating with the always on engine, can provide the general PUSH channel for SP, 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 on Online infrastructure), always-on infrastructure, 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, mobile communication networks (mobile telephone networks), wireless Local Area Networks (LANs), Bluetooth networks (Bluetooth personal Area networks), Ethernet networks (Ethernet LANs), token ring Local Area networks (token ring LANs), wide Area networks (wide Area networks), 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 combination PDA and mobile telephone, a PDA, an Integrated Messaging Device (IMD), a personal computer (personal computer and notebook computer), which are mobile or located on a mobile device, such as, but not limited to, a car, truck, taxi, bus, boat, airplane, bicycle, motorcycle, etc., the terminals (10) may be accessible to 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 one or more application servers include, but are not limited to, the networks described above may comprise other various different kinds of communication devices.
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 (SMS), Multimedia message Service Multimedia Service (MMS), e-mail, Instant Message Service (IMS), Bluetooth, 802.11, etc., different communication devices may use different infrared resources, including but not limited to infrared radio resources (MMS), wireless radio resources (radio), cable connection, and the like.
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: PUSH Mail, weather forecast, VOIP, advertising, location services, business office, life services, etc.
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: PUSH Mail, weather forecast, VOIP, advertising, location services, business office, life services, etc.
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. the memory (106) may include high-speed Ram memory and may also include non-volatile memory such as at least one disk memory.
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, manage information of the AOE (101) registered in the system, such as an IMSI digest, User Agent (UA) information of the AOE (101), 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 (IP PUSH), 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 the downlink message that the application server needs to send, an IP data channel is directly established, and the downlink message is sent to the always-on 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, such as at least one disk memory.
The memory (306) may optionally include at least one storage device (e.g., an external storage 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.