With recent progress in communication technology, various scenarios will arise in which an address of a node may change during a connection with another node. For example, a connection between nodes is broken or generally exhibits an outage, e.g. due to fast moving terminal nodes in mobile networks, or the like. Nodes such as terminals of end users or even servers acting as a node with which a terminal is communicating will, however, experience such outage (e.g. caused by a break/failure) in the connection as rather inconvenient. A temporary connection outage need not necessarily be caused by a connection failure which is usually related to e.g. a failure on the physical layer, though this is not excluded here. Rather, a connection outage as discussed in the present invention is mostly due to a node address change caused e.g. by a physical connection change or the like.
For the purpose of the present invention to be described herein below, it should be noted that                a node may for example be any kind of communication device, such as a wireless or wired device, e.g. personal computer, mobile phone or the like, irrespective of a specific standard to which these conform as long as they are compatible to a communication network; a node may be a terminal (also referred to as client) or a server;        for the communication network any suitable protocol for operating/message exchange is possible; only as an example it is noted that packet based communication networks such as IP based networks (e.g. conforming to IPv4 or IPv6) are particularly suitable to be used with the present invention;        method steps likely to be implemented as software code portions and being run using a processor at one of the nodes, are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;        generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention in terms of the functionality implemented;        method steps and/or devices or parts of devices referred to as units likely to be implemented as hardware components at one of the server/terminal entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor Transistor Logic), etc., using for example ASIC (Application Specific Integrated Circuit) components or DSP (Digital Signal Processor) components, as an example;        devices can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device/system is preserved.        
Although the present description will be given on a general level as the invention is applicable to any communication network, it is pointed out that the invention is most suitable for IP based networks.
For example, two nodes communicating with each other on an application level are having a so-called peer-to-peer communication. The application level is carried on a connection level. A level as mentioned here corresponds to a layer in a layered communication model. However, the present invention is not limited to a specific OSI layer or layers. (OSI=Open System Interconnection).
Nevertheless, a communication between two nodes as described in examples of scenarios to which the present invention is applicable, is not limited to a peer-to-peer communication. Rather, IETF (Internet Engineering Task Force) defines a client as a host (node) that initiates e.g. IP communication by sending the first packet to another node and a server as a host that—when idle—waits and listens to incoming packets from a client. In such a framework, two peers are nothing but two hosts that can assume the role of either a client or a server (or both). (Other definitions of peer-to-peer exist, too, in abundance.) Nonetheless, the invention is also applicable to a variety of client-server scenarios. Its applicability to peer-to-peer scenarios is a by-product of its applicability to client-server scenarios under the above-given definition of peer-to-peer.
For example, a peer-to-peer communication application between two nodes A and B may reside in a scenario as follows. A node (client) negotiates and establishes an IPv6 tunnel over an IPv4 connection to a tunnelling server. The tunnelling server and the intermediate IPv6 network then route IPv6 traffic to and from another node. The IPv4 connection may break or be subject to an outage unintentionally e.g. because of a node (e.g. a mobile phone) will move from one BTS area to another experiencing a change of the node's IP address of the IPv4 connection. The node may also change intentionally the IPv4 connectivity e.g. from GPRS to WLAN, if WLAN becomes available, which could also lead to a change of the IPv4 connection node address.
If the underlying IPv4 connectivity experiences an outage, the same applies as well to the IPv6 tunnel and possible peer-to-peer connections (with applications) that have been established between this node and other nodes.
This results in applications losing the peer-to-peer connections, and requiring from the user manual re-establishment of the connection.
In case of e.g. group VoIP (Voice over IP) communication as an application example, with members of the VoIP group moving around in a metropolitan area, the usability of the application would be ruined if in practice every time you want to communicate with the group you would first have to manually check with whom you have lost the connection, and re-establish the connections manually. Otherwise the peers/nodes that have dropped the (peer-to-peer) connection with your node will not receive the VoIP message.
To summarize, there are situations emerging which lead to the problem of how a node can maintain IP-connectivity or generally an ongoing communication connection with another node, whose IP-address changes, without terminating the application(s) running between the nodes on top of it, i.e. on top of the IP connectivity layer. This is especially critical for any type of real time applications, where the tolerable connection interruption time on the application layer is quite short. However, the applicability of the present invention as described hereinafter is not limited to real time applications. Rather, real time applications are merely referred to as an example for applications which fail in cases or require specialized code to cope with situations in which the address of a communication partner node changes. Generally, it is to be noted that the present invention is advantageously applicable to applications which fail in cases or require specialized code to cope with situations in which the address of a communication partner node changes. Real-time applications are only referred to as a descriptive example without limiting the scope of applicability of the present invention.
Irrespective of the above examples focusing on peer-to-peer scenarios, it has to be kept in mind that examples of client-server scenario also exist. The invention is also not limited to cases where tunnelling is used.
Generally, the following example cases are applicable, where one of the nodes has a public address to which traffic from another node can be routed (i.e. the node is addressable and reachable), and the address changes during an ongoing transmission between the nodes.                The public address is assigned to the node by e.g. a DHCP (Dynamic Host Configuration Protocol) server for a lease period. Upon lease expiration, the node gets a different address from the DHCP server.        The public address is assigned to the node by e.g. a NAT (Network Address Translation) or NAPT (Network Address Port Translation) server, which suddenly assigns a different address to the node.        The public address is assigned to the node by e.g. a tunnelling server, which suddenly assigns a different address to the node.        
Thus, problems as those mentioned in the above examples may occur on any network, where the node address may change without a warning, e.g., on the Internet if the server uses dynamic DNS and its address changes, say, under DHCP.
Furthermore, in connection with IP based networks, Dynamic Domain Name Service (DynDNS) is widely know in the Internet and has been into use there for a long time. Nevertheless, DynDNS has not been used as a mechanism to recover from node address changes for real time traffic in a fast enough manner, to prevent terminating of e.g. the real time application running on top of the connection. Recovery from IP address changes for a standard DynDNS implementation is slow and takes some time (in the area of minutes, for example the minimum time-to-live time for caching of DNS entries is defined to 60 s).
USPTO Backgrounds
USPTO Backgrounds