HK1178017A - System and method for pushing content to a terminal utilizing a network-initiated data service technique - Google Patents

Description

System and method for pushing content to a terminal using network-initiated data service techniques

The present application is a divisional application of chinese patent application 200580001281.1 entitled "system and method for pushing content to a terminal using a network-initiated data service technology", filed 3/2005.

Technical Field

The present invention relates generally to a system and method for pushing content to a terminal and, more particularly, to pushing content to a terminal using both network-initiated data session technology and Session Initiation Protocol (SIP).

Background

The modern communications era has led to a tremendous expansion of wireline and wireless networks. Computer networks, television networks, and telephony networks have experienced unprecedented technological expansion due to consumer demand. Wireless and mobile networking technologies address the associated consumer demands while providing more flexibility and rapidity in information transfer.

Current and future networking technologies continue to facilitate ease of information transfer and convenience to users. The proliferation of local, regional, and global networks such as the internet is beneficial for delivering large amounts of information to society. These networking technologies are expanding to increasingly include wireless and mobile technologies. Through these networks, information may be downloaded to desktop systems, wireless systems, mobile systems, and the like. For example, information available via the internet can now be downloaded onto mobile wireless units, such as cellular telephones, Personal Digital Assistants (PDAs), laptop computers, and the like.

The second generation wireless services, commonly referred to as 2G wireless services, are current wireless services based on circuit-switched technology. In this regard, 2G systems such as global system for mobile communications (GSM) use wireless technology for improved quality and wider service range over first generation mobile technologies. The third generation wireless service, commonly referred to as 3G wireless service, refers to a set of digital technologies that ensure capacity, speed, and efficiency improvements by adopting a new packet-based transmission method between a terminal and a network. Users of 3G devices and networks can access multimedia services such as video-on-demand, video conferencing, fast web access, and file transfer. Existing and future services are, and will continue to be, provided by network service operators who make services and applications available to mobile device users through a network.

One particular service feature currently available for transmitting information is a "push" feature (also referred to as a "notify" feature or an "alert" feature). In a typical client/server model, a client requests a service or information from a server, which then responds to the client with the transmitted information. This is commonly referred to as a "pull" technique, in which a client pulls information from a server. For example, entering a Uniform Resource Locator (URL) at the client device, and then sending the input to the server to retrieve the relevant information is a pull transaction.

In contrast, "push" technology generally refers to a device transmitting information to one or more devices without prior user action. Thus, there is no explicit request from the client before the server transmits the information, so the push technique actually involves a server-initiated transaction. Push technology can be used with a variety of protocols and communication technologies. For example, some representative push technologies include Short Message Service (SMS), Wireless Application Protocol (WAP) push, Multimedia Messaging Service (MMS), Session Initiation Protocol (SIP), and others.

While conventional push techniques are adequate for pushing content to a client, such techniques have certain drawbacks. Consider a private network that includes, is connected to, or is associated with a mobile network such as a General Packet Radio Service (GPRS) network. In this case, a client, e.g., a mobile terminal, communicating across the mobile network is typically able to initiate a communication session (e.g., a SIP communication session) with a server across a Network Address Translator (NAT) located between the client and the server, e.g., in accordance with a "pull" technique. As should be appreciated, the NAT can translate a client's private IP address into a public IP address recognizable by the server. However, a server is typically unable to initiate a similar communication session with a client across a NAT, e.g., according to "push" techniques. In this regard, clients within private and cellular networks typically lack static and public identities such as fixed IP addresses, and as such, servers are typically unable to identify the desired client to the NAT.

Mobile networks are typically configured in a manner that prevents a server from initiating a SIP communication session with a corresponding client for some reason. First, depending on the network topology, allowing IP connections to clients within the network may consume an undesirable amount of resources, or reduce network performance, even if there is no IP-traffic across the network. Secondly, in a network, just as in many private networks, there may be more clients than IP-addresses available. As such, the network may include a NAT, dynamically assigned IP addresses, and/or private IP addresses. Third, the security requirements and policies of many networks require that different IP-traffic be prevented from entering the network. Such a situation often leads to the use of NAT, especially when the mobile network includes an associated firewall/gateway.

To overcome the disadvantages of NAT, allowing a server to initiate a communication session with a client according to a "push" technique, the network can be configured so that each client has a unique fixed IP address, which are entered into a corresponding Domain Name System (DNS) server. The NAT of the network, as well as any security components (e.g., firewall/gateway, etc.), can also be configured to allow the server to initiate a communication session with the client and to allow traffic to be routed to and from the IP address assigned to the client. Further, for example, when the client connects to the network, network technology specific resources required for IP connectivity with each client within the network can be allocated.

However, this technique of allowing the server to push content to the client ignores the restrictions on the public network that result in the use of the NAT component. That is, this technique ignores the limitation of available public IP addresses. Again, this technique ignores the ability of the NAT component to communicate with a firewall/gateway that provides security functions. It is therefore desirable to design a system that can allow a server to push content to a client in a mobile or private network using network-initiated communication session technology, and that maintains firewall and/or gateway functionality to the respective network, taking into account the limited address space of the public network.

Summary of The Invention

In light of the foregoing background, embodiments of the present invention provide an improved system and method for pushing content to a terminal, typically a mobile terminal having an associated private IP address, using a network-initiated data session technique. In contrast to conventional techniques for pushing content to a terminal, embodiments of the present invention allow a network-initiated data session to be established with the terminal from a network node directly across a public network from the terminal. More particularly, embodiments of the present invention allow a network node to establish a network-initiated data session with a terminal in a manner that accounts for a limited number of available public IP addresses and maintains firewall and/or gateway functionality to a mobile network that includes the terminal.

