US20080095138A1

US20080095138A1 - Method for performing handovers in a communication system

Info

Publication number: US20080095138A1
Application number: US11/646,279
Authority: US
Inventors: Yi Wu; Mikael Latvala; Janne Tuononen
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2006-10-24
Filing date: 2006-12-28
Publication date: 2008-04-24
Also published as: GB0908275D0; EP2084859A4; EP2084859B1; GB2456451A; EP2084859A1; ES2508940T3; GB2456451B; WO2008049968A1; EP2770774A1; US20080096562A1; HK1201397A1; US7970402B2; FI20060936A0

Abstract

The invention relates to a method for the performing of handover in a communication system. In the method a transport connection establishment request is sent from a first network node to a second network node. A node name is obtained for the second network node. A handover condition is detected by the first network node. A new address is obtained for the first network node. The new address for the first network node is updated to a name service node. A transport connection migration request is sent from the first node to the second network node. The transport connection migration request comprises a token, which identifies the connection.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention
The invention relates to mobile communication networks and mobile terminal. Particularly, the invention relates to a method for the performing of handovers in a communication system.
2. Description of the Related Art
The introduction of Wireless Local Area Networks (WLAN) has the potential to revolutionize mobile Internet communications. The current licensed band mobile communication networks have limited usability due to the lack of bandwidth for high-bitrate content offering. The WLANs have the capability to provide higher bitrates, for example, due to smaller cell size. Therefore, in WLAN coverage areas mobile terminals have the capability to download larger content objects and to support the streaming of multimedia content. The WLANs have also the additional benefit of providing free-of-charge radio access. Unfortunately, WLANs are only available in limited geographical areas such as offices and homes whereas licensed band radio access is generally available in vastly larger areas such as entire cities, major highways and populated rural areas. WLANs may also provide only scattered radio access which is why it is necessary for mobile terminals to fall back to licensed band radio access while moving between separate WLANs. However, the performing of such a fallback is currently not supported in a manner which enables existing packet switched transport connections to be handed over seamlessly from a WLAN to a licensed band radio cell. The problems are related to the need to change the Internet Protocol (IP) addresses while moving between a WLAN and a licensed band radio cell. The WLAN and the mobile communication network providing the licensed band radio cell belong to different administrative domains.
One method of dealing with this problem is provided by Mobile IP, which is defined by Engineering Task Force (IETF). In Mobile IP a mobile node is accessed via a home agent, which provides a permanent address for the mobile node. Before a route optimization procedure is performed, at least all terminating packets are routed via the home agent. The mobile node obtains a care-of address from its current network and registers the care-of address to the home agent. The home agent routes the packets to the care-of address using IP tunneling. The problem with mobile IP is that it introduces a significant delay to the packet stream. Further problems are related to firewalls and network security, which in effect mandate that outgoing packets should also be tunneled to the home agent before they may be routed independently. Due to these reasons, mobile IP is considered not to provide an ultimate solution for terminal portability. There exists the possibility to deal with the problem on TCP layer by splitting a TCP layer connection to two parts and to have a TCP layer proxy.
Reference is now made to FIG. 1, which is a block diagram illustrating the Transmission Control Protocol (TCP) segment headers in prior art. The TCP is described in detail in IETF document RFC 793. TCP does the tasks of a transport layer in the Open System Interconnection (OSI) model of data communications. In FIG. 1 there is a TCP segment header 100. In header 100 the source port identifies the application that sent the TCP segment and the destination port the targeted application. A single application may use several ports for the sending of data and it may listen to several ports for data received. By means of the port number a protocol stack knows the correct application entity to which the TCP segment must be sent. The sequence number identifies in bytes the current position in the byte stream that is being sent. The acknowledgement number indicates to the sender the bytes in the byte stream that have correctly been received by the receiver. During the establishment of a TCP connection, initial sequence numbers (ISNs) are exchanged between the sending and the receiving host. The Len-field indicates in 32-bit words the length of the TCP header. The flags comprise an urgent flag, an acknowledgement flag (ACK), a push flag, a connection reset flag, a synchronize sequence numbers (SYN) flag and a final flag (FIN). The flag SYN is used in connection establishment phase. A segment with SYN flag is referred to as a SYN segment or a TCP-SYN segment. Similarly, a segment with the ACK flag on is referred to as an ACK segment. Window size is the number of data bytes beginning with the one indicated in the acknowledgment field, which the sender of the current segment is willing to accept. The checksum is computed as the 16-bit one's complement of the one's complement sum of a pseudo header comprising information collected from the IP header, the TCP header, and the data, padded as needed with zero bytes at the end to make a multiple of two bytes. If the URG flag is set, then the 16-bit field urgent pointer is an offset from the sequence number indicating the last urgent data byte.
These mandatory fields are followed by a number of additional header fields called options. If any options are present, then the total length of the option field must be a multiple of a 32-bit word and the data offset field must be adjusted appropriately. There are two kinds of options, namely two-byte options comprising a type byte and a length byte and three-byte options comprising a type byte, a length byte and a number of data bytes. The data bytes carry the field value included in an option.
TCP connections comprise three phases: connection establishment phase, data transfer phase and connection termination phase. A three-way handshake is used to establish a connection. A four-way handshake is used to tear down a connection. Despite the fact that it is possible for a pair of hosts to initiate a connection between each other simultaneously, typically one host opens a socket and listens passively for a connection from the other end. This is commonly referred to as a passive open, and it designates the server-side of a connection. The client-side of a connection to be established initiates an active open by sending an initial SYN segment to the server as part of the three-way handshake. The server-side responds to a valid SYN segment with a SYN segment with also the ACK flag on. Finally, the client-side responds to the server with an ACK segment, thereby completing the three-way handshake and the connection establishment phase.

