WO2011137792A1 - 一种推送设备间的协作方法及装置 - Google Patents

一种推送设备间的协作方法及装置 Download PDF

Info

Publication number
WO2011137792A1
WO2011137792A1 PCT/CN2011/074345 CN2011074345W WO2011137792A1 WO 2011137792 A1 WO2011137792 A1 WO 2011137792A1 CN 2011074345 W CN2011074345 W CN 2011074345W WO 2011137792 A1 WO2011137792 A1 WO 2011137792A1
Authority
WO
WIPO (PCT)
Prior art keywords
push
address
client
identifier
proxy
Prior art date
Application number
PCT/CN2011/074345
Other languages
English (en)
French (fr)
Inventor
李波杰
彭程晖
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2011137792A1 publication Critical patent/WO2011137792A1/zh
Priority to US13/753,833 priority Critical patent/US9247018B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5076—Update or notification mechanisms, e.g. DynDNS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/65—Telephone numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols

Definitions

  • the invention relates to a method and a device for collaborating between push devices.
  • the application is filed on July 30, 2010, and the application number is 201010244030.9.
  • the invention is entitled "A method and device for cooperation between push devices”. Priority is hereby incorporated by reference in its entirety.
  • the present invention relates to the field of communications technologies, and in particular, to a method and apparatus for cooperation between push devices. Background technique
  • IP Internet Protocol
  • Push technology is a technology based on the client/server mechanism, and the application server actively sends information to the client. That is, the Push transaction is initiated by the application server without the user having to log in to the application server in advance.
  • the essence of Push technology is to let information actively seek users. Therefore, its advantage lies in the initiative and timeliness of information. By using this technology, information can be pushed to user equipment as soon as possible.
  • Push Notification solution for i-phone.
  • the solution adopts the Push technology.
  • an application arrives at an application (such as receiving a new email)
  • the event is directly pushed to the client without the client being applied online at all times, or periodically to the application server. Is there a new event happening?
  • the working process of the Push Notification scheme can be summarized as follows:
  • the application server packages the application message to be sent, the destination i-phone identifier, and sends the notification message to the Push server through the Notification message; 2.
  • the Push server searches the IP address of the destination i-phone in the i-phone list of the registered Push service, and converts the Notification message into a Push message, which is sent to the destination i-phone.
  • the i-phone passes the sent Push message to the corresponding client application, and pops up the Push notification according to the settings.
  • the basis for the Push server to determine which i-phone the Push message should be sent to is a "purpose i-phone identifier". This identifier is called a device token.cca
  • the i-phone After the i-phone enters the network, it will be established with the Push server. A persistent IP connection. After the connection is established, the i-phone registers with the Push server.
  • the Push server sends the device token to the i-phone, and the i-phone sends the device token to the application server through the client application.
  • the corresponding device token is sent to the Push server together with the application message, and the Push server finds the corresponding destination i-phone according to the device token, and sends the corresponding Push message.
  • the heartbeat operation is performed every ten minutes between the Push server and the i-phone to maintain the validity of the IP connection.
  • the Push server records the IP connection during the i-phone connection establishment process. Information, IP connection information contains the address and port of the i-phone. If there is a network between the i-phone and the Push server The network address translation (NAT) records the public network address and port of the i-phone after NAT conversion.
  • NAT network address translation
  • a method and a device for cooperation between push devices are provided, which are used to improve the validity and reachability of an IP connection.
  • the embodiment of the invention provides a collaboration method between push devices, including:
  • the push proxy obtains the push identifier and the address of the push client; the push proxy saves the mapping relationship between the push identifier and the address of the push client; if the address of the push client changes, the push proxy updates the corresponding address in the mapping relationship.
  • Another method for cooperation between push devices is provided in the embodiment of the present invention, including:
  • the push proxy obtains the push identifier of the push client, the network internal identifier and the address; the push proxy saves the mapping relationship between the push identifier of the push client, the internal identifier of the network, and the address;
  • the push proxy updates the corresponding address in the mapping relationship.
  • a collaboration device between push devices including:
  • a first obtaining module configured to obtain a push identifier and an address of the push client
  • a first save module configured to save a mapping relationship between the push identifier and the address of the push client
  • a first update module configured to be used by the push client When the address changes, the corresponding address in the mapping relationship is updated.
  • Another embodiment of the present invention provides a collaboration device between push devices, including:
  • a second obtaining module configured to obtain a push identifier of the push client, a network internal identifier and an address
  • a second save module configured to save a mapping relationship between the push identifier of the push client, the internal identifier of the network, and the address; And updating, when the address of the push client changes, a corresponding address in the mapping relationship.
  • the embodiment of the invention has the following beneficial effects:
  • the Push proxy obtains the Push identifier and the address of the Push client, and saves the mapping relationship between the Push identifier and the address of the Push client.
  • the Push proxy can update the address of the Push client in time. , can improve the validity and reachability of the IP connection, thereby improving the real-time and reliability of the Push message.
  • FIG. 1 is a flowchart of a method for cooperation between push devices according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a method for obtaining a Push identifier and an address of a Push client according to an embodiment of the present invention
  • FIG. 4 and FIG. 5 are flowcharts of a Push registration method according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of a Push message forwarding method according to an embodiment of the present invention
  • FIG. 7 and FIG. 8 are flowcharts of an address update method of a Push client according to an embodiment of the present invention
  • FIG. 9 is a flowchart of a method for releasing a Push client address according to an embodiment of the present invention
  • FIG. 10 is a flowchart of a Push deregistration method according to an embodiment of the present invention
  • FIG. 13 is provided in an embodiment of the present invention
  • FIG. 14 is a flowchart of a Push registration method according to an embodiment of the present invention
  • FIG. 17 is another Push message forwarding method according to an embodiment of the present invention.
  • Flow chart of the method; 18 to FIG. 26 are structural diagrams of a cooperation device between push devices provided in an embodiment of the present invention.
  • the embodiment of the present invention deploys a Push proxy in the carrier network, and acts as a transit between the Push server and the Push client, processes signaling between the Push server and the Push client, and forwards the Push message sent by the Push server to the Push client.
  • the Push proxy can update the address of the saved Push client in time without heartbeat operation, thereby improving the validity and reachability of the IP connection of the Push client. In turn, the real-time performance and reliability of the Push message can be improved.
  • the Push server refers to a server that can provide a Push service
  • the Push client refers to a terminal that customizes a Push service when entering the network, such as a Personal Computer (PC), a mobile phone, a Personal Digital Assistant (PDA), and the like.
  • the address of the Push client can refer to either an IP address or an IP address and port.
  • the Push proxy is a logical entity, and may be located on the same device as the network side network element on the physical device, or may be independently deployed on different devices.
  • the network side network element may be a data gateway node, a Home Location Register (HLR), or a Home Subscriber Server (HSS), or an Authentication, 4 Authorization, Accounting, AAA. )server.
  • the data gateway node can be the third Gateway GPRS Support Node (GGSN) in a 3rd-Generation (3G) network, or a Packet Data Network Gateway in a Long Term Evolution (LTE) network (Packet Data Network) Gateway, PDNGW), can also be a home agent (HA) in the Worldwide Interoperability for Microwave Access (WIMAX) network or a peer entity in other networks.
  • GGSN Gateway GPRS Support Node
  • LTE Long Term Evolution
  • PDNGW Packet Data Network Gateway
  • HA home agent
  • WIMAX Worldwide Interoperability for Microwave Access
  • FIG. 1 is a flowchart of a method for cooperation between push devices according to an embodiment of the present invention. As shown in FIG. 1, the method may include the following steps:
  • the Push proxy obtains a Push identifier and an address of the Push client.
  • the address of the Push client may be an IP address of the Push client, or an IP address and a port.
  • the Push identifier of the Push client may be a device token of the Push client, or may be another parameter or identifier that may indicate the identity of the Push client.
  • the Push proxy saves the mapping relationship between the Push identifier and the address of the Push client.
  • the Push proxy can save the mapping between the Push identifier and the address of multiple Push clients.
  • the system forms a mapping table of Push identifiers and addresses. In the mapping table, the Push identifiers of each Push client are different from each other. Generally, the addresses of each Push client are different from each other.
  • the Push proxy updates the corresponding address in the mapping relationship.
  • the Push proxy can obtain the Push identifier and address of the Push client in the following two ways:
  • Manner 1 The Push agent obtains the Push ID and address of the Push client by receiving and transferring the Push registration request message of the Push client. As shown in Figure 2, the following steps can be included:
  • the Push proxy receives the Push registration request message sent by the Push client, where the Push registration request message or the data packet header carries the address of the Push client, and may also carry the address of the Push server.
  • the above data packet is a data packet of a Push registration request message.
  • the Push proxy parses the foregoing Push registration request message or its data packet header, and obtains an address of the Push client.
  • the Push proxy sends the Push registration request message to the Push server.
  • the Push proxy may write its address to the Push registration request message and send it to the Push server.
  • the Push proxy may update the address of the Push client carried in the Push registration request message to the address of the Push proxy, and implement the Push proxy address to write the Push registration request message; or the Push proxy may directly
  • the above-mentioned Push registration request message increases the address of the Push proxy, and does not affect the implementation of the embodiment of the present invention.
  • the Push proxy receives the Push registration request response message sent by the Push server, where the Push registration request response message carries the Push identifier allocated by the Push server to the Push client.
  • the Push server After receiving the Push registration request message sent by the Push proxy, the Push server sends the Push identifier to the Push client, and sends the Push identifier assigned by the Push client to the Push registration request response message through the address of the Push proxy. To the Push agent.
  • the mapping relationship between the Push identifier of the Push client and the address of the Push proxy may be saved.
  • the Push proxy parses the foregoing Push registration request response message, and obtains a Push identifier of the Push client.
  • the Push registration request message sent by the Push client received by the Push proxy in the foregoing step 201 may further carry the authentication information of the Push client, where the authentication information is used to prove the identity of the Push client to the Push server, including the certificate and the account name. , passwords, message summaries generated with key material, and more.
  • the Push proxy may further obtain the authentication information of the Push client by parsing the Push registration request message.
  • the Push server After receiving the Push registration request message sent by the Push proxy, the Push server authenticates the Push client's identity according to the authentication information of the Push client, and then assigns the Push identifier to the Push client, and the address of the Push proxy will be Push.
  • the Push identifier assigned by the client is sent to the Push proxy in the Push Registration Request Response message.
  • the Push proxy receives a proxy registration request message sent by the Push client, where the proxy registration request message or the data packet header thereof carries a Push identifier and an address of the Push client.
  • the Push proxy parses the foregoing proxy registration request message or its data packet header, and obtains a Push.
  • the Push agent obtains the Push ID and the address of the Push client through the foregoing method 2.
  • the Push client needs to register with the Push server in advance to obtain the Push identifier of the Push client.
  • the Push client registers with the Push server and obtains the Push identifier of the Push client, which is specifically:
  • the Push client sends a Push registration request message to the Push server;
  • the Push registration request message sent by the Push client or the data packet header carries the address of the Push client, and may also carry the address of the Push server.
  • the Push registration request message sent by the Push client may also carry the authentication information of the Push client, so that after receiving the Push registration request message sent by the Push client, the Push server authenticates the identity of the Push client according to the authentication information of the Push client.
  • the Push identifier assigned to the Push client may also carry the authentication information of the Push client, so that after receiving the Push registration request message sent by the Push client, the Push server authenticates the identity of the Push client according to the authentication information of the Push client.
  • the Push identifier assigned to the Push client is assigned to the Push client.
  • the Push client receives the Push registration request response message sent by the Push server, where the Push registration request response message carries the Push identifier allocated by the Push server to the Push client; optionally, the Push client sends the Step 1)
  • the Push registration request message may also carry the address of the Push proxy. After the Push server allocates the Push identifier to the Push client, the mapping relationship between the Push identifier of the Push client and the address of the Push proxy may be saved.
  • the address of the Push proxy can be configured in advance in the Push client or dynamically generated by the Push client through Dynamic Host Configuration Protocol (DHCP), i or Domain Name System (DNS). It may be that the Push client is redirected by the Push server during the process of establishing a connection or registration with the Push server.
  • DHCP Dynamic Host Configuration Protocol
  • DNS Domain Name System
  • the Push client parses the above Push registration request response message to obtain the Push client. Push logo.
  • the Push proxy updates the address of the Push client in the above mapping relationship.
  • the address change of the Push client may include two cases of address update and release:
  • the Push proxy receives an address update message sent by the network side network element, where the address update message carries the original address of the Push client sensed by the network side network element and the changed new address;
  • the network side network element may be a data gateway node, or a home location register (HLR), or a home subscriber server (HSS), or an authentication, authorization, and accounting (AAA) server.
  • HLR home location register
  • HSS home subscriber server
  • AAA authentication, authorization, and accounting
  • the Push proxy queries the mapping relationship between the Push ID and the address of the saved Push client according to the original address, and updates the corresponding address in the mapping relationship with the new address.
  • the Push agent needs to inform the network side network element in advance, and notify the Push agent in time when the network element senses that the address of the Push client changes.
  • the Push proxy sends a trigger message to the network side network element, where the trigger message carries the address of the Push client, and is used to trigger the network side network element to notify the Push agent when it senses that the address of the Push client changes.
  • the Push proxy and the network side network element may be located on the same device, and the interaction or trigger between the two is internal interaction or triggering, for example, by means of inter-process communication, function call, or the like. Interlace or trigger. That is, the Push proxy sends a trigger message through an internal trigger mechanism (such as inter-process communication, function call, etc.) to trigger the network side network element to notify the Push agent when it senses that the address of the Push client changes. If the Push proxy and the network side network element share the number According to the data, the interaction or triggering step between the two can be omitted.
  • an internal trigger mechanism such as inter-process communication, function call, etc.
  • the Push client initiates the address update of the Push client.
  • the specific process is as follows: 1) The Push proxy receives the address update message sent by the Push client, where the address update message carries the Push identifier of the Push client and the Push client senses. The new address after the change; 2) The Push proxy queries the mapping relationship between the Push identifier and the address of the saved Push client according to the Push identifier of the Push client, and updates the corresponding address in the mapping relationship with the new address.
  • the address of the Push client is released by the network side network element.
  • the specific process is as follows: 1) The Push proxy receives the address release message sent by the network side network element, where the address release message carries the Push client perceived by the network side network element. The address before release;
  • the Push proxy queries the mapping relationship between the Push ID and the address of the saved Push client according to the address, and marks the address in the mapping relationship as an unobtained or special value.
  • the special value may be represented by 0 or 1, and is used to indicate that the address of the Push client corresponding to the Push identifier has not been obtained.
  • the Push agent also needs to inform the network side network element in advance, and notify the Push agent in time when the network element of the network side senses that the address of the Push client changes.
  • the interaction or trigger between the two is internal interaction or trigger.
  • the Push proxy can use an internal trigger mechanism (such as inter-process communication, function call, etc.).
  • the trigger message is sent to trigger the network side network element to notify the Push agent when it senses that the address of the Push client changes.
  • the Push proxy receives the address release message sent by the Push client, where the address release message carries the pre-release address of the Push client; 2) The Push proxy queries the mapping relationship between the saved Push identifier and the address of the saved Push client according to the address, and marks the address in the mapping relationship as an unobtained or special value.
  • the address update operation of the Push client is started by the network side network element or the Push client, so that the Push agent can update the address of the Push client in the mapping relationship between the Push identifier and the address of the Push client in time to improve the effective IP connection. Sex and accessibility.
  • the Push proxy can forward the Push message sent by the Push server to the Push client, based on the mapping relationship between the Push identifier and the address of the Push client.
  • the specific process is as follows:
  • the Push proxy receives the Push message, and the Push message carries the Push identifier of the Push client.
  • the Push proxy obtains the address of the Push client from the mapping relationship between the Push identifier and the address of the saved Push client according to the Push identifier of the Push client;
  • the Push proxy sends a Push message to the Push client according to the address of the Push client.
  • the Push proxy can convert the Push message into a format to adapt to the interface of the Push client.
  • the Push proxy can send Push messages of different formats sent by different Push servers to the Push client in a unified format, so that the Push service is not limited to a specific Push client.
  • the Push client or the network side network element may initiate the registration process to the Push server.
  • the deregistration process can be divided into the following scenarios:
  • Scenario 1 The Push client initiates a registration process to the Push server.
  • the process is as follows:
  • the Push client sends a registration request message to the Push server, where the de-registration request message carries at least the Push identifier of the Push client, so that the Push server deletes the context related to the Push identifier of the Push client, for example, deleting the Push client.
  • the Push proxy receives the de-registration request message sent by the Push client, where the de-registration request message carries at least the Push identifier of the Push client;
  • the Push proxy sends a registration request response message to the Push client, and deletes the mapping relationship between the Push ID and the address of the saved Push client.
  • Scenario 2 The Push client initiates a registration process to the Push server. The process is as follows:
  • the Push proxy receives the de-registration request message sent by the Push client, where the de-registration request message or its data packet header carries at least the Push identifier of the Push client. Optionally, the de-registration request message or its data packet header can also be carried.
  • Push server address 2) Push proxy sends the deregistration request message to the Push server;
  • the Push proxy may convert the deregistration request message sent by the Push client into a format to adapt to the interface of the Push server.
  • the Push proxy receives the de-registration request response message sent by the Push server and sends it to the Push client, and deletes the mapping relationship between the Push ID and the address of the saved Push client.
  • Scenario 3 The network side network element initiates the registration process to the Push server. The process is as follows:
  • the Push proxy receives the deregistration request message sent by the network side network element, where the deregistration request message or the data packet header carries at least the address of the Push client;
  • the Push proxy obtains the Push identifier of the Push client from the mapping relationship between the Push identifier and the address of the saved Push client according to the address of the Push client, and writes the registration request message to the Push server, so that the Push server deletes the Push client.
  • the context of the Push identifier is related to the context of the Push proxy, for example, the mapping between the Push identifier of the Push client and the address of the Push proxy is deleted.
  • the Push proxy receives the registration request response message sent by the Push server, and deletes the mapping relationship between the saved Push identifier and the address of the saved Push client.
  • the Push proxy can save the mapping relationship between the Push identifier and the address of the Push client.
  • the Push client can be saved in time.
  • the address of the terminal is updated, so that the validity and reachability of the IP connection of the Push client can be improved, thereby improving the real-time and reliability of the Push message.
  • the Push proxy may send a Push message of a different format sent by a different Push server to a Push client in a unified format, so that the Push service is not limited to a specific Push client.
  • the Push proxy acts as a Push server and
  • the transit of the Push client can be used to complete Push registration including Push client, Push message forwarding, Push client address update or release, Push to register, Push proxy to simulate heartbeat, and Network exception notification.
  • the Push client In order to use the Push service, the Push client first needs to initiate a Push registration process to the Push server. According to whether the Push proxy transits the registration signaling, there may be the following registration modes: Mode A), Push proxy transit registration signaling, as shown in FIG. 4, the registration process may include the following steps:
  • a Transmission Control Protocol (TCP) connection can be established between the Push client and the Push proxy.
  • TCP Transmission Control Protocol
  • the address of the Push proxy can be configured in advance by the Push client or dynamically discovered by the Push client through DHCP, DNS, etc., or Push.
  • the client is redirected by the Push server when establishing a connection to the Push server.
  • the Push client sends a Push registration request message to the Push proxy, where the registration request message or the data packet header carries the address of the Push client and the address of the Push server.
  • the Push registration request sent by the Push client to the Push proxy may further carry the authentication information of the Push client.
  • the authentication information is used to prove the identity of the Push client to the Push server, and the authentication information may include, but is not limited to, a certificate, an account name, a password, a message summary generated by the key material, and the like.
  • the Push client may also send a Push registration request to the Push server, and the Push server redirects the registration request to the corresponding Push proxy.
  • the Push proxy parses the foregoing Push registration request message or its data packet header, obtains an address of the Push client, and saves the address;
  • the Push proxy may also obtain the authentication information of the Push client and save the information.
  • the Push proxy forwards the Push registration request message to the Push server according to the address of the Push server carried in the Push registration request message, where the Push proxy updates the address of the Push client carried in the Push registration request message to the Push proxy.
  • the Push proxy can also add the address of the Push proxy directly in the Push registration request message, without deleting or updating the address of the Push client, and does not affect the implementation of the embodiment of the present invention.
  • the Push proxy may convert the Push registration request to the Push server interface before forwarding the Push registration request.
  • the Push server After receiving the Push registration request message forwarded by the Push proxy, the Push server sends a Push registration request response message to the Push proxy, where the Push registration request response message carries the Push.
  • the Push server saves the mapping relationship between the Push identifier and the Push proxy address;
  • the Push server authenticates the identity of the Push client according to the authentication information of the Push client. Then, the Push identifier is allocated to the Push client, and the Push identifier assigned to the Push client is carried in the Push registration request response message and sent to the Push proxy through the address of the Push proxy.
  • the Push proxy parses the Push registration request response message sent by the Push server, and saves a mapping relationship between the Push identifier and the address of the Push client.
  • step 406 can be placed after step 407.
  • the Push proxy forwards the Push registration request response message sent by the Push server to the Push client according to the address of the Push client.
  • the Push proxy may convert the Push registration request response message sent by the Push server to the Push client interface.
  • the Push proxy sends a trigger message to the data gateway node, where the trigger message carries an address of the Push client, and is used to trigger the data gateway node to notify the Push proxy when the address of the Push client is updated or the address is released.
  • the Push proxy can also send a trigger message carrying the address of the Push client to the network element such as the data gateway node, the HLR, the HSS, and the AAA server, and is used to trigger the network side network element to exit the network (ie, deregister) when the Push client exits the network. Notify the Push agent.
  • the network element such as the data gateway node, the HLR, the HSS, and the AAA server
  • steps 406, 407 and 408 are not sequentially defined, as long as after step 405 Execute.
  • the Push proxy does not transfer the registration signaling.
  • the registration process may include the following steps:
  • the Push client sends a Push registration request message to the Push server.
  • the Push registration request message sent by the Push client or the data packet header carries at least the address of the Push client and the address of the Push server.
  • the Push registration request message sent by the Push client in the foregoing step 501 may further carry an address of the Push proxy.
  • the address of the Push proxy is configured in advance by the Push client or dynamically by the Push client through DHCP, DNS, and the like.
  • the Push server allocates a Push identifier to the Push client, and returns to the Push client.
  • Push registration request response message carries a Push identifier allocated by the Push server for the Push client
  • the Push registration request response message returned by the Push server in the step 502 to the Push client may further carry the Push proxy. address.
  • the Push proxy address is obtained by the Push server querying the local configuration table according to the address of the Push client carried in the Push registration request message in the foregoing step 501.
  • the Push server saves the mapping relationship between the Push identifier and the Push proxy address assigned by the Push client.
  • the Push registration request message sent by the Push client in the foregoing step 501 may further carry the authentication information of the Push client, so that the Push server receives the Push registration request message sent by the Push client, according to the authentication information of the Push client.
  • the identity of the authenticated Push client is legally assigned to the Push identifier of the Push client. 503.
  • the Push client After obtaining the Push identifier, the Push client sends a proxy registration request message to the Push proxy, where the proxy registration request message or the data packet header carries the Push identifier and address of the Push client.
  • the proxy registration request may also carry the authentication information of the Push client.
  • the Push proxy saves a mapping relationship between the Push identifier and the address of the Push client.
  • the Push proxy returns a proxy registration request response message to the Push client.
  • the Push proxy sends a trigger message to the data gateway node, where the trigger message carries an address of the Push client, and is used to trigger the data gateway node to notify the Push proxy when the address of the Push client is updated or released.
  • Push proxy can also send and carry to the data gateway node, HLR/HSS/AAA, and other network elements.
  • the trigger message of the address of the Push client is used to trigger the network side network element to notify the Push agent when the terminal exits the network (ie, goes to the registration).
  • steps 504, 505, and 506 are not sequentially limited, and may be performed after step 503.
  • the Push client After receiving the Push proxy registration request response, the Push client sends a registration confirmation message to the Push server.
  • the Push proxy can save the mapping relationship between the Push identifier and the address of the Push client, and then the Push proxy can forward the Push message sent by the Push server to the Push client.
  • the Push server triggers the sending of the Push message by receiving an application message sent by the application server.
  • the process of Push message forwarding is as follows:
  • the application server sends an application message to the Push server, where the application message carries Push flag of the Push client;
  • the address of the Push server and the Push identifier of the Push client may be notified by the Push server after the Push registration of the Push client is completed.
  • the Push server generates a Push message according to the application message sent by the application server, where the Push message carries the Push identifier of the Push client, and sends the Push message to the Push proxy according to the mapping relationship between the Push identifier and the Push proxy address saved in the registration process. ;
  • the Push proxy parses the Push identifier in the Push message sent by the Push server, and forwards the Push message to the Push client according to the mapping relationship between the Push identifier and the address of the saved Push client.
  • the Push proxy can convert the Push message sent by the Push server into a format to adapt
  • the Push proxy can send a Push message of a different format, which is sent by different Push servers, to the Push client, so that the Push service is not limited to a specific Push client.
  • the Push proxy converts the C2DM Push message sent by the Google C2DM server into a SIP Push message or a WAP Push message and sends it to the Push client.
  • the Push proxy can save the mapping relationship between the Push identifier and the address of the Push client, and then when the address of the Push client is updated or released, the Push proxy can update the address in the mapping relationship in time. .
  • the address update of the Push client refers to the address change of the Push client due to mobile or other network abnormalities. There are two ways to update the address of the Push client:
  • Method A) Push client initiates address update The method A) is that the Push client perceives that the address changes, and actively notifies the Push proxy. As shown in FIG. 7, the method includes the following steps:
  • the Push client senses the address change, and sends an address update message to the Push proxy, where the address update message or the data packet header carries the Push identifier and the new address of the Push client. 702.
  • the Push proxy updates the saved Push client's Push. The mapping relationship between the identifier and the address, replacing the original address with the new address;
  • the Push agent returns an update response to the Push client.
  • Method B The network side network element starts the address update of the Push client:
  • the mode B) is that the network side network element (such as the data gateway node) senses that the address of the Push client changes, and notifies the Push agent.
  • the method B) requires the network side network element (such as the data gateway node) to receive the trigger message sent by the Push agent in advance, and the trigger message is used to notify the Push agent when the network side network element senses that the address of the Push client changes.
  • the Push agent and the network side network element share data without triggering. As shown in Figure 8, the following steps are included:
  • the Push proxy queries the mapping relationship between the Push ID and the address of the saved Push client according to the original address of the Push client, and updates the address in the mapping relationship with the new address.
  • the address release of the Push client is applicable to a non-LTE network (such as a 3G network).
  • the address release of the Push client does not affect the connection between the Push client and the circuit-side (CS) domain on the network side.
  • CS circuit-side
  • the method A) requires the network side network element (such as the data gateway node) to receive the trigger message sent by the Push agent in advance, and the trigger message is used to notify the Push agent when the network side network element senses that the address of the Push client changes. If the Push proxy and the network side network element (such as a data gateway node) share data, no triggering is required. As shown in Figure 9, the following steps are included:
  • the sent address release message is sent to the Push proxy, where the address release message carries the Push perceived by the network side network element.
  • the Push proxy queries the mapping relationship between the Push identifier and the address of the saved Push client according to the address of the Push client carried in the address release message, and marks the address in the mapping relationship as an unobtained or special value.
  • Method B Push client initiates address release, including the following steps:
  • the Push client sends an address release message to the Push proxy, where the address release message carries the address of the Push client;
  • Push proxy updates the mapping relationship between the Push ID and the address of the saved Push client, and marks the address of the Push client in the mapping relationship as an unobtained or special value.
  • Process 4 Push client's Push to register:
  • the Push proxy can save the mapping relationship between the Push identifier and the address of the Push client. If the Push client does not need the Push service or the network is disconnected, the Push client or the network side network element can initiate the registration process to the Push server. Among them, consider Mode A) The Push client initiates the Push-to-registration process, and the Push proxy transfers the registration signaling. As shown in FIG. 10, the Push-to-registration process of the mode A) may include the following steps:
  • the Push client sends a registration request message to the Push proxy, where the de-registration request message or the data packet header carries the Push identifier of the Push client; optionally, the address of the Push server;
  • the Push proxy sends a registration request message to the Push server.
  • the Push proxy can convert the de-registration request message sent by the Push client to the interface of the Push server, so that the Push client can interact with different Push servers, so that the Push service is not limited to a specific Push client. end.
  • the Push server returns a registration request response message to the Push proxy.
  • the Push proxy forwards the registration request response message to the Push client, and deletes the mapping relationship between the Push identifier and the address of the saved Push client.
  • the Push proxy can convert the de-registration request response message returned by the Push server to the interface of the Push client, so that different Push servers can interact with the Push client, so that the Push service is not limited to a specific Push server. .
  • the Push client initiates the Push registration process, and the Push proxy does not transfer the registration signaling.
  • the Push registration process of the mode B) may include the following steps:
  • the Push client sends a registration request message to the Push server, where the de-registration request message carries the Push identifier of the Push client, so that the Push server deletes the context related to the Push identifier of the Push client, for example, deleting the Push of the Push client.
  • the Push client sends a registration request message to the Push proxy, where the registration is required.
  • the message carries the Push identifier of the Push client;
  • the Push proxy sends a registration request response message to the Push client, and deletes the mapping relationship between the Push identifier and the address of the saved Push client.
  • Method C The network side network element initiates a Push to register process
  • the mode C) requires the network side network element (such as the data gateway node) to receive the trigger message sent by the Push agent in advance, and the trigger message is used to notify the Push agent when the network side network element senses that the Push client exits the network. If the Push proxy and the network side network element (such as a data gateway node) share data, no triggering is required.
  • the Push deregistration process of mode C) may include the following steps:
  • the network side network element discovers that when the Push client exits the network, sending a registration request message to the Push proxy, where the deregistration request message carries the address of the Push client;
  • the Push proxy obtains the Push identifier of the Push client from the mapping relationship between the Push identifier and the address of the saved Push client according to the address of the Push client, and writes the registration request message to the Push server, so that the Push server deletes the Push client.
  • the context of the Push identifier is related to the context of the Push proxy, for example, the mapping between the Push identifier of the Push client and the address of the Push proxy is deleted.
  • the Push server returns a registration request response message to the Push proxy, and the Push proxy deletes the mapping relationship between the Push identifier and the address of the Push client.
  • the Push proxy may also delete the authentication information according to the Push client.
  • Push agent simulates heartbeat
  • the Push Agent can simulate that the Push client periodically sends a heartbeat to the Push server to conform to the existing mechanism of the Push server.
  • Process 6 network exception notification:
  • the Push proxy When the Push proxy receives the Push message sent by the Push server to the Push client, if it finds that the Push client corresponding to the Push identifier in the Push message is located in a busy or abnormal network area, it returns a busy or abnormal response to the Push server, so as to facilitate The Push server handles it accordingly.
  • the Push proxy can interact with the data gateway node to obtain a network area identifier corresponding to the address of the Push client, and the network area identifier can be a network element address of the data gateway node connected to the SGSN or GW.
  • the Push agent interacts with the network status database according to the network area identifiers to obtain the status of the free/busy/abnormal status of the network areas, which may be a periodic acquisition status, or an event-triggered network status database reporting to the Push agent.
  • the Push proxy can save the mapping relationship between the Push identifier and the address of the Push client.
  • the address of the Push client changes, no heartbeat is needed.
  • the operation can update the address of the saved Push client in time, thereby improving the validity and reachability of the IP connection of the Push client, thereby improving the real-time and reliability of the Push message.
  • eliminating the heartbeat between the Push client and the Push server can save Push client energy and network side resources. Because, in the wireless network, the Push client needs to intermittently perform the idle state and the active state to transmit the heartbeat packet.
  • FIG. 13 is a flowchart of another method for cooperation between push devices according to an embodiment of the present invention. As shown in FIG. 13, the method may include the following steps:
  • the Push client address is an IP address of the Push client, or an IP address and a port.
  • the internal identifier of the network of the Push client includes, but is not limited to, the International Mobile Subscriber Identity (IMSI) of the Push client, the Mobile Station ISDN (MSISDN), and the Network Access Identifier. , NAI) and so on.
  • IMSI International Mobile Subscriber Identity
  • MSISDN Mobile Station ISDN
  • NAI Network Access Identifier
  • the Push proxy saves a mapping relationship between a Push identifier of the Push client, an internal identifier of the network, and an address;
  • the Push proxy updates the corresponding address in the mapping relationship.
  • the Push proxy obtains the push Push identifier of the Push client, the internal identifier of the network, and the address, which can be used in the following manner:
  • the Push proxy receives the Push registration request message sent by the Push client, where the Push registration request message or the data packet header carries the address of the Push client, and may also carry the address of the Push server;
  • the Push proxy parses the above-mentioned Push registration request message or its data packet header, obtains the address of the Push client, and queries the network side network element for the corresponding network internal identifier according to the obtained Push client address, and the network side network element is the data gateway.
  • the Push proxy sends a Push registration request message to the Push server
  • the Push proxy receives the Push registration request response message sent by the Push server, where the Push registration request response message carries the Push identifier allocated by the Push server for the Push client; 5) The Push proxy resolves the Push registration request response message to obtain the Push The Push ID of the client.
  • the Push proxy receives the Push registration request message sent by the Push client, and the Push registration request message or the data packet header carries the Push identifier of the Push client, the network internal identifier, and the address; 2) The Push proxy resolves the Push registration request or the Push register The packet header obtains the Push identifier, network internal identifier, and address of the Push client.
  • the Push proxy receives the notification of the Push client incoming network sent by the network side network element, and the Push client incoming network notification carries the address of the Push client and the internal identifier of the network;
  • the network side network element is a data gateway node, or a home location register HLR, or Home subscriber server HSS, or authentication, authorization, and accounting AAA server;
  • the Push proxy obtains the Push client authentication information and the Push server address according to the internal identifier of the network or sends the Push client authentication information to the Push server, and sends a Push registration request message to the Push server;
  • the Push proxy receives the Push registration request response message sent by the Push server, where the Push registration request response message carries a Push identifier allocated by the Push server for the Push client;
  • the Push proxy parses the Push registration request response message to obtain the Push identifier of the Push client.
  • the Push proxy may update the address in the mapping relationship as follows:
  • the Push proxy receives the address update message sent by the network side network element, where the address update message carries the internal identifier of the Push client and the changed new address of the Push client perceived by the network side network element;
  • the network side network element is a data gateway node, or a home location register (HLR), or a home subscriber server (HSS), or an authentication, authorization, and accounting (AAA) server.
  • HLR home location register
  • HSS home subscriber server
  • AAA authentication, authorization, and accounting
  • the Push proxy searches for the mapping relationship between the Push identifier of the Push client, the internal identifier of the network, and the address according to the internal identifier of the network, and updates the corresponding address in the mapping relationship with the new address.
  • the Push proxy can save the mapping relationship between the Push identifier of the Push client, the internal identifier of the network, and the address, in the Push client.
  • the address of the terminal changes, the address of the saved Push client can be updated in time without a heartbeat operation, thereby improving the validity and reachability of the IP connection of the Push client, thereby improving the real-time and reliable Push message.
  • Embodiment 4
  • the Push proxy is used as the transit between the Push server and the Push client, and the Push internal registration of the Push client, the Push message forwarding, the Push client address update, or the Push client address update may be completed. Release, Push to register, Push proxy to simulate heartbeat and network exception notification, etc., to enrich the function of Push proxy.
  • Push proxy transit registration signaling as shown in Figure 14, the registration process may include the following steps:
  • step 1401 is the same as step 401 in the second embodiment
  • the Push client sends a Push registration request message to the Push proxy, where the registration request message or the data packet header carries the address of the Push client, the internal identifier of the network, and the address of the Push server, where the internal identifier of the network is optional.
  • the Push proxy parses the foregoing Push registration request message or its data packet header, obtains an address of the Push client and an internal identifier of the network, and saves the identifier;
  • the Push proxy sends a Push registration request message to the Push server according to the address of the Push server.
  • Push server before this, if the original Push registration request message carries the internal identifier of the network, the internal identifier of the network is deleted;
  • the Push server After receiving the Push registration request message forwarded by the Push proxy, the Push server sends a Push registration request response message to the Push proxy, where the Push registration request response message carries the Push identifier allocated by the Push server for the Push client. At the same time, the Push server saves the mapping relationship between the Push identifier and the Push proxy address;
  • the Push proxy If the Push proxy has not obtained the internal identifier of the network of the Push client, perform a network internal identifier query interaction with the data gateway node. During the interaction, the Push proxy sends the address of the Push client to the data gateway node, and the data gateway node returns the corresponding network internal. Identification
  • step 1406 may be omitted.
  • the Push proxy parses the Push registration request response message sent by the Push server, and saves Push mapping of the Push client, the internal identifier of the network, and the mapping relationship between the addresses;
  • the Push proxy forwards the Push registration request response message sent by the Push server to the Push client according to the address of the Push client.
  • the Push proxy sends a trigger message to the data gateway node, where the trigger message carries a network internal identifier of the Push client, and is used to trigger the data gateway node to notify the Push proxy when the address of the Push client is updated or released.
  • the Push proxy may also send a trigger message carrying the internal identifier of the network of the Push client to the data gateway node, the HLR/HSS/AAA, and the like, for triggering the network side network elements to exit the network (ie, registering) on the Push client. Notify the Push agent.
  • Push Pro does not transfer registration signaling, as shown in Figure 15, the registration process can include the following steps:
  • step 1501 is the same as step 501 in the second embodiment
  • step 1502 is the same as step 502 in the second embodiment
  • the Push client After receiving the Push identifier, the Push client sends a proxy registration request message to the Push proxy, where the proxy registration request message or the data packet header carries the Push identifier of the Push client, the network internal identifier and the address, where the internal identifier of the network is Choose to carry;
  • the network gateway identifies the interaction with the data gateway node. During the interaction, the Push proxy sends the address of the Push client to the data gateway node, and the data gateway node returns the corresponding network internal. Identification
  • step 1504 may be omitted.
  • the Push proxy saves the Push identifier of the Push client, the internal identifier of the network, and the mapping of the address. Shooting relationship
  • the Push proxy returns a proxy registration request response message to the Push client.
  • the Push proxy sends a trigger message to the data gateway node, where the trigger message carries a network internal identifier of the Push client, and is used to trigger the data gateway node to notify the Push proxy when the address of the Push client is updated or released.
  • the Push proxy may also send a trigger message carrying the internal identifier of the network of the Push client to the network element such as the data gateway node and the HLR/HSS/AAA, and is used to trigger the network side network element to notify when the terminal exits the network (ie, deregisters).
  • the network element such as the data gateway node and the HLR/HSS/AAA, and is used to trigger the network side network element to notify when the terminal exits the network (ie, deregisters).
  • the network element such as the data gateway node and the HLR/HSS/AAA
  • the Push agent initiates Push registration, as shown in FIG. 16, the registration process may include the following steps:
  • the Push client accesses the network, and the data gateway node allocates an address for the Push client, and sends a Push client network notification to the Push proxy, where the notification carries the internal identifier and address of the Push client;
  • the address of the Push proxy can be configured in the data gateway node in advance.
  • a TCP connection can be established between the Push client and the Push proxy.
  • the network internal identifier query interaction is performed to the data gateway node.
  • the Push proxy sends the address of the Push client to the data gateway node, and the data gateway node returns the corresponding network internal.
  • step 1603 may be omitted.
  • the Push agent learns that the Push client accesses the network or the Push client and the Push proxy are established. After the connection, the local query is obtained according to the obtained internal identifier of the network or the address of the Push server is obtained from the user information database, and a Push registration request message is sent to the Push server;
  • the Push registration request message sent by the Push proxy may also carry the authentication information of the Push client.
  • the Push server After receiving the Push registration request message sent by the Push proxy, the Push server sends the message.
  • a Push registration request response message is sent to the Push proxy, where the Push registration request response message carries a Push identifier allocated by the Push server to the Push client;
  • the Push server first authenticates the Push client identity and then sends the Push registration request carrying the Push identifier.
  • the response message is sent to the Push agent.
  • the Push proxy saves the mapping relationship between the Push identifier of the Push client, the internal identifier of the network, and the address.
  • the Push proxy forwards the Push registration request response message to the Push client.
  • Push message forwarding As shown in Figure 17, the process of Push message forwarding is as follows:
  • step 1701 is the same as step 601 described above;
  • step 1702 is the same as step 602 described above;
  • the Push proxy converts the Push message into a Short Messaging Service (SMS) message or a Wireless Application Protocol (WLAN) Push message, and sends the message to the Short Message Service Center (SMSC) or a WAP Push proxy gateway, where the SMS message or the WAP Push message carries an internal identifier of the network corresponding to the Push identifier; The address of the SMSC or WAP proxy gateway is pre-configured in the Push proxy.
  • SMS Short Messaging Service
  • WLAN Wireless Application Protocol
  • the 1704, SMSC or WAP proxy gateway sends an SMS message or a WAP Push message to the Push client.
  • the Push proxy can save the Push client.
  • the Push proxy can update the address in the mapping relationship in time.
  • the method A) is that the Push client perceives that the address changes, and actively notifies the Push agent, and the specific process is:
  • the address update message is sent to the Push proxy, where the address update message carries the Push client Push identifier, the network internal identifier, and the new address; 2)
  • the Push proxy updates the saved Push identifier, the network. The mapping between the internal identifier and the address, replacing the original address with the new address;
  • Method B The network side network element starts the address update of the Push client:
  • the mode B) is that the network side network element (such as the data gateway node) perceives that the address of the Push client changes, and notifies the Push agent.
  • the method B) requires the network side network element (such as the data gateway node) to receive the trigger message sent by the Push proxy in advance, and the trigger message is used to notify the Push proxy when the network side network element senses that the address of the Push client changes. If the Push proxy and the network side network element (such as a data gateway node) share data, no triggering is required.
  • the specific process is: After the network side network element senses the address change of the Push client, the network update message is sent to the Push proxy, where the address update message carries the network internal identifier of the Push client that is perceived by the network side network element and the changed new address;
  • the Push proxy queries the mapping of the Push identity, the network internal identifier and the address of the saved Push client according to the internal identifier of the Push client, and updates the address in the relationship between the new address update.
  • the address release of the Push client does not affect the connection between the Push client and the CS domain on the network side.
  • the address of the Push client is released as:
  • the network side network element senses that all the PDPs of the Push client are released or the addresses are released, and the sent address release message is sent to the Push agent, where the address release message carries the network internal identifier of the Push client perceived by the network side network element;
  • the Push proxy queries the saved internal identifier of the Push client, the internal identifier of the network, and the address according to the internal identifier of the Push client carried in the address release message, and marks the address in the mapping relationship as not acquired or a special value.
  • the Push client sends a registration request message to the Push proxy, where the deregistration request message or the data packet header carries the internal identifier of the Push client and the address of the Push server;
  • the Push proxy sends a registration request to the Push server according to the address of the Push request message or the Push server carried in the data packet header;
  • the Push proxy can convert the de-registration request message sent by the Push client to the interface of the Push server, so that the Push client can interact with different Push servers, so that the Push service is not limited to a specific Push client. end.
  • the Push server returns a registration request response message to the Push agent
  • the Push proxy forwards the registration request response message to the Push client, and deletes the mapping relationship between the saved Push client's Push identifier, the network internal identifier, and the address.
  • the Push proxy can convert the de-registration request response message returned by the Push server to the interface of the Push client, so that different Push servers can interact with the Push client, so that the Push service is not limited to a specific Push server. .
  • the Push proxy can save the mapping relationship between the internal identifier and the address of the Push logo network of the Push client.
  • the address of the saved Push client can be updated in time without the heartbeat operation, which can improve the validity and reachability of the IP connection of the Push client, thereby improving the real-time and reliability of the Push message.
  • eliminating the heartbeat between the Push client and the Push server can save Push client energy and network side resources.
  • the Push proxy may send a Push message of a different format sent by a different Push server to a Push client in a unified format, so that the Push service is not limited to a specific Push client.
  • FIG. 18 is a structural diagram of a collaboration device between push devices according to an embodiment of the present invention, which is used to implement the functions of the Push proxy in the first embodiment and the second embodiment.
  • the collaboration device can include:
  • the first obtaining module 1801 is configured to obtain a Push identifier and an address of the Push client, where the first saving module 1802 is configured to save a mapping relationship between the Push identifier and the address of the Push client.
  • the first update module 1803 is configured to update a corresponding address in the mapping relationship when the address of the Push client changes.
  • the address of the Push client may be an IP address of the Push client, or an IP address and a port.
  • FIG. 19 is a structural diagram of another cooperation device between push devices according to an embodiment of the present invention.
  • the collaboration device shown in FIG. 19 is optimized for the collaboration device shown in FIG. 18, where the first acquisition module 1801 may include:
  • the first receiving unit 18011 is configured to receive a Push registration request message sent by the Push client, where the Push registration request message or the data packet header thereof carries an address of the Push client; optionally, the address of the Push server may also be carried;
  • the first parsing unit 18012 is configured to parse the Push registration request message or the data packet header thereof, and obtain an address of the Push client.
  • the first sending unit 18013 is configured to send the foregoing Push registration request message to the Push server.
  • the first receiving unit 18011 is further configured to receive a Push registration request response message sent by the Push server, where the Push registration request response message carries a Push identifier allocated by the Push server to the Push client.
  • the first parsing unit 18012 is further configured to parse the Push registration request response message. Obtain the Push ID of the Push client.
  • the first saving module 1802 can be used to save the mapping relationship between the Push identifier and the address of the Push client obtained by the first parsing unit 18012.
  • FIG. 20 is a structural diagram of another cooperation device between push devices according to an embodiment of the present invention.
  • the collaboration device shown in FIG. 20 is optimized for the collaboration device shown in FIG. 18, where the first acquisition module 1801 may include:
  • the second receiving unit 18014 is configured to receive a proxy registration request message sent by the Push client, where the proxy registration request message or the data packet header carries a Push identifier and an address of the Push client;
  • the second parsing unit 18015 is configured to parse the proxy registration request message or the data packet header thereof, and obtain a Push identifier and an address of the Push client.
  • the first saving module 1802 can be used to save the mapping relationship between the Push identifier and the address of the Push client obtained by the second parsing unit 18015.
  • FIG. 21 is a structural diagram of another cooperation device between push devices according to an embodiment of the present invention.
  • the collaboration device shown in FIG. 21 is optimized for the collaboration device shown in FIG. 18, wherein the first update module 1803 can include:
  • the first processing unit 18031 is configured to receive an address update message sent by the network side network element, where the address update message carries the original address of the Push client that is perceived by the network side network element and the changed new address.
  • the network side network The element is a data gateway node, or an HLR, or HSS, or AAA server.
  • the second processing unit 18032 is configured to query, according to the original address of the Push client, the mapping relationship between the saved Push identifier and the address of the saved Push client, and update the new address to update the corresponding address in the mapping relationship. That is, the new address is updated to the original address of the Push client.
  • the second processing unit 18032 is specifically configured to query, according to the original address of the Push client, the mapping relationship between the Push identifier and the address of the Push client saved by the first saving module 1802, and update the corresponding address in the mapping relationship.
  • the structure of the first obtaining module 1801 may be the same as that of the first acquiring module 1801 in FIG. 19 or FIG. 20, which is not limited in this embodiment.
  • the second processing unit 18032 is further configured to send a trigger message to the network side network element, where the trigger message carries an address of the Push client, and is used to trigger the network side network element to perceive Push.
  • the first processing unit 18031 is notified when the address of the client changes.
  • FIG. 22 is a structural diagram of another cooperation device between push devices according to an embodiment of the present invention.
  • the collaboration device shown in FIG. 22 is optimized for the collaboration device shown in FIG. 18, wherein the first update module 1803 can include:
  • the third processing unit 18033 is configured to receive an address update message sent by the Push client, where the address update message carries a Push identifier of the Push client and a changed new address perceived by the Push client.
  • the fourth processing unit 18034 is configured to query, according to the Push identifier of the Push client, the mapping relationship between the Push identifier and the address of the Push client saved by the first save module 1802, and update the new address to the corresponding address in the mapping relationship.
  • the structure of the first obtaining module 1801 may be the same as that of the first acquiring module 1801 in FIG. 19 or FIG. 20, which is not limited in this embodiment.
  • FIG. 23 is a structural diagram of another cooperation device between push devices according to an embodiment of the present invention.
  • the collaboration device shown in FIG. 23 is optimized by the collaboration device shown in FIG. 18, and the collaboration device includes a first acquisition module 1801, a first storage module 1802, and a In addition to the update module 1803, the method further includes:
  • the first control module 1804 is configured to receive, by the Push server, a Push message, where the Push message carries a Push identifier of the Push client.
  • the second control module 1805 is configured to obtain the address of the Push client from the mapping relationship between the Push identifier and the address of the Push client saved by the first saving module 1802 according to the Push identifier of the Push client, and notify the first control module 1804;
  • the first control module 1804 is further configured to send the Push message sent by the Push server to the Push client according to the address of the Push client notified by the second control module 1805.
  • the first control module 1804 may first convert the Push message to the interface of the Push client, so that the Push service is not limited to a specific Push client. .
  • the structure of the first obtaining module 1801 may be the same as the structure of the first obtaining module 1801 in FIG. 19 or FIG. 20, and the structure of the first updating module 1803 may be the same as FIG. 21 or The structure of the first update module 1803 in FIG. 22 is the same, and is not limited in this embodiment.
  • the third control module 1806 is configured to receive an address release message sent by the network side network element, where the address release message carries a pre-release address of the Push client that is perceived by the network side network element;
  • the network side network element is a data gateway node, or an HLR, or an HSS, or an AAA server.
  • the fourth control module 1807 is configured to query, according to the address, the mapping relationship between the Push identifier and the address of the Push client saved by the first saving module 1802, and mark the corresponding address in the mapping relationship as an unobtained or special value.
  • the third control module 1806 is further configured to receive a de-registration request message sent by the Push client, where the de-registration request message carries at least the Push client. Push logo;
  • the fourth control module 1807 is further configured to send a de-registration request response message to the Push client, and delete the mapping relationship between the Push identifier and the address of the Push client saved by the first saving module 1802.
  • the third control module 1806 is further configured to receive
  • the de-registration request message sent by the Push client where the de-registration request message carries at least the Push identifier of the Push client; optionally, the address of the Push server;
  • the fourth control module 1807 is further configured to send the de-registration request message to the Push server; receive the de-registration request response message sent by the Push server, send the message to the Push client, and delete the Push client saved by the first save module 1802.
  • the first save module 1802 can save the mapping relationship between the Push identifier and the address of the Push client, and the first update module 1803 does not need a heartbeat operation when the address of the Push client changes.
  • the address of the saved Push client can be updated in a timely manner, thereby improving the validity and reachability of the IP connection of the Push client, thereby improving the real-time and reliability of the Push message.
  • eliminating the heartbeat between the Push client and the Push server can save Push client energy and network side resources.
  • the collaboration device may send a Push message of a different format sent by different Push servers to a Push client in a unified format, so that the Push service is not limited to a specific Push client.
  • Example 6 Example 6:
  • FIG. 24 is a structural diagram of another apparatus for cooperation between push devices according to an embodiment of the present invention, which is used to implement the functions of the Push Agent in the third embodiment and the fourth embodiment.
  • the collaboration device can include:
  • the second obtaining module 2401 is configured to obtain a Push identifier, a network internal identifier, and an address of the Push client.
  • the second saving module 2402 is configured to save a mapping relationship between the Push identifier, the network internal identifier, and the address of the Push client.
  • the second update module 2403 is configured to update a corresponding address in the mapping relationship when the address of the Push client is changed.
  • FIG. 25 is a structural diagram of another cooperation device between push devices according to an embodiment of the present invention.
  • the collaboration device shown in FIG. 25 is optimized for the collaboration device shown in FIG. 24, wherein the second acquisition module 2401 may include:
  • the third receiving unit 24011 is configured to receive a Push registration request message sent by the Push client, where the Push registration request message or the data packet header thereof carries an address of the Push client; optionally, the address of the Push server may also be carried;
  • the third parsing unit 24012 is configured to parse the foregoing Push registration request message or the data packet header thereof, obtain the address of the Push client, and query the network side network element to obtain the network internal identifier of the Push client according to the address of the Push client, where the network side network element a data gateway node, or a home location register HLR, or a home subscriber server HSS, or an authentication, authorization, and accounting AAA server;
  • the third sending unit 24013 is configured to send a Push registration request message to the Push server.
  • the third receiving unit 24011 is further configured to receive a Push registration request response message sent by the Push server, where the Push registration request response message carries the Push server as Push identifier assigned by the Push client;
  • the third parsing unit 24012 is further configured to parse the Push registration request response message. Obtain the Push ID of the Push client.
  • FIG. 26 is a structural diagram of another cooperation device between push devices according to an embodiment of the present invention.
  • the collaboration device shown in FIG. 26 is optimized for the collaboration device shown in FIG. 24, wherein the second update module 2403 may include:
  • the fifth processing unit 24031 is configured to receive an address update message sent by the network side network element, where the address update message carries a network internal identifier of the Push client and a changed new address of the Push client perceived by the network side network element;
  • the network side network element is a data gateway node, or an HLR, or an HSS, or an AAA server.
  • the sixth processing unit 24032 is configured to query, according to the network internal identifier, the mapping relationship between the Push identifier, the network internal identifier, and the address of the Push client saved by the second saving module 2402, and update the corresponding address in the mapping relationship with the new address.
  • the structure of the second obtaining module 2401 may be the same as that of the second obtaining module 2401 in FIG. 25, which is not limited in this embodiment.
  • the collaboration apparatus provided in this embodiment may further include:
  • the fifth control module 2404 is configured to receive, by the Push server, a Push message, where the Push message carries a Push identifier of the Push client.
  • the sixth control module 2405 obtains the network internal identifier of the Push client from the mapping relationship between the Push identifier of the Push client, the internal identifier of the network, and the address saved by the second save module 2402 according to the Push identifier of the Push client; and converts the Push message.
  • the SMS message or the WAP Push message is sent to the SMSC or the WAP Push proxy gateway, where the converted message carries the network internal identifier corresponding to the Push identifier.
  • the second save module 2402 can save When the address of the Push client is changed, the second update module 2403 can update the address of the saved Push client in time without the heartbeat operation when the address of the Push client changes. It can improve the validity and reachability of the IP connection of the Push client, and thus improve the real-time and reliability of the Push message. In addition, eliminating the heartbeat between the Push client and the Push server can save Push client energy and network side resources.
  • the foregoing program may be stored in a computer readable storage medium, and the program is executed when executed.
  • the foregoing storage medium includes the following: The storage medium includes: a read only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