According to one aspect of the present invention, a system for pushing content to a terminal located in a mobile network or a private network is provided. The system includes a network node, such as a Session Initiation Protocol (SIP) proxy, that is directly across a public network from a network that includes the terminal. The network node can subscribe to a push service on behalf of the terminal, so that the network node can also receive push content according to the push service. Thereafter, the network node can establish a network-initiated data session with the terminal. For example, the network node can send a trigger to the terminal independent of the public network, thereby triggering the terminal to register with the network node and establish a network-initiated data session. The network node can further register the terminal in response to the network initiating the data session, such that the terminal can receive the push content according to the registration.

More specifically, the network node can receive the push content and thereafter store the push content in a buffer. In such an instance, the network node can send the push content from the buffer to the terminal. Alternatively, the network node can register the terminal, so that the terminal can subscribe to the push service according to the registration. In such an instance, the terminal can receive the push content according to a push service to which the terminal subscribes.

The network node is capable of receiving a registration message from the terminal across the public network, thereby identifying the terminal across the public network and registering the terminal. For example, the network node can receive a registration message from the terminal through a Network Address Translator (NAT) and/or Firewall (FW) located between the network node and the terminal. In such instances, the network node can establish the network-initiated data session in a manner independent of the NAT and/or FW. The network node may additionally or alternatively be capable of registering the terminal so that the terminal can receive push content based on the identity of the terminal across the public network.

According to another aspect of the invention, a terminal and a method for pushing content to the terminal are provided. Accordingly, embodiments of the present invention provide an improved system and method for pushing content to a terminal using network-initiated data session techniques. Embodiments of the present invention allow a terminal (i.e., a terminal node) to subscribe to a push service and thereafter receive content from the push service without the need for an additional or many additional public IP addresses. Embodiments of the present invention further allow a network node to establish a network-initiated data session with a terminal without excluding firewall and/or gateway functionality that would otherwise be provided, for example, by a FW to a mobile network including the terminal. Accordingly, the system and method of embodiments of the present invention solve the problems identified by prior techniques and provide additional advantages.

Brief description of the drawings

Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:

FIG. 1 is a schematic block diagram of a communication system, including a public network and a mobile network, to which an originating node and a terminating (terminating) node are bidirectionally coupled, directly or indirectly, in accordance with one embodiment of the present invention;

fig. 2 is a schematic block diagram of an entity acting as a SIP client according to an embodiment of the present invention;

FIG. 3 is a schematic block diagram of a mobile station that functions as a SIP client in accordance with an embodiment of the present invention;

FIG. 4A is a control flow diagram illustrating in greater detail a method of pushing content to a terminal in accordance with one embodiment of the invention;

fig. 4B is a control flow diagram illustrating a method of pushing content to a terminal in more detail according to another embodiment of the present invention.

Detailed description of the invention

The present invention will now be described in detail with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements.

Referring to fig. 1, one type of system that would benefit from the present invention is provided. The system and method of embodiments of the present invention will be primarily described in conjunction with mobile communications applications. It should be understood, however, that the system and method of embodiments of the present invention can be utilized in conjunction with a variety of other applications, both in the mobile communications industries and outside of the mobile communications industries.

As shown, the system 10 includes a public network 12, such as a public Internet Protocol (IP) network like the Internet. The public network includes a plurality of network nodes, each typically including a processing element such as a server computer, personal computer, laptop computer, or the like. More specifically, the public network may include one or more network nodes, including fixed terminals 14, each of which is capable of communicating within or across the public network. The network nodes of the public network 12 may also include proxies 16, such as Session Initiation Protocol (SIP) proxies. Although not shown, the network nodes of the public network may also include a SIP registrar (registry). In this regard, the registrar may be implemented within a SIP proxy, as is well known to those skilled in the art. As can be appreciated, a call model such as SIP provides an application layer signaling protocol that involves multimedia sessions (see, for example, IETF request for comments document RFC 3261, entitled SIP: Session initiation protocol, month 6 2002, the contents of which are incorporated herein in their entirety). The SIP proxy is thus capable of receiving and forwarding SIP signaling messages, such as SIP signaling messages to and/or from network nodes including fixed terminals serving as the originating node 20, as explained in detail below. The public network may also include one or more Domain Name System (DNS) servers 18. In this regard, each network node typically has a unique IP address with an associated host DNS name that is typically easier to invoke. The DNS server can then translate the host DNS name into an associated IP address so that network traffic can be routed to the appropriate network node.

In addition to the public network 12, the system 10 includes one or more private networks 24, such as a Local Area Network (LAN). Each private network, like a public network, can include a plurality of network nodes. Also as with the public network 12, the network nodes of each private network may include one or more DNS servers 26. Similar to the foregoing, the DNS servers of the private network can translate the host DNS name into an associated IP address so that network traffic can be routed to the appropriate public or network node. The private network may also include one or more network nodes including mobile terminals 32, each of which is capable of communicating within or across the private network. The terminal 32 may include, for example, a mobile telephone, Portable Digital Assistant (PDA), pager, laptop computer, smart card, and other types of electronic systems.

To facilitate access to the private network by the terminal 32, the private network 24 may include one or more wireless Access Points (APs) (not shown), each coupled to one or more terminals. In this regard, the AP may comprise an access point configured to communicate with the terminals in accordance with techniques such as, for example, Radio Frequency (RF), Bluetooth (BT), infrared (IrDA) or any number of different wireline and/or wireless networking techniques, including LAN and/or WLAN techniques. Also similar to the public network, the private network may include an originating node 20, which will be described in detail below. As described below, the private network may include a terminating node 36 that is capable of communicating with an originating node. As described below, one or more terminals of the private network can function as an originating node or a terminating node.

To facilitate communication between the network nodes of the public network 12 and the network nodes of the private network 24, each private network may further include a Network Address Translator (NAT) interconnecting the public network and the private network. As explained in the background section, each NAT can translate a public IP address from a public network into a private IP address of a network node of a corresponding private network, and vice versa, for communication between the public network and the corresponding private network. As can be appreciated, the NAT can also include an Application Layer Gateway (ALG) (not shown) that can translate IP addresses embedded within, for example, application Protocol Data Units (PDUs). The NAT may also include or be associated with a firewall and/or gateway for the corresponding private network. As shown, the NAT that includes or is associated with the firewall/gateway is then shown as NAT/FW 28.