SUMMARY OF THE INVENTION

The invention relates to a method comprising: sending a transport connection establishment request from a first network node to a second network node; obtaining a node name for said second network node; detecting a handover condition in said first network node; obtaining a second address for said first network node; updating said second address for said first network node to a name service node; and sending a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said connection.
The invention relates also to a communication system comprising: a first network node configured to send a transport connection establishment request to a second network node, to obtaining a node name for said second network node, to detect a handover condition, to obtain a second address, to request updating of said second address for said first network node to a name service node and to send a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said transport connection; said second network node configured to receive said transport connection establishment request and to receive said transport connection migration request; and said name service node to receive said request for updating of said second address for said first network node.
The invention relates also to a network node comprising: a transport entity configured to send a transport connection establishment request to a second network node, to obtaining a node name for said second network node, to detect a handover condition, to obtain a second address, to request updating of said second address for said network node to a name service node and to send a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said transport connection.
The invention relates also to a network node comprising: means for sending a transport connection establishment request to a second network node; means for obtaining a node name for said second network node; means for detecting a handover condition; means for obtaining a second address; means for requesting the updating of said second address for said network node to a name service node; and means for sending a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said transport connection.
The invention relates also to a computer program comprising code adapted to perform the following steps when executed on a data-processing system: sending a transport connection establishment request to a second network node; obtaining a node name for said second network node; detecting a handover condition; obtaining a second address; requesting the updating of said second address for said network node to a name service node; and sending a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said transport connection.
In one embodiment of the invention, the transport entity in the first network node adds a public key of said first network node to the transport connection establishment request. The transport entity in the first network node also obtains a public key for said second network node. The public key for the second network node is obtained in response to the transport connection establishment request from the second network node. Thereupon, the transport entity compute a shared secret with said public key of said first network node and said public key of said second network node. The transport entity computes the token using the shared secret. The token is computed similarly in the server which obtains the connection information using the token as an index to a list of connections.
In one embodiment of the invention, the transport entity in the first network node is configured to detect a timer expiry for a reply to said transport connection migration request. If the timer expires the transport entity obtains a second address for said second network node using said node name for said second network node. The second address is obtained from, for example, a domain name server. The transport entity sends said transport connection migration request to said second network node. The transport connection migration request comprises said token.
In one embodiment of the invention, the transport entity in the first network node starts a first transport process upon sending a transport connection migration request. The transport entity starts also a second transport process upon receiving a transport connection migration request. The transport entity detects connection migration completion of said first transport process and to abandon said second transport process. The completion is detected, for example, by receiving an acknowledgement first or by an arbitration based on original connection establishment.
In one embodiment of the invention, the transport connection is a transport control protocol connection.
In one embodiment of the invention, the name service node comprises a domain name server. The domain name server may be the authoritative name server for the name of the second network node.
In one embodiment of the invention, the communication system comprises an IP multimedia subsystem.
In one embodiment of the invention, the communication system comprises a packet switched network, for example, an Internet Protocol (IP) network.
In one embodiment of the invention, said communication system comprises a mobile communication network. In one embodiment of the invention, said terminal comprises a mobile station or generally a mobile terminal. In one embodiment of the invention, the communication system comprises at least one of a Global System of Mobile Communications (GSM) network and a Universal Mobile Telephone System (UMTS) network. The terminal may be, for example, a GSM mobile station or a UMTS mobile station with a dual mode or multimode functionality to support different access types.
In one embodiment of the invention, the computer program is stored on a computer readable medium. The computer readable medium may be a removable memory card, magnetic disk, optical disk or magnetic tape.
The embodiments of the invention described hereinbefore may be used in any combination with each other. Several of the embodiments may be combined together to form a further embodiment of the invention. A method, a communication system, a network node or a computer program to which the invention is related may comprise at least one of the embodiments of the invention described hereinbefore.
The benefits of the invention are related to improved reliability of connections in a communication system. A double handover where both the first and the second network nodes perform simultaneously a handover and obtain a new IP address may be handled in an organized way.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a further understanding of the invention and constitute a part of this specification, illustrate embodiments of the invention and together with the description help to explain the principles of the invention. In the drawings:

FIG. 1 is a block diagram illustrating the Transmission Control Protocol (TCP) segment headers in prior art;

FIG. 2 is a message sequence chart illustrates transport connection migration support for only client in one embodiment of the invention;

FIG. 3A is a message sequence chart illustrating transport connection migration in one embodiment of the invention;

FIG. 3B is a message sequence chart illustrating the continuation of transport connection migration in one embodiment of the invention;

FIG. 4A is a flow chart illustrating a method for the completion of handover in one embodiment of the invention;

FIG. 4B is a flow chart illustrating the continuation of the method for the completion of handover in one embodiment of the invention; and

FIG. 5 is a block diagram illustrating a network node in one embodiment of the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings.
Reference is now made to FIG. 2, which is a message sequence chart that illustrates transport connection migration support for only client in one embodiment of the invention.
In FIG. 2 there is illustrated a Authoritative Name Servers (ANS) for a TCP client and a TCP server, namely ANS-B 250 and ANS-A 256. There is also a client 252 and a server 254. At time T0, an application in client 252 request that a TCP connection is set-up towards server 254. The application (not shown) must provide a Fully Qualified Domain Name (FQDN) to TCP layer (not shown) in client 252 in order to enable the relocation of server 254. The use of a FQDN instead of an IP address provides a level of indirection, which facilitates end-to-end mobility. Client 252 sends a query to ANS-B 250, which carries the FQDN-B, as illustrated with arrow 201. ANS-B 250 resolves the FQDN-B into IP-B and returns the current address of server 254, namely IP-B to client 252, as illustrated with arrow 202.
Client 252 initiates TCP handshake by sending a TCP segment to server 254 as illustrated with arrow 203. The TCP segment comprises the SYN flag set to “1” and the Sequence Number (SN) set to initial value “531521”. The initial value of the sequence number is generated by an initial sequence number generator, which selects a new 32 bit initial sequence number. The generator may be bound to a 32 bit clock which is incremented roughly every 4 microseconds. The purpose of the initial sequence number is to avoid reusing same sequence numbers in subsequent SYN segments. The segment also comprises a “Migrate OK” option and a “Timestamp” option. These options are used to carry parts of the public key “K_A” of client 252. The public key is reassembled in client 252. The “Migrate OK” option also carries a curve name parameter if Elliptic Curve Diffie-Hellman (ECDH) key exchange is used. The public key is computed in client 252 by setting K_A=XA*P. The value XA is a random value between 1 and n-1, wherein n is the order of P.
Server 254 also computes its public key by setting K_B=XB*P. The value XB is a random value between 1 and n-1, wherein n is the order of P. By using the public keys K_A and K_B both hosts compute the same shared secret K=K_A*XB=K_B*XA since K=K_A*XB=XA*P*XB=XB*P*XA=K_B*XA. Thereupon, in response to TCP segment illustrated with arrow 203, server 254 sends a TCP segment to client 252, as illustrated with arrow 204. The TCP segment comprises the SYN and ACK flags set to value “1”, sequence number set to initial value “083521” and acknowledgement number “ACK” set to value “531522”, which indicates successful receiving of one byte representing the SYN segment. The segment also comprises a “Migrate OK” option and a “Timestamp” option. These options are used to carry parts of the public key “K_B” of server 254, which is reassembled in client 252. Client 252 completes the connection establishment phase by sending a TCP segment to server 254, as illustrated with arrow 205. The TCP segment comprises the ACK flag set to value “1” and acknowledgement number set to value “083522”. The acknowledgement number is incremented by 1 in order to acknowledge the receipt of the ACK+SYN TCP segment. Normally, a SYN or an ACK+SYN segment is acknowledged by incrementing the sequence number “SN” by one. Thereupon, a number of data TCP segments are exchanged between client 252 and server 254. The final TCP segment before a handover that occurs at time T1 is illustrated with arrow 206. The TCP segment comprises sequence number set to value “091861”, acknowledgement number set to value “545968” and 536 bytes of data. The TCP segment is successfully received by client 252.
At time T1 client 252 performs a handover to a new address. The new address is obtained, for example, from a Dynamic Host Configuration Protocol (DHCP) server in the new network to which client 252 has moved. Client 252 resumes the TCP connection by sending a SYN TCP segment to server 254, as illustrated with arrow 207. The TCP segment comprises the SYN flag set to value “1”, sequence number set to value “545967” and a “Migrate” option comprising a token “T” and a request “R”. The token T=SHA1(client-isn, server-isn, K) is computed using a secure hash function SHA1 from the initial sequence values of client 252 and server 254 and the shared secret key “K” that has been computed using the public key “K_A” of client 252. The request R=SHA1(client-isn, server-isn, K, S, I) is computed using a secure hash function SHA1 from the initial sequence values of client 252 and server 254, the shared secret key “K”, the entire SYN segment comprising the “migrate” option, and a sequence number I identifying the migrate request from other similar migrate requests. Generally, in a TCP segments indicating migration, the sequence number “SN” is set to a value which is equal to one less than the acknowledgement number “ACK” of the last TCP segment successfully received from the peer. This is performed in order to differentiate migrate requests from other TCP SYN segments. In response, server 254 sends a segment to client 252, as illustrated with arrow 208. The segment comprises the SYN and ACK flags set to value “1”, sequence number set to value “092397” and acknowledgement number set to value “545968”, as illustrated with arrow 208. The three-way-handshake associated with the migration is completed by client 252, which sends a TCP segment to server 254 with the ACK flag set to “1” and acknowledgement number set to “092398”, as illustrated with arrow 209.
FIG. 3A is a message sequence chart that illustrates transport connection migration in one embodiment of the invention. In FIG. 3A there is illustrated an Authoritative Name Servers (ANS) for a TCP client and a TCP server, namely ANS-A 350 and ANS-B 356. There is also a client 352 and a server 354. At time T0, an application in client 352 request that a TCP connection is set-up towards server 354. The application (not shown) must provide a Fully Qualified Domain Name (FQDN) to TCP layer (not shown) in client 352 in order to enable the relocation of server 354. Otherwise, the TCP layer must obtain the FQDN using an IP address. The use of a FQDN instead of an IP address provides a level of indirection, which facilitates end-to-end mobility. Client 352 sends a query to ANS-B 356, which carries the FQDN-B, as illustrated with arrow 301. ANS-B 356 resolves the FQDN-B into IP-B and returns the current address of server 354, namely IP-B to client 352, as illustrated with arrow 302.
Client 352 initiates TCP handshake by sending a TCP segment to server 354 as illustrated with arrow 303. The TCP segment comprises the SYN flag set to “1” and the Sequence Number (SN) set to initial value “531521”. The segment also comprises a “Migrate OK” option, which is also referred to as, a Migrate-Permitted option.
In one embodiment of the invention, the segment also comprises a “Timestamp” option. The “Migrate OK” option and the “Timestamp” option may be used to carry parts of the public key “K_A” of client 352. The public key is reassembled in client 352.
In one embodiment of the invention, the “Migrate OK” option also carries a curve name parameter whenever Elliptic Curve Diffie-Hellman (ECDH) key exchange is used between client 352 and server 354 to negotiate a shared secret K.
In one embodiment of the invention, the public key is computed in client 352 by setting K_A=XA*P. The value XA is a random value between 1 and n-1, wherein n is the order of P. Server 354 also computes its public key by setting K_B=XB*P. The value XB is a random value between 1 and n-1, wherein n is the order of P. By using the public keys K_A and K_B both hosts compute the same shared secret K=K_A*XB=K_B*XA since K=K_A*XB=XA*P*XB=XB*P*XA=K_B*XA.
Server 354 sends reverse name service query to ANS-A 350 comprising the IP address (IP-A) of client 352 in order to obtain the Fully Qualified Domain Name (FQDN) for it, as illustrated with arrow 304. The returning of FQDN-A from ANS-B 350 to server 354 is illustrated with arrow 305. In response to the SYN TCP segment illustrated with arrow 303, server 354 sends a TCP segment to client 352, as illustrated with arrow 306. The TCP segment comprises the SYN and ACK flags set to value “1”, sequence number set to initial value “083521” and acknowledgement number “ACK” set to value “531522”, which indicates successful receiving of one byte representing the SYN segment. The segment also comprises a “Migrate OK” option. This indicates that communication peer supports TCP Migrate functionality. If the option is missing, initiator interprets it to indicate that Migration cannot be used for this session and will continue the session as a legacy TCP session.
In one embodiment of the invention, the segment also comprises a “Timestamp” option. These options are used to carry parts of the public key “K_B” of server 354, which is reassembled in client 352.
Client 352 completes the connection establishment phase by sending the TCP segment illustrated with arrow 307. The TCP segment comprises the ACK flag set to value “1” and acknowledgement number set to value “083522”. The acknowledgement number is incremented by 1 in order to acknowledge the receipt of the ACK+SYN TCP segment. Normally, a SYN or an ACK+SYN segment is acknowledged by incrementing the sequence number “SN” by one.
Thereupon, a number of data TCP segments are exchanged between client 352 and server 354. The final TCP segment before handovers that occur at time T1 is illustrated with arrow 308. The TCP segment comprises sequence number set to value “091861”, acknowledgement number set to value “545968” and 536 bytes of data. The TCP segment is successfully received by client 352. At time T1 client 352 and server 354 both perform handovers to new addresses. The new addresses A′ and B′ are obtained (not shown), for example, from Dynamic Host Configuration Protocol (DHCP) servers in the new networks to which client 352 and server 354 have moved, respectively.
FIG. 3B is a message sequence chart that illustrates continuation of transport connection migration in one embodiment of the invention. In FIG. 3B there is illustrated an Authoritative Name Servers (ANS) for a TCP client and a TCP server, namely ANS-A 350 and ANS-B 356. There is also a client 352 and a server 354.
Client 352 sends an update message to ANS-A 350, which provides the FQDN-A and IP-A′, as illustrated with arrow 309. The acknowledgement to the update is not shown. Client 352 starts attempting to resume the TCP connection by sending a SYN TCP segment to server 354, as illustrated with arrow 310. The TCP segment comprises the SYN flag set to value “1”, sequence number set to value “545967” and a “Migrate” option comprising a token “T” and a request “R”. The token T=SHA1(client-isn, server-isn, K) is computed using a secure hash function SHA1 from the initial sequence values of client 252 and server 254 and the shared secret key “K” that has been computed using the public key “K_A” of client 252. The request R=SHA1(client-isn, server-isn, K, S, I) is computed using a secure hash function SHA1 from the initial sequence values of client 352 and server 354, the shared secret key “K”, the entire SYN segment comprising the “migrate” option, and a sequence number I identifying the migrate request from other similar migrate requests. Generally, in a TCP segments indicating migration, the sequence number “SN” is set to a value which is equal to one less than the acknowledgement number “ACK” of the last TCP segment successfully received from the peer. This is performed in order to differentiate migrate requests from other TCP SYN segments. The token “T” will be used by the receiving peer to identify the resumed TCP connection and the TCP control block information for the connection. However, the TCP segment is not received by server 354 due to the fact that it has performed handover and is no longer available at the old IP address. The TCP segment is lost.
Server 354 sends an update message to ANS-B 356, which provides the FQDN-B and IP-B′, as illustrated with arrow 311. The acknowledgement to the update is not shown. Server 354 starts attempting to resume the TCP connection by sending a SYN TCP segment to client 352, as illustrated with arrow 312. The TCP segment comprises the SYN flag set to value “1”, sequence number set to value “092397” and a “Migrate” option comprising the token “T” and the request “R”. The token and the request are computed as explained hereinbefore. However, the TCP segment is not received by client 352 due to the fact that it has performed handover and is no longer available at its old IP address. Thus, the TCP segment is lost.
In response to a timeout for a response to the TCP segment illustrated with arrow 312, server 354 sends a query to ANS-A 350, as illustrated with arrow 313. The query comprises the FQDN-A, which is used to obtain the current IP address for client 352, namely IP-A′. In response, ANS-A 350 provides the IP address IP-A′ to server 354, as illustrated with arrow 315. The timeout indicates a possible double handover and therefore the sending of the TCP segment with migrate option must be repeated.
In response to a timeout for a response to the TCP segment illustrated with arrow 310, client 352 sends a query to ANS-B 356, as illustrated with arrow 314. The query comprises the FQDN-B, which is used to obtain the current IP address for server 354, namely IP-B′. In response, ANS-B 356 provides the IP address IP-B′ to client 352, as illustrated with arrow 316.
Client 352 repeatedly sends the TCP segment with the migrate option comprising the “T” and “R” parameters, SYN flag set to “1” and sequence number to “545967” indicating the migration, as illustrated with arrow 317. Substantially simultaneously with client 352, server 354 repeatedly sends the TCP segment with the migrate option. The TCP segment comprises the “T” and “R” parameters, SYN flag set to “1” and sequence number set to “092397” indicating the migration, as illustrated with arrow 318.
In response to the receiving of the TCP segment illustrated with arrow 318, client 352 obtains the connection information with the token “T”. Client 352 searches through a list of connections and obtains connection information from the table for the connection identified with token “T”. Generally, client 352 maintains a table of connections, which are indexed using the tokens computed with the connection parameters explained hereinbefore. The client 352 sends a TCP with the SYN and ACK flags set to value “1”, sequence number set to value “545967” and acknowledgement number set to value “092398”, as illustrated with arrow 319. A second TCP process is started in client 352 in addition to the one started by sending the TCP segment illustrated with arrow 317. At a later point in time, client 352 must decide which TCP process to continue.
In response to the receiving of the TCP segment illustrated with arrow 317, server 354 obtains the connection information with the token “T”. Server 354 sends a TCP with the SYN and ACK flags set to value “1”, sequence number set to value “092397” and acknowledgement number set to value “545968”, as illustrated with arrow 320. A second TCP process is started also in server 354 in addition to the one started by sending the TCP segment illustrated with arrow 318. At a later point in time, server 354 must decide which TCP process to continue.
In response to the receiving of the TCP segment illustrated with arrow 319, server 354 sends a TCP with the ACK flags set to value “1”, sequence number set to value “092398”, the acknowledgement number set to value 545968 and 536 bytes of data.
In response to the receiving of the TCP segment illustrated with arrow 320, client 352 sends a TCP with the ACK flags set to value “1”, sequence number set to value “545968”, the acknowledgement number set to value “092398” and no bytes of data.
Due to the fact that server 354 is first in the sending of data, it is considered by client 352 that the TCP process initiated by server 354 with TCP segment 318 is the one to be continued. Therefore, the other TCP process initiated by client 352 is abandoned. Equivalently, server 354, upon receiving TCP segment 322 with no data, decides that the TCP process initiated by it should continue.
In one embodiment of the invention, additional heuristics may be used to decide which of the simultaneous processes are allowed to continue. For example, the node which originally initiated the TCP connection by sending SYN+ACK TCP segment may be considered the one which is allowed to establish the migrated connection. Similarly, the node acting initially as the TCP server may be considered the one which is allowed to establish the migrated connection. Other similar heuristics comprise the comparing of IP addresses and selecting the node with the highest IP address. In one embodiment of the invention, the IP addresses of both nodes are used as arguments in a hash function to compute a result value. The computation may be performed in both nodes. The node whose IP address yields the highest result value is considered the one which establishes the migrated connection.
FIG. 4A is a flow chart illustrating a method for the completion of handover in one embodiment of the invention.
At step 400 a public key is computed in a client by setting K_A=XA*P. The value XA is a random value between 1 and n-1, wherein n is the order of P. The client starts establishing a transport connection with a server. The transport connection may be a TCP connection. The transport layer connection may also be a media stream connection carried over an unreliable datagram service between the client and the server. The connection may be a Real-Time Protocol (RTP) stream carried over User Datagram Protocol (UDP). In association with the connection establishment the client provides the public key K_A to the server. The Server also computes its public key by setting K_B=XB*P. The value XB is a random value between 1 and n-1, wherein n is the order of P. By using the public keys K_A and K_B both hosts compute the same shared secret K=K_A*XB=K_B*XA. The server provides the public key K_B to the client in association with connection establishment acknowledgement.
At step 402 the server obtains the client name using the client address. If the client has established the connection using an address of the server, the client also obtains the name of the server using the server address. Thus, peer node names are obtained using peer addresses. The step of obtaining peer node names may also be performed during the course of the establishment of the transport connection.
At step 404 it is checked if the connection release is to be performed. If the connection must be released, for example, due to a release request from either party, the connection is released and the method is finished. If the connection is not to be released, the method continues at step 406.
At step 406 it is checked by the client or the server if there is a handover. If there is no handover, the method continues at step 404. If there is a handover condition, the method continues at step 408.
At step 408 the node performing the handover allocates a radio resource from the target radio network and establishes radio communication with a base transceiver station from the target radio network. The node performing the handover obtains a new address from a packet switched network connected to the target radio network. The node performing the handover may be the client or the server.
At step 410 the new address is updated to a name service, which is responsible for providing an address for the node using its name. The name service may be the Internet Domain Name System (DNS).
At step 412 a token is computed in the node performing the handover. The token is computed, for example, by setting T=SHA1(client-isn, server-isn, K), wherein client-isn and the server-isn are the initial sequence numbers associated with the client and the server, respectively. The parameter K is the shared secret K. Generally, the token identifies the connection securely to the peer node, which is informed of the handover. Further, a request value may be computed in addition to the token. The request R=SHA1(client-isn, server-isn, K, S, I) is computed using a secure hash function SHA1 from the initial sequence values of the client and the server, the shared secret key “K”, an entire connection re-establishment request comprising a migrate option, and a sequence number I identifying the migrate request from other similar migrate requests. The secure hash algorithm is not necessarily SHA1, but may be any other secure hash algorithm such as, for example, MD5 or SHA-256. The token T, optionally the request R and the new address of the node that performed the handover are sent to the peer node.
At step 414 the node that performed the handover waits for an acknowledgement to the migration request. For example, in the case of TCP, the node waits for a TCP segment with the SYN and ACK flags set to value “1”. If such an acknowledgement is received within a predefined time limit, the method continues at step 416. If such an acknowledgement is not received within the predefined time limit, the method continues at step 418.
At step 416 the acknowledgement to the migration request acknowledgement and the connection parameters received from the peer node are acknowledged by the node that performed the handover.
FIG. 4B is a flow chart illustrating the continuation of the method for the completion of handover in one embodiment of the invention.
At step 418 the node that performed the handover requests the peer address using the peer node name from the name service. The purpose of the repeated request is to obtain the new address for the peer node in case also the peer node has performed a handover and changed its address.
At step 420 the node that performed the handover at step 406, repeats the sending of the token and its new address to the peer node. As mentioned before, the token may be accompanied by the request parameter R, which identifies the request from the previous requests.
At step 422 a reply or a timer expiry for receiving a response is waited. The reply may be received from the peer node or from the name service. If a reply is received from the peer node, the method continues at step 416. If a reply is received from the name service and the reply comprises a new address for the peer node, the method continues at step 412. If a reply is received from the name service and the reply still provides the old address for the peer node, the method continues at step 418. If the timer for a reply expires, the method continues at step 418.
FIG. 5 is a block diagram illustrating a network node in one embodiment of the invention. The network node may be the client or the server as described in association with FIGS. 3A, 3B, 4A and 4B. In FIG. 5 there is a network node 500. Node 500 comprises a processor 510 and a secondary memory 520. The secondary memory may be for example a hard disk or a flash memory or an optic disk. Node 500 comprises also a primary memory 530. When processor 510 is executing network node functionality primary memory 530 comprises an application entity 532, a transport entity 534, IP entity 536 and a layer-2 entity 538. Application entity 532 is, for example, a WWW browser, which uses transport entity 534 to exchange data with a remote node. Transport entity 534 is configured to comprise transport connection migration functions in order to move a transport connection after a handover to a new node. Transport entity 534 is also configured to control at least one transport process. A transport process comprises transport protocol state information and variables for a transport connection such as sequence numbers for packets sent and acknowledgements received. IP entity 536 comprises the network layer functions, for example, the Internet Protocol functions. Layer-2 entity 538 comprises the link layer functions. Network node 500 also comprises a network interface 540 which may be for example a Local Area Network interface, Wireless Local Network interface or a Wide Area Network interface such as optic fiber.
In one embodiment of the invention, transport entity 534, IP entity 536 and layer-2 entity 538 are comprised in the operating system of network node 500. The entities within network node 500 in FIG. 8, such as application entity 532, transport entity 534, IP entity 536 and layer-2 entity 538 may be implemented in a variety of ways. They may be implemented as processes executed under the native operating system of the network node. The entities may be implemented as separate processes or threads or so that a number of different entities are implemented by means of one process or thread. A process or a thread may be the instance of a program block comprising a number of routines, that is, for example, procedures and functions. The entities may be implemented as separate computer programs or as a single computer program comprising several routines or functions implementing the entities. The program blocks are stored on at least one computer readable medium such as, for example, a memory circuit, memory card, magnetic or optic disk. Some entities may be implemented as program modules linked to another entity. The entities in FIG. 5 may also be stored in separate memories and executed by separate processors, which communicate, for example, via a message bus or an internal network within the network node. An example of such a message bus is the Peripheral Component Interconnect (PCI) bus.
It is obvious to a person skilled in the art that with the advancement of technology, the basic idea of the invention may be implemented in various ways. The invention and its embodiments are thus not limited to the examples described above; instead they may vary within the scope of the claims.