一种推送设备间的协作方法及装置 本申请要求于 2010 年 7 月 30 日提交中国专利局， 申请号为 201010244030.9, 发明名称为"一种推送设备间的协作方法及装置 "的中国专利 申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及通信技术领域， 具体涉及一种推送设备间的协作方法及装置。 背景技术
在客户端 /服务器模式中， 除非用户登录应用服务器并向应用服务器提供 其网际协议（ Internet Protocol , IP )地址， 否则应用服务器无法主动找到用户 终端并向之发送信息。 由此， 推送（Push )技术应运而生。
Push技术是一种基于客户端 /服务器机制、 由应用服务器主动将信息发往 客户端的技术， 即 Push事务是由应用服务器发起的， 而无须用户事先登录应 用服务器。 Push技术的本质在于让信息去主动的寻找用户， 因此其优势在于 信息的主动性和及时性，通过使用该技术，可以尽快的将信息推送到用户设备。
目前， 苹果公司 ( Apple, Inc )推出了 Push通知 ( Notification )方案， 应 用于 i-phone。 该方案釆取 Push技术， 当用户某一应用有事件到达时（如收到 新的邮件）， 直接将该事件推送给客户端， 而无需客户端时时刻刻应用在线， 或者定时去应用服务器查看是否有新的事件发生。 其中， Push Notification方 案的工作过程可以概括为：
1、 应用服务器把要发送的应用消息、 目的 i-phone 标识打包并通过 Notification消息发给 Push服务器； 2、 Push服务器在已注册 Push服务的 i-phone列表中， 查找目的 i-phone 的 IP地址， 并将 Notification消息转换成 Push消息， 将发到目的 i-phone。
3、 目的 i-phone把发来的 Push消息传递给相应的客户端应用程序， 并且 按照设定弹出 Push通知。 其中， Push服务器判断 Push消息应该发送给哪一个 i-phone的依据是一 个 "目的 i-phone标识"， 这个标识称为设备令牌 ( device token )„ 在 i-phone 入网后会与 Push服务器建立持久的 IP连接， 连接建立后， i-phone向 Push服 务器注册， Push服务器会把设备令牌发送给 i-phone, i-phone通过客户端应用 程序再把这个设备令牌发给应用服务器。 后续， 应用服务器若需要向 i-phone 发送应用消息， 就会把对应的设备令牌和应用消息一起发送给 Push服务器， 而 Push服务器再依据设备令牌找到相应的目的 i-phone, 并发送相应的 Push 消息。 当没有数据传递时， Push服务器和 i-phone之间每隔十几分钟进行一次心 跳操作， 以维持 IP连接的有效性。 其中， Push服务器在 i-phone连接建立过 程中记录 IP连接信息， IP连接信息中包含 i-phone的地址和端口。如果 i-phone 和 Push服务器之间存在网络地址转换（ Network Address Translation, NAT ), 则 Push服务器记录的是 i-phone经过 NAT转换之后的公网地址和端口。 上述的方案无法保证 IP连接的有效性和可达性，从而导致 Push消息推送 失败或串到其他终端， 影响 Push消息的实时性和可靠性。
发明内容
本发明实施例中提供了一种推送设备间的协作方法及装置， 用于提高 IP 连接的有效性和可达性。 本发明实施例中提供了一种推送设备间的协作方法， 包括：
推送代理获取推送客户端的推送标识和地址； 推送代理保存所述推送客户端的推送标识和地址的映射关系； 若所述推送客户端的地址发生变化，则推送代理更新所述映射关系中对应 的地址。
本发明实施例中提供了另一种推送设备间的协作方法， 包括：
推送代理获取推送客户端的推送标识、 网络内部标识和地址； 推送代理保存所述推送客户端的推送标识、网络内部标识和地址的映射关 系；
若所述推送客户端的地址发生变化，则推送代理更新所述映射关系中对应 的地址。
本发明实施例中提供了一种推送设备间的协作装置， 包括：
第一获取模块， 用于获取推送客户端的推送标识和地址； 第一保存模块， 用于保存所述推送客户端的推送标识和地址的映射关系； 第一更新模块， 用于在所述推送客户端的地址发生变化时， 更新所述映射 关系中对应的地址。
本发明实施例中提供了另一种推送设备间的协作装置， 包括：
第二获取模块， 用于获取推送客户端的推送标识、 网络内部标识和地址； 第二保存模块， 用于保存所述推送客户端的推送标识、 网络内部标识和地 址的映射关系； 第二更新模块， 用于在所述推送客户端的地址发生变化时， 更新所述映射 关系中对应的地址。
与现有的技术相比， 本发明实施例具有以下有益效果： 本发明实施例中， 由 Push代理获取 Push客户端的 Push标识和地址， 并 保存 Push客户端的 Push标识和地址的映射关系， 在 Push客户端的地址发生 变化时， Push代理可以及时地更新 Push客户端的地址， 能够提高 IP连接的有 效性和可达性， 从而能够提高 Push消息的实时性和可靠性。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要 使用的附图作简单地介绍，显而易见地， 下面描述中的附图仅仅是本发明的一 些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动的前提下， 还 可以根据这些附图获得其他的附图。
图 1为本发明实施例中提供的一种推送设备间的协作方法流程图； 图 2、 图 3为本发明实施例中提供的获取 Push客户端的 Push标识和地址 的方法的流程图；
图 4、 图 5为本发明实施例中提供的 Push注册方法的流程图；
图 6为本发明实施例中提供的一种 Push消息转发方法的流程图； 图 7、 图 8为本发明实施例中提供的 Push客户端的地址更新方法的流程 图；
图 9为本发明实施例中提供的 Push客户端的地址释放方法的流程图； 图 10〜图 12为本发明实施例中提供的 Push去注册方法的流程图； 图 13为本发明实施例中提供的另一种推送设备间的协作方法的流程图； 图 14〜图 16为本发明实施例中提供的 Push注册方法的流程图； 图 17为本发明实施例中提供的另一种 Push消息转发方法的流程图； 图 18〜图 26为本发明实施例中提供的推送设备间的协作装置的结构图。
具体实施方式
下面将结合本发明实施例中的附图 ,对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是 全部的实施例。基于本发明中的实施例， 本领域普通技术人员在没有作出创造 性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
本发明实施例在运营商网络中部署 Push代理， 作为 Push服务器和 Push 客户端的中转， 处理 Push服务器和 Push客户端之间的信令， 并将 Push服务 器发送的 Push消息转发给 Push客户端。 与此同时， Push代理可以在 Push客 户端的地址发生变化时， 无需心跳操作即可及时地对其保存的 Push客户端的 地址进行更新， 从而能够提高 Push客户端的 IP连接的有效性和可达性， 进而 能够提高 Push消息的实时性和可靠性。
其中， Push服务器是指能够提供 Push业务的服务器； Push客户端是指入 网时定制 Push业务的终端， 例如个人计算机 ( Personal Computer, PC )、 移动 手机、 掌上电脑（ Personal Digital Assistant, PDA )等等。 Push客户端的地址 既可以指 IP地址， 也可以指 IP地址和端口。
其中， Push代理是逻辑实体， 在物理设备上可以与网络侧网元位于同一 设备， 也可以独立地部署在不同的设备。 其中， 网络侧网元可以是数据网关节 点、归属位置寄存器（ Home Location Register, HLR ),或归属用户服务器（ Home Subscriber Server , HSS ) , 或认证、 4受权以及计费 ( Authentication Authorization, Accounting, AAA )服务器。 其中， 数据网关节点可以是第三 代（ 3rd-Generation, 3G ) 网络中的网关通用分组无线服务支持节点（ Gateway GPRS Support Node, GGSN ) ,也可以是长期演进（ Long Term Evolution, LTE ) 网络中的分组数据网网关（ Packet Data Network Gateway, PDNGW ) , 还可以 是全球微波互联接入 ( Worldwide Interoperability for Microwave Access , WIMAX ) 网络中的家乡代理 （Home agent, HA )或其他网络中的对等实体。 当 Push代理和网络侧网元（如数据网关节点）位于同一设备时， 两者之间的 交互或触发为内部交互或触发，如通过进程间通信、 函数调用等方式来交行或 触发。 如果 Push代理和网络侧网元（如数据网关节点）共享数据， 则两者之 间的交互或触发步骤可以省略。 实施例一：
请参阅图 1 , 图 1为本发明实施例中提供的一种推送设备间的协作方法的 流程图。 如图 1所示， 该方法可以包括以下步骤：
101、 Push代理获取 Push客户端的 Push标识和地址；
本实施例中 , Push客户端的地址可以是 Push客户端的 IP地址 , 或是 IP 地址和端口。
其中， Push客户端的 Push标识可以是 Push客户端的设备令牌 ( device token ), 或者可以是其他可以表示 Push客户端身份的参数或标识。 在 Push客 户端入网后会与 Push服务器建立持久的 IP连接，连接建立后， Push客户端向 Push服务器注册， Push服务器会把设备令牌发送给 Push客户端。
102、 Push代理保存 Push客户端的 Push标识和地址的映射关系； 其中， Push代理中可以保存多个 Push客户端的 Push标识和地址的映射关 系， 构成一个 Push标识和地址的映射表。 在映射表中， 每一个 Push客户端的 Push标识互不相同， 一般地， 每一个 Push客户端的地址也互不相同。
103、 若 Push客户端的地址发生变化， 则 Push代理更新上述的映射关系 中对应的地址。
本实施例中， Push代理可以通过以下 2种方式来获取 Push客户端的 Push 标识和地址：
方式一： Push代理通过接收并中转 Push客户端的 Push注册请求消息来获 取 Push客户端的 Push标识和地址。 如图 2所示， 可以包括以下步骤：
201、 Push代理接收 Push客户端发送的 Push注册请求消息，其中，该 Push 注册请求消息或其数据包头携带 Push客户端的地址，另外还可以携带 Push服 务器的地址；
其中， 上述的数据包是 Push注册请求消息的数据包。
202、 Push代理解析上述的 Push注册请求消息或其数据包头， 获得 Push 客户端的地址；
203、 Push代理将上述的 Push注册请求消息后发送至 Push服务器； 可选地， Push代理可以将其地址写入 Push注册请求消息，一起发送至 Push 服务器。 举例来说， Push代理可以将上述的 Push注册请求消息中携带的 Push 客户端的地址更新为 Push代理的地址，实现 Push代理的地址写入上述的 Push 注册请求消息； 或者， Push代理也可以直接在上述的 Push注册请求消息增加 Push代理的地址， 不影响本发明实施例的实现。
204、 Push代理接收 Push服务器发送的 Push注册请求响应消息， 其中， 该 Push注册请求响应消息携带 Push服务器为 Push客户端分配的 Push标识； 其中， Push服务器在接收到 Push代理发送的 Push注册请求消息后， 为 Push客户端分配的 Push标识， 并通过 Push代理的地址将为 Push客户端分配 的 Push标识携带在 Push注册请求响应消息中发送至 Push代理。
优选地， Push服务器为 Push客户端分配 Push标识之后，可以保存该 Push 客户端的 Push标识与 Push代理的地址的映射关系。
205、 Push代理解析上述的 Push注册请求响应消息， 获得 Push客户端的 Push标识。
本实施例中， 上述步骤 201 中 Push代理接收的 Push客户端发送的 Push 注册请求消息中可以进一步携带 Push客户端的认证信息， 认证信息用于向 Push服务器证明 Push客户端的身份， 包括证书、 帐户名、 密码、 用密钥材料 生成的消息摘要等等。
相应地，在上述的步骤 202中 Push代理还可以通过解析上述的 Push注册 请求消息， 获得 Push客户端的认证信息。
相应地， Push服务器在接收到 Push代理发送的 Push注册请求消息后，根 据 Push客户端的认证信息认证 Push客户端的身份合法后再为 Push客户端分 配的 Push标识， 并通过 Push代理的地址将为 Push客户端分配的 Push标识携 带在 Push注册请求响应消息中发送至 Push代理。
方式二： Push代理无需通过中转 Push客户端的 Push注册请求消息来获取 Push客户端的 Push标识和地址。 如图 3所示， 可以包括以下步骤：
301、 Push代理接收 Push客户端发送的代理注册请求消息， 其中， 该代 理注册请求消息或其数据包头携带 Push客户端的 Push标识和地址；
302、 Push代理解析上述的代理注册请求消息或其数据包头， 获得 Push 客户端的 Push标识和地址。
其中， Push代理通过上述的方式二获取 Push客户端的 Push标识和地址 的前提是， Push客户端需要事先向 Push服务器进行注册，获取 Push客户端的 Push标识。其中， Push客户端向 Push服务器注册，并获取 Push客户端的 Push 标识具体为：
1 ) Push客户端发送 Push注册请求消息至 Push服务器；
其中， Push客户端发送的 Push注册请求消息或其数据包头携带 Push客户 端的地址， 另外还可以携带 Push服务器的地址。
可选地， Push客户端发送的 Push注册请求消息还可以携带 Push客户端的 认证信息， 使得 Push服务器在接收到 Push客户端发送的 Push注册请求消息 后， 根据 Push客户端的认证信息认证 Push客户端的身份合法再为 Push客户 端分配的 Push标识。
2 ) Push客户端接收 Push服务器发送的 Push注册请求响应消息， 其中， 该 Push注册请求响应消息携带 Push服务器为 Push客户端分配的 Push标识； 可选地， 上述步骤 1 ) 中 Push客户端发送的 Push注册请求消息还可以携 带 Push代理的地址， 使得 Push服务器为 Push客户端分配 Push标识之后， 可 以保存 Push客户端的 Push标识与 Push代理的地址的映射关系。
其中， Push代理的地址可以在 Push客户端中事先配置或者由 Push客户端 通过动态主机设置协议 ( Dynamic Host Configuration Protocol, DHCP )、 i或名系 统（ Domain Name System, DNS )等方法动态发现， 还可以是 Push客户端在 向 Push服务器建立连接或注册过程中由 Push服务器重定向确定。
3 ) Push客户端解析上述的 Push注册请求响应消息， 获得 Push客户端的 Push标识。
本实施例中， 上述的步骤 103中若 Push客户端的地址发生变化， 则 Push 代理更新上述的映射关系中的 Push客户端的地址。 具体地， Push客户端的地 址变化可以包括地址更新和释放两种情况：
情况一、 由网络侧网元启动 Push客户端的地址更新， 具体过程如下：
1 ) Push代理接收网络侧网元发送的地址更新消息， 其中， 该地址更新消 息携带网络侧网元感知的 Push客户端的原地址以及变化后的新地址；
本实施例中， 上述的网络侧网元可以为数据网关节点，也可以是归属位置 寄存器（HLR ), 或归属用户服务器（HSS ), 或认证、 授权以及计费 （AAA ) 服务器。
2 ) Push代理根据上述的原地址查询保存的 Push客户端的 Push标识和地 址的映射关系， 并将上述的新地址更新映射关系中对应的地址。
其中， 在情况一的场景下， Push代理需要事先告知网络侧网元， 在网络 侧网元感知 Push客户端的地址发生变化时及时通知 Push代理。 举例如下： Push代理发送触发消息至网络侧网元， 其中， 触发消息携带 Push客户端 的地址， 用于触发网络侧网元在感知到 Push客户端的地址发生变化时通知 Push代理。
可选地， 本实施例中， Push代理和网络侧网元可以位于同一设备， 此时 两者之间的交互或触发为内部交互或触发，如可以通过进程间通信、 函数调用 等方式来进行交行或触发。 即 Push代理通过内部触发机制 （如可以通过进程 间通信、 函数调用等方式）发送触发消息， 以触发网络侧网元在感知到 Push 客户端的地址发生变化时通知 Push代理。如果 Push代理和网络侧网元共享数 据， 则两者之间的交互或触发步骤可以省略。
情况二、 由 Push客户端启动 Push客户端的地址更新， 具体过程如下： 1 ) Push代理接收 Push客户端发送的地址更新消息， 其中， 该地址更新 消息携带 Push客户端的 Push标识以及 Push客户端感知的变化后的新地址； 2 )Push代理根据 Push客户端的 Push标识查询保存的 Push客户端的 Push 标识和地址的映射关系， 并将上述的新地址更新映射关系中对应的地址。
情况三、 由网络侧网元启动 Push客户端的地址释放， 具体过程如下： 1 ) Push代理接收网络侧网元发送的地址释放消息， 其中， 该地址释放消 息携带网络侧网元感知的 Push客户端的释放前地址；
2 ) Push代理根据该地址查询保存的 Push客户端的 Push标识和地址的映 射关系， 并将映射关系中的地址的标记为未获取或特殊值。
其中， 特殊值可以用 0或 1表示， 用于表示 Push标识对应的 Push客户端 的地址尚未获取。
其中， 在情况三的场景下， Push代理也需要事先告知网络侧网元， 在网 络侧网元感知 Push客户端的地址发生变化时及时通知 Push代理。 当 Push代 理和网络侧网元位于同一设备时 ,此时两者之间的交互或触发为内部交互或触 发， 如 Push代理可以通过内部触发机制 （如可以通过进程间通信、 函数调用 等方式）发送触发消息， 以触发网络侧网元在感知到 Push客户端的地址发生 变 4匕时通知 Push代理。
情况四、 由 Push客户端启动 Push客户端的地址释放， 具体过程如下：
1 ) Push代理接收 Push客户端发送的地址释放消息， 其中， 该地址释放 消息携带 Push客户端的释放前地址； 2 ) Push代理根据该地址查询保存的 Push客户端的 Push标识和地址的映 射关系， 并将映射关系中的地址的标记为未获取或特殊值。 本实施例中， 由网络侧网元或 Push客户端启动 Push客户端的地址更新操 作 , 使得 Push代理可以及时更新 Push客户端的 Push标识和地址的映射关系 中的 Push客户端的地址， 提高 IP连接的有效性和可达性。 本发明实施例提供的推送设备间的协作方法中， Push代理在保存了 Push 客户端的 Push标识和地址的映射关系的基础上， 可以将 Push服务器发送的 Push消息转发给 Push客户端。 具体过程如下：
1 ) Push代理接收 Push服务器发送 Push消息， 其中， 该 Push消息携带 Push客户端的 Push标识；
2 ) Push代理根据 Push客户端的 Push标识，从保存的 Push客户端的 Push 标识和地址的映射关系中获取 Push客户端的地址；
3 ) Push代理根据 Push客户端的地址， 将 Push消息发送至 Push客户端。 可选地， 在将 Push消息发送至 Push客户端之前， Push代理可以将 Push 消息转换格式以适应 Push客户端的接口。 Push代理可以将不同 Push服务器发 送的不同格式的 Push消息转换统一格式的 Push消息发送给 Push客户端， 使 得 Push服务不局限于特定的 Push客户端。 本发明实施例提供的推送设备间的协作方法中， 如果 Push客户端不再需 要 Push服务或者退网时， 可以由 Push客户端或网络侧网元向 Push服务器发 起去注册过程。 其中， 去注册过程可以分以下几种场景：
场景一： Push客户端向 Push服务器发起去注册过程， 过程如下：
1 ) Push客户端向 Push服务器发送去注册请求消息， 其中， 该去注册请 求消息至少携带 Push客户端的 Push标识， 使 Push服务器删除与 Push客户端 的 Push标识相关的上下文， 例如， 删除该 Push客户端的 Push标识与 Push代 理的地址的映射关系；
2 ) Push代理接收 Push客户端发送的去注册请求消息， 其中， 该去注册 请求消息至少携带 Push客户端的 Push标识；
3 )Push代理发送去注册请求响应消息至 Push客户端，并删除保存的 Push 客户端的 Push标识和地址的映射关系。
场景二： Push客户端向 Push服务器发起去注册过程， 过程如下：
1 ) Push代理接收 Push客户端发送的去注册请求消息， 其中， 该去注册 请求消息或其数据包头至少携带 Push客户端的 Push标识， 可选地， 该去注册 请求消息或其数据包头还可以携带 Push服务器的地址； 2 ) Push代理将该去注册请求消息发送至 Push服务器；
可选地， Push代理可以将 Push客户端发送的去注册请求消息转换格式， 以适应 Push服务器的接口。
3 ) Push代理接收 Push服务器发送的去注册请求响应消息并发送至 Push 客户端， 删除保存的 Push客户端的 Push标识和地址的映射关系。
场景三： 网络侧网元向 Push服务器发起去注册过程， 过程如下：
1 ) Push代理接收网络侧网元发送的去注册请求消息， 其中， 该去注册请 求消息或其数据包头至少携带 Push客户端的地址；
2 ) Push代理根据 Push客户端的地址，从保存的 Push客户端的 Push标识 和地址的映射关系中获得 Push客户端的 Push标识并写入去注册请求消息后发 送给 Push服务器， 使 Push服务器删除与 Push客户端的 Push标识相关的上下 文， 例如， 删除该 Push客户端的 Push标识与 Push代理的地址的映射关系；
3 ) Push代理接收 Push服务器发送的去注册请求响应消息， 删除保存的 Push客户端的 Push标识和地址的映射关系。 本实施例一中， Push代理在获取 Push客户端的 Push标识和地址之后，可 以保存 Push客户端的 Push标识和地址的映射关系， 在 Push客户端的地址发 生变化时， 可及时地对其保存的 Push客户端的地址进行更新， 从而能够提高 Push客户端的 IP连接的有效性和可达性，进而能够提高 Push消息的实时性和 可靠性。更进一步地， Push代理可以将不同 Push服务器发送的不同格式的 Push 消息转换统一格式的 Push消息发送给 Push客户端， 使得 Push服务不局限于 特定的 Push客户端。 实施例二：
本实施例提供的推送设备间的协作方法中， Push代理作为 Push服务器和
Push客户端的中转， 可以用于完成包括 Push客户端的 Push注册、 Push消息 转发、 Push客户端的地址更新或释放、 Push去注册、 Push代理模拟心跳以及 网络异常通知等过程。 下面， 结合附图说明分别对本实施例中提供的推送设备 间的协作方法包括的各过程进行详细说明。
过程一、 Push客户端的 Push注册：
为使用 Push服务， Push客户端的首先需要向 Push服务器发起 Push注册 过程。 其中， 根据 Push代理是否中转注册信令， 可以有以下几种注册方式： 方式 A ) 、 Push代理中转注册信令， 如图 4所示， 该注册过程可以包括 以下步骤：
401、 Push客户端和 Push代理之间建立连接；
例如， Push客户端和 Push代理之间可以建立传输控制协议（ Transmission Control Protocol, TCP )连接。 其中， Push代理的地址可以在 Push客户端事 先配置或者由 Push客户端通过 DHCP、 DNS等方法动态发现， 还可以是 Push 客户端在向 Push服务器建立连接时由 Push服务器重定向确定。
402、 Push客户端向 Push代理发送 Push注册请求消息， 其中， 该注册请 求消息或其数据包头中携带 Push客户端的地址以及 Push服务器的地址；
可选地， Push客户端向 Push代理发送的 Push注册请求还可以携带 Push 客户端的认证信息。其中，认证信息用于向 Push服务器证明 Push客户端身份， 这些认证信息可以包含但不限于证书、 帐户名、 密码、 用密钥材料生成的消息 摘要等。
可选地，上述的步骤 402中， Push客户端也可以向 Push服务器发送 Push 注册请求， 由 Push服务器将该注册请求重定向到相应的 Push代理。
403、 Push代理解析上述的 Push注册请求消息或其数据包头， 获得 Push 客户端的地址并保存；
可选地， 若 Push客户端向 Push代理发送的 Push注册请求还携带了 Push 客户端的认证信息， 则 Push代理还可以获取 Push客户端的认证信息并保存。
404、 Push代理根据上述的 Push注册请求消息中携带的 Push服务器的地 址将 Push注册请求消息转发给 Push服务器， 其中， Push代理将上述的 Push 注册请求消息携带的 Push客户端的地址更新为 Push代理的地址；
可选地， Push代理也可以直接在上述的 Push注册请求消息增加 Push代理 的地址， 而无需删除或更新 Push客户端的地址， 不影响本发明实施例的实现。
可选地， Push代理在转发 Push注册请求之前，可以将 Push客户端将 Push 注册请求转换格式以适应 Push服务器接口。
405、 Push服务器接收到 Push代理转发的 Push注册请求消息后，发送 Push 注册请求响应消息给 Push代理，其中，该 Push注册请求响应消息中携带 Push 服务器为 Push客户端分配的 Push标识。 同时， Push服务器保存 Push标识和 Push代理地址的映射关系；
可选地， 若 Push代理转发的 Push注册请求消息还携带了 Push客户端的 认证信息， 则 Push服务器接收到 Push代理转发的 Push注册请求消息后， 根 据 Push客户端的认证信息认证 Push客户端的身份合法后再为 Push客户端分 配的 Push标识， 并通过 Push代理的地址将为 Push客户端分配的 Push标识携 带在 Push注册请求响应消息中发送至 Push代理。
406、 Push代理解析 Push服务器发送的 Push注册请求响应消息，保存 Push 标识和 Push客户端的地址的映射关系；
其中， 上述的步骤 406可以放在步骤 407之后。
407、 Push代理根据 Push客户端的地址，将 Push服务器发送的 Push注册 请求响应消息转发给 Push客户端；
可选地， 在转发 Push服务器发送的 Push注册请求响应消息之前， Push 代理可以将 Push服务器发送的 Push注册请求响应消息转换格式以适应 Push 客户端接口。
408、 Push代理发送触发消息至数据网关节点， 其中， 触发消息携带 Push 客户端的地址， 用于触发数据网关节点在 Push客户端的地址更新或释放地址 时通知 Push代理。
此外， Push代理还可以向数据网关节点、 HLR、 HSS、 AAA服务器等网 元发送携带 Push客户端的地址的触发消息， 用于触发这些网络侧网元在 Push 客户端退网 （即去注册 ) 时通知 Push代理。
其中， 上述的步骤 406、 407和 408没有顺序限定， 只要在步骤 405之后 执行即可。
方式 B ) 、 Push代理不中转注册信令， 如图 5所示， 该注册过程可以包括 以下步骤：
501、 Push客户端发送 Push注册请求消息至 Push服务器； 其中， Push客 户端发送的 Push注册请求消息或其数据包头至少携带 Push客户端的地址以及 Push服务器的地址；
可选地，上述步骤 501中的 Push客户端发送的 Push注册请求消息还可以 携带 Push代理的地址。其中， Push代理的地址在 Push客户端事先配置或者由 Push客户端通过 DHCP、 DNS等方法动态发现。
502、 Push服务器为 Push客户端分配 Push标识， 并向 Push客户端返回
Push注册请求响应消息，其中，该 Push注册请求响应消息中携带 Push服务器 为 Push客户端分配的 Push标识；
可选地，若上述步骤 501中的 Push客户端发送的 Push注册请求消息没有 携带 Push代理的地址，则步骤 502中的 Push服务器向 Push客户端返回的 Push 注册请求响应消息还可以携带 Push代理的地址。 其中， Push代理地址是 Push 服务器根据上述步骤 501中的 Push注册请求消息中携带的 Push客户端的地址 查询本地配置表获得的。 同时， Push服务器保存为 Push客户端分配的 Push 标识和 Push代理地址的映射关系。
可选地，上述步骤 501中的 Push客户端发送的 Push注册请求消息还可以 携带 Push客户端的认证信息， 使得 Push服务器在接收到 Push客户端发送的 Push注册请求消息后，根据 Push客户端的认证信息认证 Push客户端的身份合 法再为 Push客户端分配的 Push标识。 503、 Push客户端获取 Push标识后， 向 Push代理发送代理注册请求消息， 其中，该代理注册请求消息中或其数据包头携带 Push客户端的 Push标识和地 址；
可选地， 该代理注册请求中也可以携带 Push客户端的认证信息。
504、 Push代理保存 Push客户端的 Push标识和地址的映射关系；
505、 Push代理向 Push客户端返回代理注册请求响应消息；
506、 Push代理发送触发消息至数据网关节点， 其中， 触发消息携带 Push 客户端的地址， 用于触发数据网关节点在 Push客户端的地址更新或释放地址 时通知 Push代理。
此外， Push代理还可以向数据网关节点、 HLR/HSS/AAA等网元发送携带
Push客户端的地址的触发消息， 用于触发这些网络侧网元在终端退网 （即去 注册） 时通知 Push代理。
其中， 上述的步骤 504、 505和 506没有顺序限定， 只要在步骤 503之后 执行即可。
507、 Push客户端收到 Push代理注册请求响应后， 向 Push服务器发送注 册确认消息。
过程二、 Push消息转发：
通过上述的过程一所描述的 Push注册， Push代理可以保存 Push客户端的 Push标识和地址的映射关系 , 继而 Push代理可以将 Push服务器发送的 Push 消息转发给 Push客户端。 其中， Push服务器通过接收应用服务器发送的应用 消息来触发 Push消息的发送。 如图 6所示， Push消息转发的过程如下：
601、 应用服务器向 Push服务器发送应用消息， 其中， 该应用消息中携带 Push客户端的 Push标识；
其中， Push服务器的地址和 Push客户端的 Push标识可以由 Push服务器 在 Push客户端的 Push注册完成后通知应用服务器的。
602、 Push服务器根据应用服务器发送的应用消息生成 Push消息， 其中， 该 Push消息中携带 Push客户端的 Push标识， 并根据注册过程保存的 Push标 识和 Push代理地址的映射关系向 Push代理发送该 Push消息；
603、 Push代理解析 Push服务器发送的 Push消息中的 Push标识， 并根据 保存的 Push客户端的 Push标识和地址的映射关系将该 Push消息转发给 Push 客户端。
可选的， Push代理可以将 Push服务器发送的 Push消息转换格式以适应
Push客户端接口。 从而， Push代理可以实现可以将不同 Push服务器发送的不 同格式的 Push消息转换统一格式的 Push消息发送给 Push客户端， 使得 Push 服务不局限于特定的 Push客户端。
例如， Push代理将 Google C2DM服务器发送的 C2DM Push消息转换成 SIP Push消息或者 WAP Push消息， 并发送给 Push客户端。
过程三、 Push客户端的地址更新或释放：
通过上述的过程一所描述的 Push注册， Push代理可以保存 Push客户端的 Push标识和地址的映射关系 , 继而在 Push客户端的地址更新或释放时 , Push 代理可以及时地对映射关系中的地址进行更新。
其中， Push客户端的地址更新是指， Push客户端由于移动或其它网络异 常的原因发生地址变化。 Push客户端的地址更新有以下 2种方式：
方式 A ) Push客户端启动地址更新： 其中， 方式 A )是 Push客户端感知其地址发生变化， 并主动通知 Push代 理， 如图 7所示， 包括以下步骤：
701、 Push客户端感知其地址变化， 发送地址更新消息给 Push代理， 其 中， 该地址更新消息或其数据包头中携带 Push客户端的 Push标识和新地址； 702、 Push代理更新保存的 Push客户端的 Push标识和地址的映射关系， 以新地址代替原地址；
703、 Push代理返回更新响应给 Push客户端。
方式 B ) 网络侧网元启动 Push客户端的地址更新：
其中， 方式 B )是由网络侧网元（如数据网关节点）感知 Push客户端的 地址发生变化， 并通知 Push代理。 其中， 方式 B )需要网络侧网元（如数据 网关节点 )事先接收 Push代理发送的触发消息， 该触发消息用于在网络侧网 元感知 Push客户端的地址发生变化时通知 Push代理。 如 Push代理和网络侧 网元（如数据网关节点）共享数据则不需要触发。如图 8所示， 包括以下步骤：
801、 网络侧网元感知 Push客户端的地址变化后， 发送地址更新消息给 Push代理， 其中， 该地址更新消息携带网络侧网元感知的 Push客户端的原地 址以及变化后的新地址；
802、 Push代理根据 Push客户端的原地址查询保存的 Push客户端的 Push 标识和地址的映射关系， 并将上述的新地址更新映射关系中的地址。
其中， Push客户端的地址释放：
本实施例中， Push客户端的地址释放适用于非 LTE的网络（如 3G网络）， 其中， Push客户端的地址释放不会影响 Push客户端与网络侧的电路承载（CS ) 域的连接。 Push客户端的地址释放有以下 2种方式： 方式 A ) 网络侧网元启动 Push客户端的地址释放：
其中， 方式 A )需要网络侧网元（如数据网关节点）事先接收 Push代理 发送的触发消息， 该触发消息用于在网络侧网元感知 Push客户端的地址发生 变化时通知 Push代理。 如 Push代理和网络侧网元（如数据网关节点）共享数 据则不需要触发。 如图 9所示， 包括以下步骤：
901、 网络侧网元感知 Push客户端的所有分组数据协议 ( Package Data Protocol , PDP )释放或地址释放后， 发送的地址释放消息给 Push代理， 其 中， 该地址释放消息携带网络侧网元感知的 Push客户端的地址；
902、 Push代理根据地址释放消息携带的 Push客户端的地址查询保存的 Push客户端的 Push标识和地址的映射关系， 并将映射关系中的地址的标记为 未获取或特殊值。
方式 B ) Push客户端启动地址释放， 包括以下步骤：
1 ) Push客户端发送地址释放消息给 Push代理， 其中， 该地址释放消息 中携带 Push客户端的地址；
2 ) Push代理更新保存的 Push客户端的 Push标识和地址的映射关系， 将 映射关系中的 Push客户端的地址标记为未获取或特殊值。 过程四、 Push客户端的 Push去注册：
通过上述的过程一所描述的 Push注册， Push代理可以保存 Push客户端的 Push标识和地址的映射关系。如果 Push客户端不再需要 Push月良务或者退网时， 可以由 Push客户端或网络侧网元向 Push服务器发起去注册过程。 其中， 考虑 方式 A ) Push客户端发起 Push去注册过程， Push代理中转去注册信令; 如图 10所示， 方式 A ) 的 Push去注册过程可以包括如下步骤：
1001、 Push客户端向 Push代理发送去注册请求消息， 其中， 该去注册请 求消息或其数据包头中携带 Push客户端的 Push标识；可选地还可以携带 Push 服务器的地址；
1002、 Push代理向 Push服务器发送去注册请求消息；
可选地， Push代理可以将 Push客户端发送的去注册请求消息转换格式， 以适应 Push服务器的接口， 使得 Push客户端可以和不同的 Push服务器进行 交互， 使 Push服务不局限于特定的 Push客户端。
1003、 Push服务器返回去注册请求响应消息给 Push代理；
1004、 Push代理转发去注册请求响应消息给 Push客户端， 并删除保存的 Push客户端的 Push标识和地址的映射关系。
可选地， Push代理可以将 Push服务器返回的去注册请求响应消息转换格 式， 以适应 Push客户端的接口， 使得不同的 Push服务器可以和 Push客户端 进行交互， 使 Push服务不局限于特定的 Push服务器。
方式 B ) Push客户端发起 Push去注册过程， Push代理不中转去注册信令; 如图 11所示， 方式 B ) 的 Push去注册过程可以包括如下步骤：
1101、 Push客户端向 Push服务器发送去注册请求消息， 其中， 该去注册 请求消息携带 Push客户端的 Push标识， 使 Push服务器删除与 Push客户端的 Push标识相关的上下文， 例如， 删除该 Push客户端的 Push标识与 Push代理 的地址的映射关系；
1102、 Push客户端向 Push代理发送去注册请求消息， 其中， 该去注册请 求消息携带 Push客户端的 Push标识；
1103、 Push代理发送去注册请求响应消息至 Push客户端， 并删除保存的 Push客户端的 Push标识和地址的映射关系。
方式 C ) 网络侧网元发起 Push去注册过程；
其中， 方式 C ) 需要网络侧网元（如数据网关节点）事先接收 Push代理 发送的触发消息， 该触发消息用于在网络侧网元感知 Push客户端退网时通知 Push代理。 如 Push代理和网络侧网元（如数据网关节点）共享数据则不需要 触发。 如图 12所示， 方式 C ) 的 Push去注册过程可以包括如下步骤：
1201、 网络侧网元发现 Push客户端退网时， 向 Push代理发送去注册请求 消息， 其中， 该去注册请求消息携带 Push客户端的地址；
1202、 Push代理根据 Push客户端的地址， 从保存的 Push客户端的 Push 标识和地址的映射关系中获得 Push客户端的 Push标识并写入去注册请求消息 后发送给 Push服务器，使 Push服务器删除与 Push客户端的 Push标识相关的 上下文， 例如， 删除该 Push客户端的 Push标识与 Push代理的地址的映射关 系；
1203、 Push服务器返回去注册请求响应消息给 Push代理， Push代理删除 Push客户端的 Push标识和地址的映射关系。
可选地， Push代理还可以将根据 Push客户端的认证信息删除。
过程五、 Push代理模拟心跳：
当 Push代理保存有 Push客户端的认证信息并且 Push客户端已经在 Push 服务器注册时， Push代理可以模拟 Push客户端定期地向 Push服务器发送心跳， 以符合 Push服务器现有机制。 过程六、 网络异常通知：
当 Push代理收到 Push服务器发送给 Push客户端的 Push消息时， 如发现 Push消息中的 Push标识对应的 Push客户端位于繁忙或异常网络区域时，则向 Push服务器返回一个繁忙或者异常响应， 以便于 Push服务器作相应的处理。
在此之前， Push代理可以和数据网关节点进行交互， 获取与 Push客户端 的地址对应的网络区域标识， 该网络区域标识可以是 SGSN或 GW等连接数 据网关节点的网元地址。 Push代理根据这些网络区域标识与网络状态数据库 交互以获得这些网络区域的忙 /闲 /异常等的状态，具体可以是周期性获取状态， 也可以是事件触发网络状态数据库向 Push代理汇报。
本实施例提供的推送设备间的协作方法中， Push代理在获取 Push客户端 的 Push标识和地址之后， 可以保存 Push客户端的 Push标识和地址的映射关 系， 在 Push客户端的地址发生变化时， 无需心跳操作即可及时地对其保存的 Push客户端的地址进行更新，从而能够提高 Push客户端的 IP连接的有效性和 可达性， 进而能够提高 Push消息的实时性和可靠性。 另外， 消除 Push客户端 和 Push服务器之间的心跳， 可以节省 Push客户端能量和网络侧资源。 因为， 在无线网络中， Push客户端为发送心跳包需要间歇地进行空闲态和激活态的 转换， 频繁的心跳需要大量消耗 Push客户端能量和网络侧资源， 特别是 Push 客户端数目庞大时容易造成网络侧信令风暴。 更进一步地， Push代理可以将 不同 Push服务器发送的不同格式的 Push消息转换统一格式的 Push消息发送 给 Push客户端， 使得 Push服务不局限于特定的 Push客户端。 实施例三 请参阅图 13 , 图 13为本发明实施例中提供的另一种推送设备间的协作方 法的流程图。 如图 13所示， 该方法可以包括以下步骤：
1301、 Push代理获取 Push客户端的推送 Push标识、网络内部标识和地址； 本实施例中， Push客户端的地址可以是 Push客户端的 IP地址， 或是 IP 地址和端口。
其中， Push客户端的网络内部标识的包括但不限于 Push客户端的国际移 动用户识别码（International Mobile Subscriber Identity, IMSI ) 、 移动用户国 际号码（ Mobile Station ISDN, MSISDN ) 、 网络访问标识符（ Network Access Identifier, NAI )等。
1302、 Push代理保存 Push客户端的 Push标识、 网络内部标识和地址的映 射关系；
1303、 若 Push客户端的地址发生变化， 则 Push代理更新上述映射关系中 对应的地址。
本实施例中， Push代理获取 Push客户端的推送 Push标识、 网络内部标 识和地址具体可以釆用以下方式：
方式一：
1 ) Push代理接收 Push客户端发送的 Push注册请求消息， 其中， 该 Push 注册请求消息或其数据包头携带 Push客户端的地址，还可以携带 Push服务器 的地址；
2 ) Push代理解析上述的 Push注册请求消息或其数据包头， 获得 Push客 户端的地址， 并根据获得的 Push客户端的地址向网络侧网元查询对应的网络 内部标识， 该网络侧网元为数据网关节点， 或归属位置寄存器 HLR, 或归属 用户服务器 HSS, 或认证、 授权以及计费 AAA服务器；
3 ) Push代理将 Push注册请求消息发送至 Push服务器；
4 ) Push代理接收 Push服务器发送的 Push注册请求响应消息， 其中， 该 Push注册请求响应消息携带 Push服务器为 Push客户端分配的 Push标识； 5 )Push代理解析上述的 Push注册请求响应消息，获得 Push客户端的 Push 标识。
方式二：
1 ) Push代理接收 Push客户端发送的 Push注册请求消息，该 Push注册请 求消息或其数据包头中携带 Push客户端的 Push标识、 网络内部标识、 地址； 2 ) Push代理解析上述的 Push注册请求或其数据包头， 获得 Push客户端 的 Push标识、 网络内部标识、 地址。
方式三：
1 ) Push代理接收网络侧网元发送的 Push客户端入网通知 , 该 Push客户 端入网通知携带 Push客户端的地址、 网络内部标识； 该网络侧网元为数据网 关节点， 或归属位置寄存器 HLR, 或归属用户服务器 HSS , 或认证、 授权以 及计费 AAA服务器；
2 ) Push代理根据网络内部标识本地查询或者向用户信息数据库获取 Push 客户端认证信息、 Push服务器地址，并向 Push服务器发送 Push注册请求消息；
3 ) Push代理接收 Push服务器发送的 Push注册请求响应消息， 该 Push 注册请求响应消息携带 Push服务器为 Push客户端分配的 Push标识；
4 )Push代理解析上述的 Push注册请求响应消息，获得 Push客户端的 Push 标识。 本实施例中， 若 Push客户端的地址发生变化， 则 Push代理更新上述映射 关系中的地址具体可以为：
1 ) Push代理接收网络侧网元发送的地址更新消息， 其中， 该地址更新消 息携带 Push客户端的网络内部标识以及网络侧网元感知的 Push客户端的变化 后的新地址；
其中， 网络侧网元为数据网关节点， 或归属位置寄存器（HLR ) , 或归属 用户服务器（HSS ) , 或认证、 授权以及计费 （AAA )服务器。
2 ) Push代理根据网络内部标识查询保存的 Push客户端的 Push标识、 网 络内部标识和地址的映射关系 , 并将新地址更新映射关系中对应的地址。
本实施例提供的推送设备间的协作方法中， Push代理在获取 Push客户端 的 Push标识、 网络内部标识和地址之后， 可以保存 Push客户端的 Push标识、 网络内部标识和地址的映射关系 , 在 Push客户端的地址发生变化时 , 无需心 跳操作即可及时地对其保存的 Push客户端的地址进行更新， 从而能够提高 Push客户端的 IP连接的有效性和可达性，进而能够提高 Push消息的实时性和 可靠性。 实施例四：
本实施例提供的推送设备间的协作方法中， Push代理作为 Push服务器和 Push客户端的中转，结合 Push客户端的网络内部标识可以完成包括 Push客户 端的 Push注册、 Push消息转发、 Push客户端的地址更新或释放、 Push去注册、 Push代理模拟心跳以及网络异常通知等过程， 丰富 Push代理的功用。 下面， 结合附图说
进行伴细说明。 过程一、 Push客户端的 Push注册：
方式 A ) 、 Push代理中转注册信令， 如图 14所示， 该注册过程可以包括 以下步骤：
1401 , 与实施例二中的步骤 401相同；
1402、 Push客户端向 Push代理发送 Push注册请求消息， 其中， 该注册请 求消息或其数据包头中携带 Push客户端的地址、网络内部标识以及 Push服务 器的地址， 其中网络内部标识为可选携带；
1403、 Push代理解析上述的 Push注册请求消息或其数据包头， 获得 Push 客户端的地址和网络内部标识并保存；
1404、 Push代理根据 Push服务器的地址， 将 Push注册请求消息发送至
Push服务器； 在此之前， 如原 Push注册请求消息中携带网络内部标识， 则将 该网络内部标识删除；
1405、 Push服务器接收到 Push代理转发的 Push注册请求消息后， 发送 Push注册请求响应消息给 Push代理，其中，该 Push注册请求响应消息中携带 Push服务器为 Push客户端分配的 Push标识。 同时， Push服务器保存 Push标 识和 Push代理地址的映射关系；
1406、 Push代理如还未获取 Push客户端的网络内部标识， 则向数据网关 节点进行网络内部标识查询交互， 交互过程中 Push代理向数据网关节点发送 Push客户端的地址 , 数据网关节点返回相应的网络内部标识；
其中，若 Push代理已经通过前面的步骤获取 Push客户端的网络内部标识， 则步骤 1406可以省略。
1407、 Push代理解析 Push服务器发送的 Push注册请求响应消息， 保存 Push客户端的 Push标识、 网络内部标识和地址的映射关系；
1408、 Push代理根据 Push客户端的地址， 将 Push服务器发送的 Push注 册请求响应消息转发给 Push客户端；
1409、 Push代理发送触发消息至数据网关节点，其中，触发消息携带 Push 客户端的网络内部标识， 用于触发数据网关节点在 Push客户端的地址更新或 释放地址时通知 Push代理。
此外， Push代理还可以向数据网关节点、 HLR/HSS/AAA等网元发送携带 Push客户端的网络内部标识的触发消息， 用于触发这些网络侧网元在 Push客 户端退网 （即去注册 ) 时通知 Push代理。
方式 B ) 、 Push代理不中转注册信令， 如图 15所示， 该注册过程可以包 括以下步骤：
1501、 与实施例二中的步骤 501相同；
1502、 与实施例二中的步骤 502相同；
1503、 Push客户端获取 Push标识后，向 Push代理发送代理注册请求消息， 其中， 该代理注册请求消息或其数据包头中携带 Push客户端的 Push标识、 网 络内部标识和地址， 其中网络内部标识为可选携带；
1504、 Push代理如还未获取 Push客户端的网络内部标识， 则向数据网关 节点进行网络内部标识查询交互， 交互过程中 Push代理向数据网关节点发送 Push客户端的地址 , 数据网关节点返回相应的网络内部标识；
其中，若 Push代理已经通过前面的步骤获取 Push客户端的网络内部标识， 则步骤 1504可以省略。
1505、 Push代理保存 Push客户端的 Push标识、 网络内部标识和地址的映 射关系；
1506、 Push代理向 Push客户端返回代理注册请求响应消息；
1507、 Push代理发送触发消息至数据网关节点，其中，触发消息携带 Push 客户端的网络内部标识， 用于触发数据网关节点在 Push客户端的地址更新或 释放地址时通知 Push代理。
此外， Push代理还可以向数据网关节点、 HLR/HSS/AAA等网元发送携带 Push客户端的网络内部标识的触发消息， 用于触发这些网络侧网元在终端退 网 （即去注册） 时通知 Push代理。
方式 C ) 、 Push代理发起 Push注册， 如图 16所示， 该注册过程可以包括 以下步骤：
1601、 Push客户端入网， 数据网关节点为 Push客户端分配地址， 并且向 Push代理发送 Push客户端入网通知 ,该通知中携带 Push客户端的网络内部标 识及地址；
其中， 可以事先在数据网关节点中配置 Push代理的地址。
1602、 Push客户端和 Push代理之间建立连接；
例如 , Push客户端和 Push代理之间可以建立 TCP连接。
1603、 Push代理如还未获取 Push客户端的网络内部标识， 则向数据网关 节点进行网络内部标识查询交互， 交互过程中 Push代理向数据网关节点发送 Push客户端的地址 , 数据网关节点返回相应的网络内部标识；
其中，若 Push代理已经通过前面的步骤获取 Push客户端的网络内部标识， 则步骤 1603可以省略。
1604、 Push代理获知 Push客户端入网或者 Push客户端和 Push代理建立 连接后， 根据获得的网络内部标识本地查询或者向用户信息数据库获取 Push 服务器的地址， 并向 Push服务器发送 Push注册请求消息；
可选地， Push代理发送的 Push注册请求消息还可以携带 Push客户端的认 证信息。
1605、 Push服务器接收到 Push代理发送的 Push注册请求消息后， 发送
Push注册请求响应消息给 Push代理， 其中， 该 Push注册请求响应消息携带 Push服务器为 Push客户端分配的 Push标识；
可选地， 若上述步骤 1604的 Push代理发送的 Push注册请求消息还携带 Push客户端的认证信息， 则在步骤 1605中， Push服务器先认证 Push客户端 身份合法后再发送携带 Push标识的 Push注册请求响应消息给 Push代理。
1606、 Push代理保存 Push客户端的 Push标识、 网络内部标识和地址的映 射关系；
1607、 与上述步骤 1507相同;
1608、 Push代理将 Push注册请求响应消息转发给 Push客户端。
过程二、 Push消息转发： 如图 17所示， Push消息转发的过程如下：
1701、 与上述的步骤 601相同;
1702、 与上述的步骤 602相同;
1703、 Push代理将 Push消息转换成短消息服务（ Short Messaging Service, SMS )消息或无线应用协议 ( Wireless Application Protocol, WAP ) Push消息， 并发送给短消息服务中心（ Short Message Service Center, SMSC )或 WAP Push 代理网关， 其中， SMS消息或 WAP Push消息中携带与 Push标识对应的网络 内部标识； 其中 , SMSC或 WAP代理网关的地址在 Push代理为预配置。
1704、 SMSC或 WAP代理网关将 SMS消息或 WAP Push消息发送给 Push 客户端。
过程三、 Push客户端的地址更新或释放：
通过上述的过程一所描述的 Push注册， Push代理可以保存 Push客户端的
Push标识、 网络内部标识和地址的映射关系， 继而在 Push客户端的地址更新 或释放时， Push代理可以及时地对映射关系中的地址进行更新。 其中， Push 客户端的地址更新有以下 2种方式：
方式 A ) Push客户端启动地址更新：
其中， 方式 A )是 Push客户端感知其地址发生变化， 并主动通知 Push代 理， 具体过程为：
1 ) Push客户端感知其地址变化时， 发送地址更新消息给 Push代理， 其 中， 该地址更新消息携带 Push客户端 Push标识、 网络内部标识和新地址； 2 ) Push代理更新保存的 Push标识、 网络内部标识和地址的映射关系， 以新地址代替原地址；
3 ) Push代理返回更新响应给 Push客户端。
方式 B ) 网络侧网元启动 Push客户端的地址更新：
其中， 方式 B )是由网络侧网元（如数据网关节点）感知 Push客户端的 地址发生变化， 并通知 Push代理。 其中， 方式 B )需要网络侧网元（如数据 网关节点 )事先接收 Push代理发送的触发消息， 该触发消息用于在网络侧网 元感知 Push客户端的地址发生变化时通知 Push代理。 如 Push代理和网络侧 网元（如数据网关节点）共享数据则不需要触发。 具体过程为： 1 )网络侧网元感知 Push客户端的地址变化后，发送地址更新消息给 Push 代理， 其中， 该地址更新消息携带网络侧网元感知的 Push客户端的网络内部 标识以及变化后的新地址；
2 ) Push代理根据 Push客户端的网络内部标识查询保存的 Push客户端的 Push标识、 网络内部标识和地址的映射关系， 并将上述的新地址更新映射关 系中的地址。
其中， Push客户端的地址释放：
本实施例中， Push客户端的地址释放不会影响 Push客户端与网络侧的 CS 域的连接。 Push客户端的地址释放为：
1 ) 网络侧网元感知 Push客户端的所有 PDP释放或地址释放后， 发送的 地址释放消息给 Push代理，其中，该地址释放消息携带网络侧网元感知的 Push 客户端的网络内部标识；
2 ) Push代理根据地址释放消息携带的 Push客户端的网络内部标识查询 保存的 Push客户端的 Push标识、 网络内部标识和地址的映射关系， 并将映射 关系中的地址的标记为未获取或特殊值。
过程四、 Push客户端的 Push去注册：
其中， Push客户端的 Push去注册的具体过程为：
1 ) Push客户端向 Push代理发送去注册请求消息， 其中， 该去注册请求 消息或其数据包头中携带 Push客户端的网络内部标识以及 Push服务器的地 址；
2 ) Push代理根据去注册请求消息或其数据包头中携带的 Push服务器的 地址， 向 Push服务器发送去注册请求； 可选地， Push代理可以将 Push客户端发送的去注册请求消息转换格式， 以适应 Push服务器的接口， 使得 Push客户端可以和不同的 Push服务器进行 交互， 使 Push服务不局限于特定的 Push客户端。
3 ) Push服务器返回去注册请求响应消息给 Push代理；
4 )Push代理转发去注册请求响应消息给 Push客户端，并删除保存的 Push 客户端的 Push标识、 网络内部标识和地址的映射关系。
可选地， Push代理可以将 Push服务器返回的去注册请求响应消息转换格 式， 以适应 Push客户端的接口， 使得不同的 Push服务器可以和 Push客户端 进行交互， 使 Push服务不局限于特定的 Push服务器。
本实施例提供的推送设备间的协作方法中， Push代理在获取 Push客户端 的 Push标识、 网络内部标识和地址之后， 可以保存 Push客户端的 Push标识 网络内部标识和地址的映射关系 , 在 Push客户端的地址发生变化时 , 无需心 跳操作即可及时地对其保存的 Push客户端的地址进行更新， 从而能够提高 Push客户端的 IP连接的有效性和可达性，进而能够提高 Push消息的实时性和 可靠性。 另外， 消除 Push客户端和 Push服务器之间的心跳， 可以节省 Push 客户端能量和网络侧资源。 更进一步地， Push代理可以将不同 Push服务器发 送的不同格式的 Push消息转换统一格式的 Push消息发送给 Push客户端， 使 得 Push服务不局限于特定的 Push客户端。 实施例五：
请参阅图 18, 图 18为本发明实施例中提供的一种推送设备间的协作装置 的结构图， 用于实现上述实施例一、 实施例二中的 Push代理的功能。 如图 18 所示， 该协作装置可以包括：
第一获取模块 1801 , 用于获取 Push客户端的 Push标识和地址； 第一保存模块 1802, 用于保存上述的 Push客户端的 Push标识和地址的 映射关系；
第一更新模块 1803 , 用于在 Push客户端的地址发生变化时， 更新上述的 映射关系中对应的地址。
本实施例中， Push客户端的地址可以是 Push客户端的 IP地址， 或是 IP 地址和端口。
请参阅图 19, 图 19为本发明实施例中提供的另一种推送设备间的协作装 置的结构图。其中， 图 19所示的协作装置是对图 18所示的协作装置进行优化 得到的， 其中， 第一获取模块 1801可以包括：
第一接收单元 18011 , 用于接收 Push客户端发送的 Push注册请求消息， 其中， 该 Push注册请求消息或其数据包头携带 Push客户端的地址； 可选地， 还可以携带 Push服务器的地址；
第一解析单元 18012, 用于解析上述的 Push注册请求消息或其数据包头， 获得 Push客户端的地址；
第一发送单元 18013 , 用于将上述的 Push注册请求消息后发送至 Push服 务器；
其中， 第一接收单元 18011 , 还用于接收 Push服务器发送的 Push注册请 求响应消息， 该 Push注册请求响应消息携带 Push服务器为 Push客户端分配 的 Push标识；
相应地，第一解析单元 18012还用于解析上述的 Push注册请求响应消息， 获得 Push客户端的 Push标识。
相应地，第一保存模块 1802可以用于保存第一解析单元 18012获得的 Push 客户端的 Push标识和地址的映射关系。
请参阅图 20, 图 20为本发明实施例中提供的另一种推送设备间的协作装 置的结构图。其中， 图 20所示的协作装置是对图 18所示的协作装置进行优化 得到的， 其中， 第一获取模块 1801可以包括：
第二接收单元 18014, 用于接收 Push客户端发送的代理注册请求消息， 该代理注册请求消息或其数据包头携带 Push客户端的 Push标识和地址；
第二解析单元 18015 , 用于解析上述的代理注册请求消息或其数据包头， 获得 Push客户端的 Push标识和地址。
相应地，第一保存模块 1802可以用于保存第二解析单元 18015获得的 Push 客户端的 Push标识和地址的映射关系。
请参阅图 21 , 图 21为本发明实施例中提供的另一种推送设备间的协作装 置的结构图。其中， 图 21所示的协作装置是对图 18所示的协作装置进行优化 得到的， 其中， 第一更新模块 1803可以包括：
第一处理单元 18031 , 用于接收网络侧网元发送的地址更新消息， 该地址 更新消息携带网络侧网元感知的 Push客户端的原地址以及变化后的新地址； 本实施例中， 网络侧网元为数据网关节点， 或 HLR, 或 HSS, 或 AAA服 务器。
第二处理单元 18032, 用于根据 Push客户端的原地址查询保存的 Push客 户端的 Push标识和地址的映射关系， 并将上述的新地址更新映射关系中对应 的地址。 即， 将新地址更新 Push客户端的原地址。 其中， 第二处理单元 18032具体用于根据 Push客户端的原地址查询第一 保存模块 1802保存的 Push客户端的 Push标识和地址的映射关系， 并将上述 的新地址更新映射关系中对应的地址。
可选地， 图 21 所示的协作装置中， 第一获取模块 1801 的结构可以与图 19或图 20中的第一获取模块 1801的结构相同， 本实施例不作限定。
可选地， 图 21所示的协作装置中， 第二处理单元 18032还用于发送触发 消息至网络侧网元， 该触发消息携带 Push客户端的地址， 用于触发网络侧网 元在感知到 Push客户端的地址发生变化时通知第一处理单元 18031。
请参阅图 22, 图 22为本发明实施例中提供的另一种推送设备间的协作装 置的结构图。其中， 图 22所示的协作装置是对图 18所示的协作装置进行优化 得到的， 其中， 第一更新模块 1803可以包括：
第三处理单元 18033 , 用于接收 Push客户端发送的地址更新消息， 该地 址更新消息携带 Push客户端的 Push标识以及 Push客户端感知的变化后的新 地址；
第四处理单元 18034 , 用于根据 Push客户端的 Push标识查询第一保存模 块 1802保存的 Push客户端的 Push标识和地址的映射关系， 并将新地址更新 上述映射关系中对应的地址。
可选地， 图 22所示的协作装置中， 第一获取模块 1801 的结构可以与图 19或图 20中的第一获取模块 1801的结构相同， 本实施例不作限定。
请参阅图 23 , 图 23为本发明实施例中提供的另一种推送设备间的协作装 置的结构图。其中， 图 23所示的协作装置是对图 18所示的协作装置进行优化 得到的， 该协作装置除了包括第一获取模块 1801、 第一保存模块 1802以及第 一更新模块 1803之外， 还包括：
第一控制模块 1804, 用于接收 Push服务器发送 Push消息， 该 Push消息 携带 Push客户端的 Push标识；
第二控制模块 1805 , 用于根据上述的 Push客户端的 Push标识， 从第一 保存模块 1802保存的 Push客户端的 Push标识和地址的映射关系中获取 Push 客户端的地址并通知第一控制模块 1804;
相应地， 第一控制模块 1804还用于根据第二控制模块 1805通知的 Push 客户端的地址， 将 Push服务器发送的 Push消息发送至 Push客户端。
可选地， 第一控制模块 1804在将 Push服务器发送的 Push消息发送送至 Push客户端之前，可以先将 Push消息转换格式以适应 Push客户端的接口，使 得 Push服务不局限于特定的 Push客户端。
可选地， 图 23所示的协作装置中， 第一获取模块 1801 的结构可以与图 19或图 20中的第一获取模块 1801的结构相同， 第一更新模块 1803的结构可 以与图 21或图 22中的第一更新模块 1803的结构相同， 本实施例不作限定。
第三控制模块 1806, 用于接收网络侧网元发送的地址释放消息， 该地址 释放消息携带网络侧网元感知的 Push客户端的释放前地址；
其中， 网络侧网元为数据网关节点， 或 HLR, 或 HSS , 或 AAA服务器。 第四控制模块 1807 , 用于根据上述地址查询第一保存模块 1802保存的 Push客户端的 Push标识和地址的映射关系， 并标记映射关系中对应的地址为 未获取或特殊值。
可选地， 图 23所示的协作装置中， 第三控制模块 1806还可以用于接收 Push客户端发送的去注册请求消息， 该去注册请求消息至少携带 Push客户端 的 Push标识；
相应地， 第四控制模块 1807还可以用于发送去注册请求响应消息至 Push 客户端， 并删除第一保存模块 1802保存的 Push客户端的 Push标识和地址的 映射关系。
可选地， 图 23所示的协作装置中， 第三控制模块 1806还可以用于接收
Push客户端发送的去注册请求消息， 该去注册请求消息至少携带 Push客户端 的 Push标识； 可选地， 还可以携带 Push服务器的地址；
相应地，第四控制模块 1807还可以用于将去注册请求消息发送至 Push服 务器； 接收 Push服务器发送的去注册请求响应消息并发送至 Push客户端， 并 删除第一保存模块 1802保存的 Push客户端的 Push标识和地址的映射关系。
本实施例提供的推送设备间的协作装置中， 第一保存模块 1802可以保存 上述的 Push客户端的 Push标识和地址的映射关系，第一更新模块 1803在 Push 客户端的地址发生变化时， 无需心跳操作即可及时地对其保存的 Push客户端 的地址进行更新， 从而能够提高 Push客户端的 IP连接的有效性和可达性， 进 而能够提高 Push消息的实时性和可靠性。 另外， 消除 Push客户端和 Push服 务器之间的心跳， 可以节省 Push客户端能量和网络侧资源。 更进一步地， 协 作装置可以将不同 Push服务器发送的不同格式的 Push消息转换统一格式的 Push消息发送给 Push客户端， 使得 Push服务不局限于特定的 Push客户端。 实施例六：
请参阅图 24, 图 24为本发明实施例中提供的另一种推送设备间的协作装 置的结构图， 用于实现上述实施例三、 实施例四中的 Push代理的功能。 如图 24所示， 该协作装置可以包括：
第二获取模块 2401 , 用于获取 Push客户端的 Push标识、 网络内部标识 和地址；
第二保存模块 2402, 用于保存上述的 Push客户端的 Push标识、 网络内 部标识和地址的映射关系；
第二更新模块 2403 , 用于在上述的 Push客户端的地址发生变化时， 更新 上述映射关系中对应的地址。
请参阅图 25 , 图 25为本发明实施例中提供的另一种推送设备间的协作装 置的结构图。其中， 图 25所示的协作装置是对图 24所示的协作装置进行优化 得到的， 其中， 第二获取模块 2401可以包括：
第三接收单元 24011 , 用于接收 Push客户端发送的 Push注册请求消息， 该 Push注册请求消息或其数据包头携带 Push客户端的地址； 可选地， 还可以 携带 Push服务器的地址；
第三解析单元 24012, 用于解析上述的 Push注册请求消息或其数据包头， 获得 Push客户端的地址，并根据 Push客户端的地址查询网络侧网元获得 Push 客户端的网络内部标识， 该网络侧网元为数据网关节点， 或归属位置寄存器 HLR, 或归属用户服务器 HSS, 或认证、 授权以及计费 AAA服务器；
第三发送单元 24013 , 用于将 Push注册请求消息发送至 Push服务器； 相应地，第三接收单元 24011还用于接收 Push服务器发送的 Push注册请 求响应消息， 该 Push注册请求响应消息携带 Push服务器为 Push客户端分配 的 Push标识；
相应地，第三解析单元 24012还用于解析上述的 Push注册请求响应消息， 获得 Push客户端的 Push标识。
请参阅图 26, 图 26为本发明实施例中提供的另一种推送设备间的协作装 置的结构图。其中， 图 26所示的协作装置是对图 24所示的协作装置进行优化 得到的， 其中， 第二更新模块 2403可以包括：
第五处理单元 24031 , 用于接收网络侧网元发送的地址更新消息， 该地址 更新消息携带 Push客户端的网络内部标识以及网络侧网元感知的 Push客户端 的变化后的新地址；
其中， 网络侧网元为数据网关节点， 或 HLR, 或 HSS, 或 AAA服务器。 第六处理单元 24032, 用于根据上述的网络内部标识查询第二保存模块 2402保存的 Push客户端的 Push标识、 网络内部标识和地址的映射关系， 并 将新地址更新映射关系中对应的地址。
可选地， 图 26所示的协作装置中， 第二获取模块 2401 的结构可以与图 25中的第二获取模块 2401的结构相同， 本实施例不作限定。
如图 26所示， 本实施例提供的协作装置还可以包括：
第五控制模块 2404, 用于接收 Push服务器发送 Push消息， 该 Push消息 携带 Push客户端的 Push标识；
第六控制模块 2405 ,根据 Push客户端的 Push标识，从第二保存模块 2402 保存的 Push客户端的 Push标识、网络内部标识和地址的映射关系中获取 Push 客户端的网络内部标识；并将该 Push消息转换成 SMS消息或 WAP Push消息， 将转换后的消息发送给 SMSC或 WAP Push代理网关，其中，转换后的消息中 携带与 Push标识对应的网络内部标识。
本实施例提供的推送设备间的协作装置中， 第二保存模块 2402可以保存 上述的 Push客户端的 Push标识、 网络内部标识和地址的映射关系， 第二更新 模块 2403在 Push客户端的地址发生变化时，无需心跳操作即可及时地对其保 存的 Push客户端的地址进行更新， 从而能够提高 Push客户端的 IP连接的有 效性和可达性， 进而能够提高 Push消息的实时性和可靠性。 另外， 消除 Push 客户端和 Push服务器之间的心跳， 可以节省 Push客户端能量和网络侧资源。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可 以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存 储介质中， 该程序在执行时， 执行包括上述方法实施例的步骤； 而前述的存储 介质包括： 只读存储器（ROM ) 、 随机存取器（RAM ) 、 磁碟或者光盘等各 种可以存储程序代码的介质。
以上对本发明实施例所提供的一种推送设备间的协作方法及装置进行了 上实施例的说明只是用于帮助理解本发明的方法及其核心思想； 同时，对于本 领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会 有改变之处， 综上， 本说明书内容不应理解为对本发明的限制。