The system 10 may also include one or more mobile or cellular networks 30. The cellular network may include one or more of a plurality of different mobile networks. In this regard, the cellular network may comprise any of a first generation (1G), a second generation (2G), a 2.5G, and/or a third generation (3G) cellular network, and/or any of the cellular networks capable of operating in accordance with embodiments of the present invention. For example, each cellular network may include a GSM (Global System for Mobile communications), IS-136 (time division multiple Access-TDMA), IS-95 (code division multiple Access-CDMA), or EDGE (enhanced data GSM Environment) network. Alternatively, one or more of the cellular networks may comprise GPRS (general packet radio service) or GPRS-based networks (e.g., universal mobile telecommunications system-UMTS).

Similar to the public and private networks 12, 24, the cellular network 30 also includes one or more network nodes. In this regard, the network nodes of each cellular network may include one or more mobile terminals 32 capable of communicating within and/or across the respective cellular network. As described below, one or more of the mobile terminals can function as the originating node 20, e.g., in the same manner as the originating nodes of public and private networks. In addition, as also described below, one or more of the mobile terminals can serve as a terminating node 38 that can communicate with the originating node via the SIP proxy 16 in accordance with SIP, as described above and below.

Within the cellular network 30, the network nodes can also include one or more network signaling support nodes, such as one or more SGSNs (signaling GPRS support nodes) 38, and one or more gateway support nodes, such as one or more GGSNs (gateway GPRS support nodes) 40. For example, the network nodes may include one or more SGSNs and one or more GGSNs, as described in various specifications of the 3G partnership project (3 GPP). As will be appreciated by those skilled in the art, the SGSN is capable of routing communications to and from the mobile terminal 32 and also of providing connections to other network nodes while the terminal is engaged in a communication session with such network nodes. On the other hand, the GGSNs are capable of interconnecting the cellular network and the private network 24. In this regard, the GGSN can perform conventional gateway actions, as is known. It should be noted that although the cellular network may include SGSNs and GGSNs, the cellular network may also include network nodes that operate similarly for other types of cellular networks.

Referring now to fig. 2, a block diagram of entities that can be used as network nodes (e.g., SIP proxy 16, originating node 20, NAT/FW28, terminating node 36, SGSN38, GGSN40, etc.) within public network 12, private network 24, or cellular network 30 is shown, in accordance with one embodiment of the present invention. Although shown as separate entities, in some embodiments one or more entities may support one or more network nodes that are logically separate but co-exist within the entity. For example, a single entity can support logically separate but co-existing originating nodes and SIP proxies. Also, for example, as described above, a single entity can support logically separate but co-located NATs and firewalls/gateways.

As shown, the entities capable of functioning as network nodes may generally include a controller 42, a processor, etc. connected to a memory 44. The controller may also be connected to at least one interface 46 or other means for transmitting and/or receiving data, content or the like. The memory may include volatile and/or nonvolatile memory, typically for storing data, content or the like. For example, the memory typically stores software applications, instructions or the like for the controller to perform steps associated with operation of the entity in accordance with embodiments of the present invention. Also for example, the memory typically stores content transmitted from or received by the network node.

Fig. 3 shows a functional block diagram of a mobile station capable of operating as a mobile terminal 32 and thus also as an originating node 20 or a terminating node 36 in accordance with an embodiment of the present invention. It should be understood that the mobile station illustrated and hereinafter described is merely illustrative of one type of mobile station that would benefit from the present invention and, therefore, should not be taken to limit the scope of the present invention. While several embodiments of the mobile station are illustrated and will be hereinafter described as examples, other types of mobile stations, such as Portable Digital Assistants (PDAs), pagers, laptop computers and other types of voice and text communications systems, can readily employ the present invention.

The mobile station includes a transmitter 48, a receiver 50, and a controller 52 that provides signals to and receives signals from the transmitter and receiver. These signals include signaling information in accordance with the air interface standard of the cellular system being used, as well as user speech and/or user generated data. In this regard, the mobile station can be capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. More particularly, the mobile terminal may be capable of operating in accordance with any of a number of 1G, 2G, 2.5G and/or 3G communication protocols or the like. For example, the mobile station can operate in accordance with 2G wireless communication protocols IS-136(TDMA), GSM, and IS-95 (CDMA). Also, for example, the mobile station can be capable of operating in accordance with 2.5G wireless communication protocols GPRS, Enhanced Data GSM Environment (EDGE), or the like. Some narrow-band AMPS (NAMPS), as well as TACS, mobile stations may also benefit from embodiments of the present invention, as should dual or higher mode mobile stations (e.g., digital/analog or TDMA/CDMA/analog phones).

It should be understood that the controller 52 includes the circuitry required for implementing the audio and logic functions of the mobile station. For example, the controller may be comprised of a digital signal processor device, a microprocessor device, and various analog to digital converters, digital to analog converters, and other support circuits. The control and signal processing functions of the mobile station are allocated between these devices according to their respective capabilities. The controller thus also includes the functionality to convolutionally encode and interleave message and data prior to modulation and transmission. The controller may also include an internal Voice Coder (VC)52A and may include an internal Data Modem (DM) 52B. The controller can also include the functionality to run one or more software applications, which may be stored in memory.