Claims

1. A method, comprising:

sending a transport connection establishment request from a first network node to a second network node;

obtaining a node name for said second network node;

detecting a handover condition in said first network node;

obtaining a second address for said first network node;

updating said second address for said first network node to a name service node; and

sending a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said connection.

2. The method according to claim 1, the method further comprising:

adding a public key of said first network node to said transport connection establishment request;

obtaining a public key for said second network node;

computing a shared secret with said public key of said first network node and said public key of said second network node; and

computing said token using said shared secret.

3. The method according to claim 1, the method further comprising:

detecting a timer expiry for a reply to said transport connection migration request;

obtaining a second address for said second network node using said node name for said second network node; and

sending said transport connection migration request to said second network node, said transport connection migration request comprising said token.

4. The method according to claim 1, the method further comprising:

starting a first transport process upon sending the transport connection migration request in said first network node;

starting a second transport process upon receiving the transport connection migration request in said first network node;

detecting connection migration completion of said first transport process; and

abandoning said second transport process.

5. The method according to claim 1, wherein said transport connection comprises a transport control protocol connection.

6. The method according to claim 1, wherein said name service node comprises a domain name server.

7. A communication system comprising:

a first network node configured to send a transport connection establishment request to a second network node, to obtaining a node name for said second network node, to detect a handover condition, to obtain a second address, to request updating of said second address for said first network node to a name service node and to send a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said transport connection;