Claims

权 利 要 求
1、 一种推送设备间的协作方法， 其特征在于， 包括：
推送代理获取推送客户端的推送标识和地址；
推送代理保存所述推送客户端的推送标识和地址的映射关系；
若所述推送客户端的地址发生变化，则推送代理更新所述映射关系中对应 的地址。
2、 根据权利要求 1所述的方法， 其特征在于， 所述推送代理获取推送客 户端的推送标识和地址包括：
推送代理接收推送客户端发送的推送注册请求消息，所述推送注册请求消 息或其数据包头携带所述推送客户端的地址；
解析所述推送注册请求消息或其数据包头， 获得所述推送客户端的地址； 将所述推送注册请求消息发送至推送服务器；
接收所述推送服务器发送的推送注册请求响应消息 ,所述推送注册请求响 应消息携带所述推送服务器为所述推送客户端分配的推送标识；
解析所述推送注册请求响应消息， 获得所述推送客户端的推送标识。
3、 根据权利要求 1所述的方法， 其特征在于， 所述推送代理获取推送客 户端的推送标识和地址包括：
推送代理接收推送客户端发送的代理注册请求消息 ,所述代理注册请求消 息或其数据包头携带所述推送客户端的推送标识和地址；
解析所述代理注册请求消息或其数据包头 ,获得所述推送客户端的推送标 识和地址。
4、 根据权利要求 3所述的方法， 其特征在于， 所述推送客户端的推送标 识是所述推送客户端通过以下方式获得的：
推送客户端发送推送注册请求消息至推送服务器；
推送客户端接收所述推送服务器发送的推送注册请求响应消息，所述推送 注册请求响应消息携带所述推送服务器为所述推送客户端分配的推送标识； 推送客户端解析所述注册请求响应消息， 获得所述推送客户端的推送标 识。
5、 根据权利要求 1所述的方法， 其特征在于， 若所述推送客户端的地址 发生变化， 则推送代理更新所述映射关系中对应的地址包括：
推送代理接收网络侧网元发送的地址更新消息，所述地址更新消息携带所 述网络侧网元感知的所述推送客户端的原地址以及变化后的新地址；所述网络 侧网元为数据网关节点， 或归属位置寄存器 HLR, 或归属用户服务器 HSS, 或认证、 授权以及计费 AAA服务器；
根据所述原地址查询保存的所述推送客户端的推送标识和地址的映射关 系， 并将所述新地址更新所述映射关系中对应的地址。
6、 根据权利要求 5所述的方法， 其特征在于， 推送代理在接收网络侧网 元发送的地址更新消息之前， 还包括：
推送代理发送触发消息至网络侧网元，所述触发消息携带所述推送客户端 的地址 ,用于触发所述网络侧网元在感知到所述推送客户端的地址发生变化时 通知推送代理。
7、 根据权利要求 6所述的方法， 其特征在于， 所述推送代理与所述网络 侧网元位于同一设备上， 所述触发消息是通过内部触发机制发送的。
8、 根据权利要求 1所述的方法， 其特征在于， 若所述推送客户端的地址 发生变化， 则推送代理更新所述映射关系中对应的地址包括：
推送代理接收推送客户端发送的地址更新消息，所述地址更新消息携带所 述推送客户端的推送标识以及所述推送客户端感知的变化后的新地址；
根据所述推送客户端的推送标识查询保存的所述推送客户端的推送标识 和地址的映射关系， 并将所述新地址更新所述映射关系中对应的地址。
9、 根据权利要求 1〜8任一项所述的方法， 其特征在于， 还包括： 推送代理接收推送服务器发送推送消息 ,所述推送消息携带所述推送客户 端的推送标识；
推送代理根据所述推送客户端的推送标识，从保存的所述推送客户端的推 送标识和地址的映射关系中获取所述推送客户端的地址；
根据所述推送客户端的地址， 将所述推送消息发送至所述推送客户端。
10、 根据权利要求 9所述的方法， 其特征在于， 在将所述推送消息发送至 所述推送客户端之前， 还包括：
将所述推送消息转换格式以适应所述推送客户端的接口。
11、 根据权利要求 1所述的方法， 其特征在于， 还包括：
推送代理接收网络侧网元发送的地址释放消息，所述地址释放消息携带所 述网络侧网元感知的所述推送客户端的释放前地址；所述网络侧网元为数据网 关节点， 或归属位置寄存器 HLR, 或归属用户服务器 HSS , 或认证、 授权以 及计费 AAA服务器；
根据所述地址查询保存的所述推送客户端的推送标识和地址的映射关系 , 并标记所述映射关系中对应的地址为未获取或特殊值。
12、 根据权利要求 1所述的方法， 其特征在于， 还包括： 推送代理接收推送客户端发送的去注册请求消息 ,所述去注册请求消息至 少携带所述推送客户端的推送标识；
推送代理发送去注册请求响应消息至所述推送客户端，并删除保存的所述 推送客户端的推送标识和地址的映射关系。
13、 根据权利要求 1所述的方法， 其特征在于， 还包括：
推送代理接收推送客户端发送的去注册请求消息 ,所述去注册请求消息至 少携带所述推送客户端的推送标识；
将所述去注册请求消息发送至推送服务器；
接收所述推送服务器发送的去注册请求响应消息并发送至所述推送客户 端， 删除保存的所述推送客户端的推送标识和地址的映射关系。
14、 一种推送设备间的协作方法， 其特征在于， 包括：
推送代理获取推送客户端的推送标识、 网络内部标识和地址；
推送代理保存所述推送客户端的推送标识、网络内部标识和地址的映射关 系；
若所述推送客户端的地址发生变化，则推送代理更新所述映射关系中对应 的地址。
15、 根据权利要求 14所述的方法， 其特征在于， 所述推送代理获取推送 客户端的推送标识、 网络内部标识和地址包括：
推送代理接收推送客户端发送的推送注册请求消息，所述推送注册请求消 息或其数据包头携带所述推送客户端的地址；
解析所述推送注册请求消息或其数据包头， 获得所述推送客户端的地址； 根据所述地址查询网络侧网元获得所述推送客户端的网络内部标识 ,所述 网络侧网元为数据网关节点，或归属位置寄存器 HLR,或归属用户服务器 HSS, 或认证、 授权以及计费 AAA服务器；
将所述推送注册请求消息发送至推送服务器；
接收所述推送服务器发送的推送注册请求响应消息 ,所述推送注册请求响 应消息携带所述推送服务器为所述推送客户端分配的推送标识；
解析所述推送注册请求响应消息， 获得所述推送客户端的推送标识。
16、 根据权利要求 14所述的方法， 其特征在于， 所述推送代理获取推送 客户端的推送标识、 网络内部标识和地址包括：
推送代理接收推送客户端发送的代理注册请求消息 ,所述代理注册请求消 息或其数据包头中携带所述推送客户端的推送标识、 网络内部标识、 地址； 解析所述代理注册请求或其数据包头， 获得所述推送客户端的推送标识、 网络内部标识、 地址。
17、 根据权利要求 14所述的方法， 其特征在于， 所述推送代理获取推送 客户端的推送标识、 网络内部标识和地址包括：
推送代理接收网络侧网元发送的推送客户端入网通知 ,所述推送客户端入 网通知携带所述推送客户端的地址、 网络内部标识； 所述网络侧网元为数据网 关节点， 或归属位置寄存器 HLR, 或归属用户服务器 HSS, 或认证、 授权以 及计费 AAA服务器；
根据所述网络内部标识本地查询或者向用户信息数据库获取推送客户端 认证信息、 推送服务器地址， 并向推送服务器发送推送注册请求消息；
接收所述推送服务器发送的推送注册请求响应消息 ,所述推送注册请求响 应消息携带所述推送服务器为所述推送客户端分配的推送标识； 解析所述推送注册请求响应消息， 获得所述推送客户端的推送标识。
18、 根据权利要求 14所述的方法， 其特征在于， 若所述推送客户端的地 址发生变化， 则推送代理更新所述映射关系中对应的地址包括：
推送代理接收网络侧网元发送的地址更新消息，所述地址更新消息携带所 述推送客户端的网络内部标识以及所述网络侧网元感知的所述推送客户端的 变化后的新地址； 所述网络侧网元为数据网关节点， 或归属位置寄存器 HLR, 或归属用户服务器 HSS, 或认证、 授权以及计费 AAA服务器；
根据所述网络内部标识查询保存的所述推送客户端的推送标识、网络内部 标识和地址的映射关系， 并将所述新地址更新所述映射关系中对应的地址。
19、 根据权利要求 14〜17任一项所述的方法， 其特征在于， 还包括： 推送代理接收推送服务器发送推送消息 ,所述推送消息携带所述推送客户 端的推送标识；
推送代理根据所述推送客户端的推送标识，从保存的所述推送客户端的推 送标识、网络内部标识和地址的映射关系中获取所述推送客户端的网络内部标 识；
将推送消息转换成 SMS消息或 WAP Push消息， 并将转换后的消息发送 给 SMSC或 WAP Push代理网关，所述转换后的消息中携带与推送标识对应的 网络内部标识。
20、 一种推送设备间的协作装置， 其特征在于， 包括：
第一获取模块， 用于获取推送客户端的推送标识和地址；
第一保存模块， 用于保存所述推送客户端的推送标识和地址的映射关系； 第一更新模块， 用于在所述推送客户端的地址发生变化时， 更新所述映射 关系中对应的地址。
21、 根据权利要求 20所述的协作装置， 其特征在于， 所述第一获取模块 包括：
第一接收单元， 用于接收推送客户端发送的推送注册请求消息， 所述推送 注册请求消息或其数据包头携带所述推送客户端的地址；
第一解析单元， 用于解析所述推送注册请求消息或其数据包头， 获得所述 推送客户端的地址；
第一发送单元， 用于将所述推送注册请求消息发送至推送服务器； 所述第一接收单元，还用于接收所述推送服务器发送的推送注册请求响应 消息 ,所述推送注册请求响应消息携带所述推送服务器为所述推送客户端分配 的推送标识；
所述第一解析单元，还用于解析所述推送注册请求响应消息， 获得所述推 送客户端的推送标识。
22、 根据权利要求 20所述的协作装置， 其特征在于， 所述第一获取模块 包括：
第二接收单元， 用于接收推送客户端发送的代理注册请求消息， 所述代理 注册请求消息或其数据包头携带所述推送客户端的推送标识和地址；
第二解析单元， 用于解析所述代理注册请求消息或其数据包头， 获得所述 推送客户端的推送标识和地址。
23、 根据权利要求 20所述的协作装置， 其特征在于， 所述第一更新模块 包括：
第一处理单元， 用于接收网络侧网元发送的地址更新消息， 所述地址更新 消息携带所述网络侧网元感知的所述推送客户端的原地址以及变化后的新地 址； 所述网络侧网元为数据网关节点， 或归属位置寄存器 HLR, 或归属用户 服务器 HSS , 或认证、 授权以及计费 AAA服务器；
第二处理单元，用于根据所述原地址查询保存的所述推送客户端的推送标 识和地址的映射关系， 并将所述新地址更新所述映射关系中对应的地址。
24、 根据权利要求 23所述的协作装置， 其特征在于，
所述第二处理单元，还用于发送触发消息至网络侧网元， 所述触发消息携 带所述推送客户端的地址，用于触发所述网络侧网元在感知到所述推送客户端 的地址发生变化时通知所述第一处理单元。
25、 根据权利要求 20所述的协作装置， 其特征在于， 所述第一更新模块 包括：
第三处理单元， 用于接收推送客户端发送的地址更新消息， 所述地址更新 消息携带所述推送客户端的推送标识以及所述推送客户端感知的变化后的新 地址；
第四处理单元，用于根据所述推送客户端的推送标识查询保存的所述推送 客户端的推送标识和地址的映射关系 ,并将所述新地址更新所述映射关系中对 应的地址。
26、 根据权利要求 20〜25任一项所述的协作装置， 其特征在于， 还包括： 第一控制模块， 用于接收推送服务器发送推送消息， 所述推送消息携带所 述推送客户端的推送标识；
第二控制模块， 用于根据所述推送客户端的推送标识，从所述第一保存模 块保存的所述推送客户端的推送标识和地址的映射关系中获取所述推送客户 端的地址并通知所述第一控制模块；
所述第一控制模块，还用于根据所述推送客户端的地址，将所述推送消息 发送至所述推送客户端。
27、 根据权利要求 26所述的协作装置， 其特征在于，
所述第一控制模块， 还用于在将所述推送消息发送至所述推送客户端之 前， 先将所述推送消息转换格式以适应所述客户端的接口。
28、 根据权利要求 20所述的协作装置， 其特征在于， 还包括：
第三控制模块， 用于接收网络侧网元发送的地址释放消息， 所述地址释放 消息携带所述网络侧网元感知的所述推送客户端释放前的地址；所述网络侧网 元为数据网关节点， 或归属位置寄存器 HLR, 或归属用户服务器 HSS , 或认 证、 授权以及计费 AAA服务器；
第四控制模块，用于根据所述地址查询所述第一保存模块保存的所述推送 客户端的推送标识和地址的映射关系，并标记所述映射关系中对应的地址为未 获取或特殊值。
29、 根据权利要求 20所述的协作装置， 其特征在于，
所述第三控制模块，还用于接收推送客户端发送的去注册请求消息， 所述 去注册请求消息至少携带所述推送客户端的推送标识；
所述第四控制模块， 还用于发送去注册请求响应消息至所述推送客户端 , 并删除所述第一保存模块保存的所述推送客户端的推送标识和地址的映射关 系。
30、 根据权利要求 29所述的协作装置， 其特征在于，
所述第三控制模块，还用于接收推送客户端发送的去注册请求消息， 所述 去注册请求消息至少携带所述推送客户端的推送标识；
所述第四控制模块，还用于将所述去注册请求消息发送至推送服务器；接 收所述推送服务器发送的去注册请求响应消息并发送至所述推送客户端 ,并删 除所述第一保存模块保存的所述推送客户端的推送标识和地址的映射关系。
31、 一种推送设备间的协作装置， 其特征在于， 包括：
第二获取模块， 用于获取推送客户端的推送标识、 网络内部标识和地址； 第二保存模块， 用于保存所述推送客户端的推送标识、 网络内部标识和地 址的映射关系；
第二更新模块， 用于在所述推送客户端的地址发生变化时， 更新所述映射 关系中对应的地址。
32、 根据权利要求 31所述的协作装置， 其特征在于， 所述第二获取模块 包括：
第三接收单元， 用于接收推送客户端发送的推送注册请求消息， 所述推送 注册请求消息或其数据包头携带所述推送客户端的地址；
第三解析单元， 用于解析所述推送注册请求消息或其数据包头， 获得所述 推送客户端的地址；并根据所述地址查询网络侧网元获得所述推送客户端的网 络内部标识， 所述网络侧网元为数据网关节点， 或归属位置寄存器 HLR, 或 归属用户服务器 HSS , 或认证、 授权以及计费 AAA服务器；
第三发送单元， 用于将所述推送注册请求消息发送至推送服务器； 所述第三接收单元，还用于接收所述推送服务器发送的推送注册请求响应 消息，所述推送注册请求响应消息携带所述推送服务器为所述推送客户端分配 的推送标识； 所述第三解析单元，还用于解析所述推送注册请求响应消息， 获得所述推 送客户端的推送标识。
33、 根据权利要求 31或 32所述的协作装置， 其特征在于， 所述第二更新 模块包括：
第五处理单元， 用于接收网络侧网元发送的地址更新消息， 所述地址更新 消息携带所述推送客户端的网络内部标识以及所述网络侧网元感知的所述推 送客户端的变化后的新地址； 所述网络侧网元为数据网关节点， 或归属位置寄 存器 HLR, 或归属用户服务器 HSS, 或认证、 授权以及计费 AAA服务器； 第六处理单元，用于根据所述网络内部标识查询所述第二保存模块保存的 所述推送客户端的推送标识、 网络内部标识和地址的映射关系， 并将所述新地 址更新所述映射关系中对应的地址。
34、 根据权利要求 31或 32所述的协作装置， 其特征在于， 还包括： 第五控制模块， 用于接收推送服务器发送推送消息， 所述推送消息携带所 述推送客户端的推送标识；
第六控制模块，根据所述推送客户端的推送标识，从保存的所述推送客户 端的推送标识、网络内部标识和地址的映射关系中获取所述推送客户端的网络 内部标识； 并将推送消息转换成 SMS消息或 WAP Push消息， 并将转换后的 消息发送给 SMSC或 WAP Push代理网关，所述转换后的消息中携带与推送标 识对应的网络内部标识。
PCT/CN2011/074345 2010-07-30 2011-05-19 一种推送设备间的协作方法及装置 WO2011137792A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/753,833 US9247018B2 (en) 2010-07-30 2013-01-30 Method and apparatus for cooperation between push devices

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010244030.9 2010-07-30
CN201010244030.9A CN102347967B (zh) 2010-07-30 2010-07-30 一种推送设备间的协作方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/753,833 Continuation US9247018B2 (en) 2010-07-30 2013-01-30 Method and apparatus for cooperation between push devices