The mobile station also comprises a user interface including a general earphone or speaker 54, a ringer 56, a microphone 60, a display 62, and a user input interface, all of which are coupled to the controller 52. The user input interface, which allows the mobile station to receive data, may include any number of devices allowing the mobile station to receive data, such as a keypad 64, a touch screen (not shown) or other input device. In embodiments including a keypad, the keypad includes conventional numbers (0-9) and associated keys (#, #), as well as other keys for operating the mobile station.

Although not shown, the mobile station may further include an IrDA transceiver or other local data transfer device so that data may be shared with and/or obtained from other devices, such as other mobile stations, car navigation systems, personal computers, printers, printed materials including barcodes, and the like. Sharing of data, as well as remote sharing of data, may also be provided according to a number of different techniques. For example, the mobile station may include a Radio Frequency (RF) transceiver capable of sharing data with other RF transceivers and/or having a Radio Frequency Identification (RFID) transponder (transponder) tag, as known to those skilled in the art. Additionally, or alternatively, the mobile station may share data using BT radio technology developed by the bluetooth special interest group. Further, the mobile stations can share data in accordance with any of a number of different wireline and/or wireless networking techniques, including LAN and/or WLAN techniques.

The mobile station may also include memory, such as a Subscriber Identity Module (SIM)66, a replaceable user identity module (R-UIM), or the like, which typically stores information elements related to a mobile subscriber. In addition to the SIM, the mobile station includes other memory. In this regard, the mobile station can include volatile memory 68 as well as other non-volatile memory 70, which can be embedded and/or removed. For example, other non-volatile memory may include embedded or removable Multimedia Memory Cards (MMCs), memory sticks manufactured by Sony corporation, EEPROM, flash memory, hard disks, and the like. The memories can store any of a number of pieces of information, and data, used by the mobile station to implement the functions of the mobile station. For example, the memories can store an identifier, such as an International Mobile Equipment Identification (IMEI) code, International Mobile Subscriber Identification (IMSI) code, Mobile Station Integrated Services Digital Network (MSISDN) code, or the like, capable of uniquely identifying the mobile station. The memory can also store content such as that sent to the originating node 20 or received from the originating node 20.

As mentioned in the background section, conventional techniques for allowing an originating node 20 to push content to an terminating node 36, such as a mobile terminal, ignore the limitations of public domains like the public network 12 (e.g., the internet), which result in the use of a NAT/FW28 to interconnect the public network with a corresponding private network 24. That is, this technique ignores the limitation of available public IP addresses. Again, this technique ignores the ability of the NAP/FW to provide firewall and/or gateway functionality to the corresponding private network. Accordingly, embodiments of the present invention provide an improved system and method for pushing content to an end node, where the end node resides in a private or cellular (i.e., mobile network). More particularly, embodiments of the present invention provide a system and method that allows an originating node to push content to an end node using a network-initiated data session technique that takes into account a public domain limited address space. Further, the system and method can, but need not, allow an originating node to push content to a terminating node while maintaining firewall and/or gateway functionality to the mobile network. As described below, the originating node initiates communication with a terminating node, including a terminal within the cellular network 30. It should be understood, however, that the end node may alternatively comprise a network node of a private network without departing from the spirit and scope of the present invention.

As is well known to those skilled in the art, SIP is an application-layer control protocol that enables the establishment, modification, and termination of multimedia sessions or calls. SIP is text-based, using ISO 10646 with UTF-8 encoded throughput. The syntax of this message is similar to HTTP, except SIP can carry transactions using User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). SIP messages, which can be generally characterized as requests or responses, can be created following the format in the following document, Internet Engineering Task Force (IETF) request for comments document RFC 822, the name of which is: standard for the Format of ARPA Internet Text Messages, 8.1982, the contents of which are incorporated herein by reference in their entirety.

Generally, the entities involved in a SIP session include a user agent (e.g., originating node 20, terminating node 36, etc.), SIP proxy 16, registrar, and location service. The user agent may act as a client (UAC) that initiates SIP requests. The user agent may also act as a server (UAS) that contacts the user when a SIP request is received and sends a response back on behalf of the user. As described above, a SIP proxy includes an intermediate entity that can act as both a client and a server. In this regard, the SIP proxy can interpret and modify the SIP request before forwarding it to other servers. As shown, the registrar can be implemented within the SIP proxy, accepting user registrations (e.g., registration (REGISTER) messages), and making this information available through a location service, as well as within the SIP proxy. The location service then comprises elements that the SIP proxy uses to obtain information about the possible locations of the terminating node.

A SIP message typically includes a start line, one or more header fields, an empty line (carriage return line-CRLF), and an optional body. Typically, the start line of a SIP message indicates whether the message is a request (e.g., INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, REFER, etc.) or a response (e.g., 100 info (information), 200 success, 300 redirection, 400 client error, 500 server error, 600 global failure, etc.). The message header may include a number of headers indicating, for example, the source ("From:"), the destination ("To:"), the Call identifier ("Call-ID:"), the message order ("Cseq:"), the Contact ("Contact:"), the transaction path ("Via:"), the Length ("Content-Length:"), and if carried in the message, the Content of the subject ("Content-Type:"). Alternatively, the message body may include any number of different types of data, the interpretation of which is typically dependent on the message type. Typically, the body content may contain a session description following a particular format, such as Session Description Protocol (SDP), text, or extensible markup language (XML) scripts. In this regard, the "Content-Type" header field gives the media Type of the message body. If the body is encoded, such Encoding is typically indicated in the "Content-Encoding" header field, and the body Length is typically given in the "Content-Length" header field.

SIP addressed entities may include users accessed through SIP proxies 16 supporting such users, where the users may be identified by SIP Uniform Resource Locators (URLs). Typically, a SIP URL may be used within a SIP message To indicate, for example, the originator (From), the current destination within the starting line (request URL), and the final recipient of the SIP request (To). As can be appreciated, the URL may take a form such as usershot, where "user" typically identifies the user (e.g., user name, telephone number, etc.) and "hot" identifies the SIP proxy supporting the user (e.g., domain name, IP address, etc.). In this regard, SIP URLs may be used to locate users based on the domain name to IP address translation of DNS server 18, particularly when the URL includes the domain name of the corresponding SIP proxy. In this regard, the initiator can query a DNS server that includes a destination address that includes a domain name of the SIP proxy.