said second network node configured to receive said transport connection establishment request and to receive said transport connection migration request; and

said name service node to receive said request for updating of said second address for said first network node.

8. The communication system according to claim 7, the system further comprising:

said first network node configured to add a public key of said first network node to the transport connection establishment request, to obtain a public key for said second network node, to compute a shared secret with said public key of said first network node and said public key of said second network node and to compute said token using said shared secret; and

said second network node configured to provide said public key for said second network node to said first network node.

9. The communication system according to claim 7, the system further comprising:

said first network node configured to detect a timer expiry for a reply to said transport connection migration request, to obtain a second address for said second network node using said node name for said second network node and to send said transport connection migration request to said second network node, said transport connection migration request comprising said token.

10. The communication system according to claim 7, the system further comprising:

said first network node configured to start a first transport process upon sending the transport connection migration request, to start a second transport process upon receiving the transport connection migration request, to detect connection migration completion of said first transport process and to abandon said second transport process.

11. The communication system according to claim 7, wherein said transport connection comprises a transport control protocol connection.

12. The communication system according to claim 7, wherein said name service node comprises a domain name server.

13. A network node comprising:

a transport entity configured to send a transport connection establishment request to a second network node, to obtaining a node name for said second network node, to detect a handover condition, to obtain a second address, to request updating of said second address for said network node to a name service node and to send a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said transport connection.

14. A network node comprising:

means for sending a transport connection establishment request to a second network node;

means for obtaining a node name for said second network node;

means for detecting a handover condition;

means for obtaining a second address;

means for requesting the updating of said second address for said network node to a name service node; and

means for sending a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said transport connection.

15. A computer program embodied on a computer readable medium, the computer program comprising code for controlling a processor to execute a method comprising:

sending a transport connection establishment request to a second network node;

obtaining a node name for said second network node;

detecting a handover condition;

obtaining a second address;

requesting the updating of said second address for a network node to a name service node; and

sending a transport connection migration request to said second network node, said transport connection migration request comprising a token identifying said transport connection.

16. The computer program according to claim 15, wherein said computer readable medium is a removable memory card.

17. The computer program according to claim 15, wherein said computer readable medium is a magnetic or an optical disk.