Publications (1)

Publication Number Publication Date
WO2011137792A1 true WO2011137792A1 (zh) 2011-11-10

Family

ID=44903602

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/074345 WO2011137792A1 (zh) 2010-07-30 2011-05-19 一种推送设备间的协作方法及装置

Country Status (3)

Country Link
US (1) US9247018B2 (zh)
CN (1) CN102347967B (zh)
WO (1) WO2011137792A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103139733A (zh) * 2011-11-25 2013-06-05 中国移动通信集团公司 通过短信拉起离线应用程序的系统与方法
CN103152374A (zh) * 2011-12-07 2013-06-12 华为终端有限公司 获知终端在线状态的方法与装置
CN106941509A (zh) * 2016-01-05 2017-07-11 阿里巴巴集团控股有限公司 用户信息流的请求方法及装置

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8099764B2 (en) * 2007-12-17 2012-01-17 Microsoft Corporation Secure push and status communication between client and server
GB201109312D0 (en) * 2011-06-03 2011-07-20 Vodafone Ip Licensing Ltd Machine to machine communications
US9295020B2 (en) * 2012-03-26 2016-03-22 Harris Corporation Systems and methods registration and maintenance of wireless clients via a proxy wireless network service
EP3015990B1 (en) * 2013-06-27 2018-08-08 Fujitsu Limited Information processing device, and destination information updating method and program
CN104468649B (zh) * 2013-09-16 2018-06-05 北大方正集团有限公司 服务器、终端、数据推送系统和数据推送方法
US9736256B2 (en) * 2014-02-13 2017-08-15 Microsoft Technology Licensing, Llc Implementing server push at server stack
CN104348905B (zh) * 2014-09-01 2016-09-14 腾讯科技（深圳）有限公司 一种离线推送消息的方法及装置
CN105814837B (zh) * 2014-11-19 2020-09-08 华为技术有限公司 一种定向统计流量的方法、设备及系统
GB2543312A (en) * 2015-10-14 2017-04-19 Smartpipe Tech Ltd Network identification as a service
CN105657000A (zh) * 2015-12-25 2016-06-08 北京奇虎科技有限公司 消息传送方法及装置
US10523565B2 (en) * 2016-08-25 2019-12-31 Ford Global Technologies, Llc Mobile device network address server update
JP6888266B2 (ja) * 2016-10-06 2021-06-16 富士通株式会社 表示制御方法、表示制御装置及び表示制御プログラム
CN113852695A (zh) * 2016-11-01 2021-12-28 鲸彩在线科技（大连）有限公司 一种信息推送方法及网络架构
CN106412138B (zh) * 2016-12-21 2019-11-19 广州四三九九信息科技有限公司 一种无标签精准推送的方法和设备
CN108337156B (zh) * 2017-01-20 2020-12-18 阿里巴巴集团控股有限公司 一种信息推送方法及装置
CN108881354B (zh) * 2017-05-09 2021-11-09 腾讯科技（深圳）有限公司 一种推送信息存储方法、装置、服务器和计算机存储介质
CN108989264B (zh) * 2017-05-31 2020-04-03 华为技术有限公司 一种直播方法、系统以及相关设备
CN109819285B (zh) * 2017-11-21 2021-09-21 北京乐我无限科技有限责任公司 一种直播方法、装置、电子设备及存储介质
US11126610B1 (en) 2017-11-22 2021-09-21 Amazon Technologies, Inc. Conflict resolution in a data proxy
US11089133B1 (en) 2017-11-22 2021-08-10 Amazon Technologies, Inc. Synchronizing data with delayed subscriptions
US11159634B1 (en) * 2017-11-22 2021-10-26 Amazon Technologies, Inc. Subscription fan out
US10891282B1 (en) 2017-11-22 2021-01-12 Amazon Technologies, Inc. Mutations with immediate feedback
CN109905312B (zh) * 2017-12-08 2021-07-23 北京新媒传信科技有限公司 消息推送方法、装置及系统
CN112136305A (zh) * 2018-03-23 2020-12-25 欧庞戈网络有限公司 虚拟联网环境中的协调数据共享
CN112615938B (zh) * 2020-12-30 2022-11-04 四川巧夺天工信息安全智能设备有限公司 一种基于tcp的物联网客户端的跨平台协同工作方法
US12058755B1 (en) * 2024-03-25 2024-08-06 Relay, Inc. Techniques for connecting a disconnected wireless device to a cloud-based communications server via a proxy device

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1801764A (zh) * 2006-01-23 2006-07-12 北京交通大学 一种基于身份与位置分离的互联网接入方法
CN101222414A (zh) * 2007-01-11 2008-07-16 华为技术有限公司 实现组播通信的装置、系统和方法
CN101730101A (zh) * 2009-04-15 2010-06-09 中兴通讯股份有限公司 身份标识与位置分离的实现方法、系统及装置

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI108195B (fi) * 1998-10-19 2001-11-30 Nokia Networks Oy Mekanismi verkon aloittamaa informaation siirtoa varten
AUPR459901A0 (en) * 2001-04-27 2001-05-24 Sharinga Networks Inc. Instant messaging
US6885861B2 (en) * 2001-08-24 2005-04-26 Nokia Corporation Service mobility and recovery in communication networks
EP1421810B1 (en) * 2001-08-29 2007-10-31 Research In Motion Limited System and method for addressing a mobile device in an ip-based wireless network
US7254614B2 (en) * 2001-11-20 2007-08-07 Nokia Corporation Web services push gateway
EP1461741A4 (en) * 2001-12-06 2006-03-29 Access Co Ltd SYSTEM AND METHOD FOR PROVIDING SUBSCRIPTION SERVICES FOR MOBILE DEVICES
US7289462B1 (en) * 2001-12-26 2007-10-30 Nortel Networks Limited Method and apparatus for network-initiated context activation using dynamic DNS updates
US6985479B2 (en) * 2002-03-04 2006-01-10 Qualcomm Incorporated Method and apparatus for processing internet protocol transmissions
US20030210678A1 (en) * 2002-05-10 2003-11-13 Nokia Corporation Functionality split between mobile terminal and terminal equipment for internet protocol multimedia signal exchange
US7640300B2 (en) * 2002-06-10 2009-12-29 Microsoft Corporation Presence and notification system for maintaining and communicating information
US20040185888A1 (en) * 2003-03-18 2004-09-23 Nokia Corporation Solving mobile station identity in a multi-SIM situation
US7177628B2 (en) * 2003-03-21 2007-02-13 Motorola, Inc. Method for enabling IP push capability to wireless devices on a wireless network
US7769866B2 (en) * 2003-07-14 2010-08-03 Microsoft Corporation Virtual connectivity with subscribe-notify service
US7324474B2 (en) * 2003-10-21 2008-01-29 Qualcomm Incorporated Methods and apparatus for Network Initiated Data Services
US8856346B2 (en) * 2004-01-15 2014-10-07 Unwired Planet, Llc Stateful push notifications
KR100842589B1 (ko) * 2004-01-29 2008-07-01 삼성전자주식회사 고속 데이터 전송을 위한 이동통신 시스템에서 이동단말에 대한 푸시 서비스 제공 방법과 이를 위한 푸시서버 장치
SE527871C2 (sv) * 2004-03-09 2006-06-27 Ericsson Telefon Ab L M Metod och system för hantering av webbtjänster
US8085741B2 (en) * 2004-03-10 2011-12-27 Core Wireless Licensing S.A.R.L. System and method for pushing content to a terminal utilizing a network-initiated data service technique
CN100345425C (zh) 2004-05-25 2007-10-24 中国移动通信集团公司 从信息系统向移动终端推送信息的方法及系统
FI20041634A0 (fi) * 2004-12-20 2004-12-20 Nokia Corp Tarjontaistunnon muodostaminen kommunikaatiojärjestelmässä
WO2006109202A1 (en) 2005-04-11 2006-10-19 Nokia Corporation Method and entities for performing a push session in a communication system
US8060554B2 (en) * 2005-04-18 2011-11-15 Research In Motion Limited System and method for enabling asynchronous push-based applications on a wireless device
CN101163157A (zh) 2007-10-30 2008-04-16 华为技术有限公司 一种离线推送实现方法、系统及无线应用协议网关
CN101437202B (zh) * 2007-11-13 2010-08-25 华为技术有限公司 一种多终端时业务消息处理方法、系统和装置
US8099764B2 (en) * 2007-12-17 2012-01-17 Microsoft Corporation Secure push and status communication between client and server
US20100138501A1 (en) * 2008-12-03 2010-06-03 Microsoft Corporation End-to-end validation in a push environment
US8064896B2 (en) * 2009-03-09 2011-11-22 Apple Inc. Push notification service
EP2254309A1 (en) * 2009-05-20 2010-11-24 Thomson Licensing Method for sending data of a service
EP2320376A1 (en) * 2009-11-06 2011-05-11 Research In Motion Limited Method, system and apparatus for management of push content when changing computing devices

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1801764A (zh) * 2006-01-23 2006-07-12 北京交通大学 一种基于身份与位置分离的互联网接入方法
CN101222414A (zh) * 2007-01-11 2008-07-16 华为技术有限公司 实现组播通信的装置、系统和方法
CN101730101A (zh) * 2009-04-15 2010-06-09 中兴通讯股份有限公司 身份标识与位置分离的实现方法、系统及装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103139733A (zh) * 2011-11-25 2013-06-05 中国移动通信集团公司 通过短信拉起离线应用程序的系统与方法
CN103139733B (zh) * 2011-11-25 2015-12-09 中国移动通信集团公司 通过短信拉起离线应用程序的系统与方法
CN103152374A (zh) * 2011-12-07 2013-06-12 华为终端有限公司 获知终端在线状态的方法与装置
WO2013082960A1 (zh) * 2011-12-07 2013-06-13 华为终端有限公司 获知终端在线状态的方法与装置
CN103152374B (zh) * 2011-12-07 2016-08-10 华为终端有限公司 获知终端在线状态的方法与装置
US9699050B2 (en) 2011-12-07 2017-07-04 Huawei Device Co., Ltd. Method and apparatus for learning online state of terminal
CN106941509A (zh) * 2016-01-05 2017-07-11 阿里巴巴集团控股有限公司 用户信息流的请求方法及装置
CN106941509B (zh) * 2016-01-05 2020-06-30 阿里巴巴集团控股有限公司 用户信息流的请求方法及装置