As described above, the system 10 may include an originating node 20 and a terminating node 36. Typically, the terminating node can subscribe to a push service of the originating node, such as a SIP push service, so that the originating node can then push content to the terminating node via the SIP proxy 16 supporting the terminating node. As known to those skilled in the art, the SIP proxy can forward SIP signaling messages from the originating node to the terminating node and vice versa. However, in contrast to conventional SIP communication techniques, when the terminating node is located behind the NAT/FW28 from the perspective of the originating node, the SIP proxy is unable to identify the terminating node across the NAT/FW when the originating node desires to initiate a SIP communication session with the terminating node. More particularly, the SIP proxy is unable to identify the terminating node, for example, when the NAT/FW no longer maintains translation table entries for the terminating node, or the SIP proxy no longer maintains a registration for a public IP address and a port assigned to the terminating node by the NAT/FW.

The terminating node can then instruct the SIP proxy 16 to subscribe to the push service of the originating node 20 on behalf of the terminating node, according to an embodiment of the present invention. The originating node can then provide the push service to the SIP proxy on behalf of the terminating node. The SIP proxy, in turn, can communicate with the terminating node across the NAT/FW28 using network-initiated data session techniques to deliver the push content to the terminating node. The SIP proxy can initiate a data session with the terminating node using any of a number of different networks, thereby initiating communication with the terminating node so that the SIP proxy can send the push content to the terminating node. For example, the SIP proxy can use the SIP proxy according to the third generation partnership project 2(3GPP) specification 3GPP2 s.p0090, with the name: network-initiated Data Session (NIDS) techniques, the contents of which are incorporated by reference in their entirety.

In another example, the SIP proxy 16 can send a non-IP based trigger to the terminating node independent of the public and private networks 12, 24, thereby instructing the terminating node to re-register with the SIP proxy, e.g., across the NAT/FW 28. In this regard, the SIP proxy can send a Short Message Service (SMS) message, an Enhanced Message Service (EMS) message, a Multimedia Message Service (MMS) message, or a Wireless Application Protocol (WAP) push trigger to the terminating node. In response to the trigger, the terminating node can re-register with the SIP proxy so that the SIP proxy can thereafter communicate with the terminating node across the NAT/FW. More specifically, in response to a trigger, the terminating node may register with the SIP proxy via the NAT/FW such that the NAT/FW assigns a public IP address to the terminating node and such that the SIP proxy can register the terminating node including the assigned public IP address. As described above, the SIP proxy can implement a registrar in accordance with SIP to perform registrar functions, such as registering a terminating node. Thus, as described herein, it should be understood that a SIP proxy can comprise a SIP proxy that implements a corresponding registrar to, for example, register and/or re-register a terminating node.

To allow the SIP proxy 16 to send non-IP based triggers to the terminating node 36, the SIP proxy can identify the terminating node independently of the IP communication channels of the public and private networks 12, 24, and thus on a communication channel independent of the NAT/FW 28. For example, the SIP proxy can identify an MSISDN or other global identifier associated with the terminating node. The SIP proxy can then send an SMS, EMS, MMS or WAP push trigger to the terminating node based on the MSISDN. In this regard, the SIP proxy can identify the non-IP-based identifier of the terminating node in any of a number of different manners. In an advantageous embodiment, the terminating node registers with the SIP proxy before the SIP proxy receives the push content for the terminating node from the originating node 20. Because the terminating node is registered with the SIP proxy, the terminating node can send the identifier of the terminating node (e.g., MSISDN) to the SIP proxy outside the IP communication channel. For more information on this network-initiated data session technique, see U.S. patent application Ser. No. 10/797765, filed on 3/10/2004, entitled: system and Method for establishing a Session Initiation Protocol Communication with a Mobile Terminal, the contents of which are incorporated herein by reference in their entirety. As an example of another network-initiated data session technique, see U.S. patent application No. 10/797529, filed 3/10/2004, entitled: system and Method for an Internet Protocol Connection with a Terminating Network Node, the contents of which are also incorporated herein by reference in their entirety.

Reference is now made to fig. 4A and 4B, which illustrate an example of a method of pushing content to a terminal node 36 in accordance with an embodiment of the present invention. For purposes of the example shown in fig. 4A and 4B, consider an end node having a private IP address that can be identified by a user as well as a host domain name. Also, consider a terminal node with an MSISDN. Further, consider, for example, an originating node 20 and a SIP proxy 16 each having a public IP address. Further, consider a NAT/FW28 that can be assigned one or more IP addresses in a pool of IP addresses.

As shown in fig. 4A, the terminating node 36 can instruct the SIP proxy 16 to subscribe to the push service of the originating node 20 on behalf of the terminating node by sending a SIP REFER (REFER) message to the SIP proxy via the corresponding NAT/FW 28. As will be appreciated by those skilled in the art, the SIP REFER message may be used by the terminating node to request that the SIP proxy REFER to the resources identified in the REFER message (i.e., the push service of the originating node) and allow the terminating node to be informed of the results of the REFER request. For more information on SIP refer technology see IETF request for comments document RFC 3515, entitled: the Session Initiation Protocol (SIP) Refer Method, month 4 2003, which is also incorporated herein by reference in its entirety.

The SIP refer message may include any number of information, such as described above. For example, the header field of the SIP refer message may include a source identifying the private IP address of terminating node 36. The header fields can also include, for example, identifying the destination of the public IP address of the SIP proxy 16, and identifying the contact of the end node user and the domain name. In addition, the header field can identify the originating node 20 in a Refer header field ("Refer-To"), which can also identify the push service of the originating node and instruct the SIP proxy To SUBSCRIBE (i.e., method SUBSCRIBE) To the push service.

In response to the SIP refer message, the NAT/FW28 can create a new translation table entry for the terminating node that associates the terminating node private IP address with the public IP address. However, if the NAT/FW currently has a translation table entry for the terminating node assigned a public IP address, the NAT/FW can query the translation table entry for the terminating node. In addition to creating new translation table entries, to allow communication between the intermediate node and the NAT/FW, the NAT/FW can add new Firewall (FW) filters that allow communication from the NAT/FW as well as communication to the SIP proxy 16, if desired. Although not described herein, messages sent and/or received according to embodiments of the present invention may also include an open communication port. In this case, the NAT/FW can create a translation table entry further comprising the same or another communication port and further operate in a manner that takes these communication ports into account.

After creating the new translation table entry, or after querying an existing translation table entry, the NAT/FW28 may translate the private IP address of the terminating node 36 in the header field of the SIP refer message into a public IP address assigned to the terminating node by the NAT/FW. Also, contact identifying the end node user and domain name can be translated to identify the public IP address assigned to the end node, based on the ALG's operation of the NAT/FW. The NAT/can then deliver the translated SIP refer message to the SIP proxy 16 after translating the address of the SIP refer message.

Upon receiving the translated SIP refer message, the SIP proxy 16 can accept the SIP refer message by returning an acceptance such as a 202 (ACCEPTED) message to the terminating node 36 via the NAT/FW 28. In this regard, the 202 (accepted) message may identify the terminating node by the public IP address assigned to the terminating node by the NAT/FW. Upon receiving 202 the (accepted) message, the NAT/FW can then translate the assigned public IP address into the private IP address of the terminating node. The NAT/FW then forwards 202 the (accepted) message to the terminating node.

Also, because the SIP refer message requests the SIP proxy 16 to enter a subscription on behalf of the terminating node 36, the SIP proxy can create a SIP subscription for the terminating node refer request. After creating the subscription, the SIP proxy can then return a SIP NOTIFY (NOTIFY) message (i.e., NOTIFY (refer)) to the terminating node, thereby notifying the terminating node that the SIP proxy has created the subscription for the terminating node refer request. As before, the SIP proxy can send the SIP notify message to the terminating node via the NAT/FW28 by addressing the SIP notify message to the public IP address assigned to the terminating node. The NAT/FW, in turn, can translate the public IP address assigned to the terminating node into the private IP address of the terminating node and forward the SIP notify message to the terminating node. Then, in response to the SIP Notification message, the terminating node can send an acknowledgement of the SIP Notification, such as a 200(OK) message, to the SIP proxy via the NAT/FW, which can translate the private IP address of the terminating node into a public IP address assigned to the terminating node by the NAT/FW.

Also when a SIP refer message is received, the SIP proxy 16 can process the SIP refer message in accordance with the SIP refer message by subscribing to the push service of the originating node 20 on behalf of the terminating node 36. In this regard, the SIP proxy can send a SIP SUBSCRIBE (SUBSCRIBE) message to the originating node, thereby subscribing to the push service of the originating node. The SIP subscribe message can include any of a number of different information, but identifies the push service identified in the SIP refer message from the SIP refer message. Furthermore, because the SIP proxy subscribes to the push service on behalf of the terminating node, the SIP subscribe message typically identifies the SIP proxy, as opposed to the terminating node.

Upon receipt of the SIP subscribe message, the originating node 20 can acknowledge receipt of the SIP subscribe message, such as by returning a 200(OK) message to the SIP proxy 16. In addition, the originating node may create a subscription for the push service for the SIP proxy. After creating the subscription, the originating node returns a SIP notify message (i.e., notify (subscribe)) to the SIP proxy, thereby notifying the SIP proxy that the originating node has created a subscription for the push service of the originating node. Upon receiving the SIP notify message, the SIP proxy can notify the terminating node 36 of the successful subscription according to the refer subscription. In this regard, the SIP proxy can send a SIP notify message (i.e., notify (refer)) to the terminating node via the NAT/FW28, as before, by addressing the SIP notify message to the public IP address assigned to the terminating node. As before, the NAT/FW can translate the public IP address assigned to the terminating node into the private IP address of the terminating node. In addition, the terminating node can send a 200(OK) message to the SIP proxy via the NAT/FW.

At one or more points in time after the SIP proxy 16 successfully subscribes to the push service of the originating node 20 on behalf of the terminating node 36, the terminating node can receive push content from the originating node via the SIP proxy and in accordance with the push service. In this regard, the originating node can send a SIP notify message (i.e., a notification including content (INC. COTNTENT)) to the SIP proxy and including the push content in accordance with the push service subscription.

However, in different situations, such as after a "time-to-live" time period, the NAT/FW28 may delete the translation table entries for the terminating node 36. Additionally or alternatively, for example, the SIP proxy 16 may cease maintaining the registration entry for the terminating node, including the public IP address assigned to the terminating node by the NAT/FW. In addition, the terminating node may deregister from the SIP proxy and thereafter enter an "idle" operating state. In this case, as can be appreciated, the SIP proxy cannot identify the terminating node across the NAT/FW and thus cannot thereby forward the push content to the terminating node via the NAT/FW.

According to embodiments of the present invention, however, the SIP proxy 16 may be capable of caching the push content from the originating node 20, such as in a memory of the SIP proxy (e.g., memory 44), when the push content is received. Thereafter, the SIP proxy can establish a network-initiated data session with the terminating node 36. For example, the SIP proxy 16 can send a non-IP based trigger to the terminating node based on the non-IP based identifier of the terminating node, such as the MSISDN. The non-IP based trigger, in turn, can instruct the terminating node to re-register with the SIP proxy. For example, the SIP proxy can send SMS messages, EMS messages, MMS messages or WAP push triggers to the terminating node across the cellular network 30 independent of the public and private networks 12, 24 and thus independent of the NAT/FW.