Also Published As

Publication number Publication date
US9247018B2 (en) 2016-01-26
CN102347967B (zh) 2014-01-01
US20130144954A1 (en) 2013-06-06
CN102347967A (zh) 2012-02-08

Similar Documents

Publication Publication Date Title
US9247018B2 (en) Method and apparatus for cooperation between push devices
US11729615B2 (en) Internet of things communication method, apparatus, and system
WO2022206260A1 (zh) 地址信息发送方法、获取方法、装置、设备及介质
US9307039B2 (en) Method, system, push client, and user equipment for service communication
JP5793812B2 (ja) データオフロードをトリガするための方法、ネットワーク側デバイス、ユーザ機器、およびネットワークシステム
US20210243170A1 (en) Methods for processing encrypted domain name server, dns, queries received from user equipment in a telecommunication network
US9565635B2 (en) Activating a mobile terminal from mobile network side
US8943572B2 (en) Method for accessing a storage server of an IM service system, and an IM service system
WO2013107163A1 (zh) 一种设备切换方法、m2m平台和网络系统
WO2011144134A1 (zh) 一种信息推送方法、装置和系统
KR20090008314A (ko) Ｓｍｓ 메시지의 전달 방법 및 시스템
EP3815401A1 (en) Security management for service access in a communication system
WO2021212939A1 (zh) 通信方法、装置及系统
WO2014023175A1 (zh) 一种终端多外部标识共存下的消息处理方法、网络侧设备
US20240097933A1 (en) Policy control function fallback
US11381955B2 (en) Methods, systems, and computer readable media for monitoring machine type communications (MTC) device related information
EP2759098B1 (en) Method and apparatus for configuring service settings for a mobile subscriber
JP2024511907A (ja) ネットワーク機能登録方法、発見方法、装置、デバイス及び媒体
JP7546154B2 (ja) Ｐｇｗ失敗におけるｐｄｎ接続の復元
WO2011110022A1 (zh) 数据的传输方法、装置及系统
WO2014063578A1 (zh) 一种短消息信令优化方法、设备和系统
WO2012088828A1 (zh) 表维护方法、系统和接入网关路由器
WO2024195282A1 (ja) コアネットワークノード、データ生成方法、プログラム及び通信システム
KR20220118273A (ko) 에지 어플리케이션 서버 디스커버리 방법 및 장치
WO2013097194A1 (zh) 一种业务触发方法、系统和设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11777211

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11777211

Country of ref document: EP

Kind code of ref document: A1