In response to the SIP proxy 16 establishing a network-initiated data session with the terminating node 36, the terminating node can re-register with the SIP proxy so that the NAT/FW28 can again assign a public IP address and communication port to the terminating node, and the SIP proxy can update its terminating node registration entry. More specifically, for example, once the terminating node receives the trigger, the terminating node can send a SIP REGISTER (REGISTER) message to the SIP proxy via the respective NAT/FW. In response to the sip register message, the NAT/Fw may again create a new translation table entry for the terminating node, associating the private IP address and the public IP address of the terminating node.

After creating the new translation table entry, the NAT/FW28 can translate the private IP address of the terminating node 36 within the SIP register message into a public IP address assigned to the terminating node by the NAT/FW. The NAT/FW can then convey the translated SIP register message to the SIP proxy 16 for registration. Upon receiving the translated registration message, the SIP proxy can update the previous registration entry for the terminating node. The SIP proxy can then acknowledge receipt and creation/update of the registration entry. As before, for example, the SIP proxy can send a 200(OK) message to the terminating node via the NAT/FW 28.

After re-registering the terminating node 36, the SIP proxy 16 can forward the push content to the terminating node via the NAT/FW28, for example, within a SIP message. For more information on the technology of sending such messages, see IETF request for comments document RFC3428, the name is: session Initiation Protocol (SIP) Extension for Instant Messaging, month 12 2002, the contents of which are incorporated by reference in their entirety. In this regard, from the SIP proxy, the NAT/FW can receive the push content and query the translation table entry for the terminating node based on the assigned public IP address of the terminating node (identified as the destination of the push content). The NAT/FW then translates the push content destination from the assigned public IP address to the private IP address of the terminating node. After translating the push content destination, the NAT/FW can forward the push content to the terminating node based on the private IP address of the terminating node. The terminating node can then acknowledge receipt of the pushed content, for example, by sending a 200(OK) message to the SIP proxy via the NAT/FW, although not shown.

Instead of the SIP proxy 16 storing the push content in a cache and forwarding the push content to the terminating node 36, the terminating node can be configured such that after re-registering with the SIP proxy, the terminating node subscribes to the push service, thereby receiving the push content. In this regard, reference is made to fig. 4B, which shows a part of a method of pushing content to a terminal node according to another embodiment of the present invention. As shown in fig. 4B, after the SIP proxy successfully subscribes to the push service of the originating node 20 on behalf of the terminating node, as before, the originating node can send a SIP notify message (i.e., notify (including content)) including push content according to the push service to the SIP proxy. As before, in response to the SIP notify message, the SIP proxy can return a 200(OK) message to the originating node. Thereafter, the SIP proxy may establish a network-initiated data session with the terminating node, for example, by sending a non-IP-based trigger to the terminating node. The terminating node can then re-register with the SIP proxy via the NAT/FW28 as before, so that the NAT/FW can again assign a public IP address and communication port to the terminating node and the SIP proxy can update its own registration entry for the terminating node.

After re-registering with the SIP proxy 16, the terminating node 36 can subscribe to the push service of the originating node 20 so that the terminating node can receive the push service from the originating node, rather than from the buffer of the SIP proxy as shown in fig. 4A. In this regard, by configuring the terminating node to instruct the SIP proxy to subscribe to the push service on behalf of the terminating node and then to subscribe to the push service after the SIP proxy receives the push content, the terminating node only needs to occupy network resources during the time period in which the originating node sends the push content in accordance with the push service.

As shown, the terminating node 36 can subscribe to push services by sending a SIP subscribe message to the originating node 20 via the NAT/FW28 and the SIP proxy 16, as shown in fig. 4B. More specifically, the terminating node can send a SIP subscribe message as before identifying the originating node push service as well as identifying the terminating node, typically the private IP address of the terminating node. The NAT/FW can then receive the SIP subscribe message, query the translation table entry for the terminating node, and thereafter translate the private IP address of the terminating node within the SIP subscribe message into a public IP address assigned to the terminating node by the NAT/FW. The NAT/FW28 can forward the SIP subscribe message to the SIP proxy after translating the terminating node private IP address into the assigned public IP address. The SIP proxy, in turn, can forward the SIP subscribe message to the originating node.

Upon receiving the SIP subscribe message, the originating node 20 acknowledges receipt of the SIP subscribe message as before, e.g., by returning a 200(OK) message to the terminating node 36 via the SIP proxy 16 and NAT/FW28, the NAT/FW28 translating the terminating node's private IP address into a public IP address assigned to the terminating node. In addition, the originating node can create a subscription for the push service for the terminating node. After creating the subscription for the push service for the terminating node, the originating node can send a SIP notify message to the terminating node via the SIP proxy and the NAT/FW. As before, the SIP notify message can include push content according to a push service subscription. In this regard, the SIP notify message can comprise the same SIP notify message received by the SIP proxy before the SIP proxy establishes the network-initiated data service with the terminating node, although the SIP notify message is now received by the terminating node via the SIP proxy and the NAT/FW identifying the terminating node as the message destination. Upon receiving the SIP notify message including the push content, the terminating node can then return a 200(OK) message to the originating node via the NAT/FW and SIP proxy.

As described herein, the terminating node 36 is located behind the NAT/FW28 from the perspective of the originating node 20. It should be understood, however, that the terminating node may be located behind a firewall/gateway without a NAT between the terminating node and the originating node. In this case, embodiments of the present invention can allow an originating node to initiate communication with a terminating node in a situation where the communication would otherwise be restricted by a FW, thereby maintaining firewall and/or gateway functionality to the network including the terminal.

For example, as will be appreciated by those skilled in the art, the system 10 including a NAT for private/public address translation is typically a network communicating according to IP version 4(IPv 4). It should be understood, however, that the system or portions of the system could alternatively be configured to communicate in accordance with IP version 6(IPv6), which supports longer IP addresses than IPv 4. In this regard, because IPv6 supports longer IP addresses than IPv4, one or more of the private networks may not require a NAT to perform address/port translation. In this case, the system may not include a NAT or NAT/FW, but rather a firewall/gateway (FW) that can be used as a security mechanism for the associated private network, e.g., in the same manner as described above. The system can then operate as above, although the end node can have an associated public IPv6 address. In this way, the source or destination of communications between the originating and terminating nodes can identify the IPv6 address that is public to the terminating node and pass without translation from the public IPv4 address to the private IPv4 address and vice versa, otherwise they identify the public IPv4 address of the terminating node assigned to be translated by the NAT into the private IPv4 address.

Many modifications and other embodiments of the invention will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims (30)

1. A method, comprising:

in response to a request for subscription to a push service of an originating node on behalf of a terminal node, deciding to establish a data session with the terminal node via a network address translator to obtain push content;

registering a network address assigned to the terminal node by the network address translator;

generating a trigger for transmission to the end node along a path independent of the network address translator, wherein the trigger instructs the end node to re-register across the network address translator; and

causing, at least in part, transmission of the push content to the end node via the network address translator.

2. The method of claim 1, further comprising:

in response to the re-registration, an update registration entry for the end node.

3. The method of claim 2, wherein the network address translator is configured to: an entry is created for the end node to associate the private network address with the public network address.

4. The method of claim 1, wherein the trigger is sent as one of a short message service message, an enhanced message service message, a multimedia message service, and a wireless application protocol push trigger.

5. The method of claim 1, wherein the trigger is non-Internet Protocol (IP) based.

6. The method of claim 1, further comprising:

a deregistration request is received from the terminal node.

7. The method of claim 1, wherein the trigger is generated according to a session initiation protocol.

8. The method of claim 1, wherein the originating node or the terminating node comprises a mobile terminal configured to operate on a cellular network.

9. An apparatus, comprising:

at least one processor, and

at least one memory including computer program code for one or more programs, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform at least the following,

deciding to establish a data session with the terminating node via a network address translator to retrieve push content in response to a request on behalf of the terminating node for subscription to a push service of an originating node,

registering a network address assigned to the terminal node by the network address translator,

generating a trigger for transmission to the end node along a path independent of the network address translator, wherein the trigger instructs the end node to re-register across the network address translator, an

Causing, at least in part, transmission of the push content to the end node via the network address translator.

10. The apparatus of claim 9, wherein the apparatus is further caused to:

in response to the re-registration, a registration entry is updated for the end node.

11. An apparatus according to claim 10, wherein the network address translator is configured to create an entry for the end node to associate a private network address with a public network address, the apparatus further caused to:

updating a registration entry for the end node in response to the re-registration.

12. The apparatus of claim 9, wherein the trigger is transmitted as one of a short message service message, an enhanced message service message, a multimedia message service, and a wireless application protocol push trigger.

13. The apparatus of claim 9, wherein the trigger is non-Internet Protocol (IP) based.

14. The apparatus of claim 9, wherein the apparatus is further caused to: a deregistration request is received from the terminal node.

15. The apparatus of claim 9, wherein the trigger is generated according to a session initiation protocol.

16. The apparatus of claim 9, wherein the originating node or the terminating node comprises a mobile terminal configured to operate on a cellular network.

17. A system, comprising:

a network address translator, and

a proxy server configured to communicate with the network address translator and to decide to establish a data session with the end node via the network address translator to obtain push content in response to a request for a push service on behalf of the end node to subscribe to an originating node,

wherein the proxy server is further configured to register a network address assigned to the end node by the network address translator and to generate a trigger for transmission to the end node along a path independent of the network address translator,

wherein the trigger instructs the end node to re-register across the network address translator; and the proxy server is further configured to cause, at least in part, transmission of the push content to the end node via the network address translator.

18. The system of claim 17, wherein the network address translator is configured to create an entry for the end node to associate a private network address with a public network address, and the proxy server is further configured to update a registration entry for the end node in response to the re-registering.

19. The system of claim 17, wherein the trigger is transmitted as one of a short message service message, an enhanced message service message, a multimedia message service, and a wireless application protocol push trigger.

20. The system of claim 17, wherein the trigger is non-Internet Protocol (IP) based.

21. The system of claim 17, wherein the trigger is generated according to a session initiation protocol.

22. The system of claim 17, wherein the originating node or the terminating node comprises a mobile terminal configured to operate on a cellular network.

23. A method of causing a node to re-register with a proxy server to receive push content after an end node has de-registered, the method comprising:

receiving a trigger from the proxy server along a path independent of a network address translator, wherein the trigger is related to a push service providing push content; and is

Re-registering the node with the proxy server across the network address translator in response to the trigger,

wherein the trigger is non-Internet Protocol (IP) based and instructs the node to re-register.

24. The method of claim 23, further comprising receiving push content via the proxy server and the network address translator.

25. The method of claim 24, further comprising subscribing to the push service for the node via the network address translator and the proxy server in order to receive the push content.

26. The method of claim 23, wherein the node comprises a mobile terminal configured to operate on a cellular network.

27. An apparatus, comprising:

a memory configured to store information;

a communication interface configured to transmit and receive information; and

a controller communicatively coupled to the memory and the communication interface, the controller configured to, when the device has unregistered from a proxy server:

receiving, via the communication interface, a trigger from the proxy server along a path independent of a network address translator, the trigger being related to a push service providing push content, and

re-registering the device with the proxy server across the network address translator in response to the trigger, thereby causing the network address translator to assign a public IP to the terminal node,

wherein the trigger is non-IP based and instructs the device to re-register.

28. The apparatus of claim 27, wherein the controller is further configured to: receiving, by the proxy server and the network address translator, push content using the communication interface.

29. The apparatus of claim 28, wherein the controller is further configured to: to receive the push content, the node is subscribed to the push service using the communication interface via the network address translator and the proxy server.

30. The apparatus of claim 27, wherein the apparatus is included in a mobile terminal configured to operate over a cellular network.