U.S. patent application number 11/646279 was filed with the patent office on 2008-04-24 for method for performing handovers in a communication system.
This patent application is currently assigned to Nokia Corporation. Invention is credited to Mikael Latvala, Janne Tuononen, Yi Wu.
Application Number | 20080095138 11/646279 |
Document ID | / |
Family ID | 37232201 |
Filed Date | 2008-04-24 |
United States Patent
Application |
20080095138 |
Kind Code |
A1 |
Wu; Yi ; et al. |
April 24, 2008 |
Method for performing handovers in a communication system
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.
Inventors: |
Wu; Yi; (Beijing, CN)
; Latvala; Mikael; (Helsinki, FI) ; Tuononen;
Janne; (Helsinki, FI) |
Correspondence
Address: |
SQUIRE, SANDERS & DEMPSEY L.L.P.
14TH FLOOR, 8000 TOWERS CRESCENT
TYSONS CORNER
VA
22182
US
|
Assignee: |
Nokia Corporation
|
Family ID: |
37232201 |
Appl. No.: |
11/646279 |
Filed: |
December 28, 2006 |
Current U.S.
Class: |
370/342 |
Current CPC
Class: |
H04W 36/24 20130101;
H04L 69/163 20130101; H04L 29/12301 20130101; H04W 36/0011
20130101; H04W 80/06 20130101; H04L 61/2076 20130101; H04L 69/16
20130101; H04W 8/26 20130101; H04W 36/12 20130101 |
Class at
Publication: |
370/342 |
International
Class: |
H04B 7/216 20060101
H04B007/216 |
Foreign Application Data
Date |
Code |
Application Number |
Oct 24, 2006 |
FI |
20060936 |
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.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] 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.
[0003] 2. Description of the Related Art
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] In one embodiment of the invention, the transport connection
is a transport control protocol connection.
[0018] 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.
[0019] In one embodiment of the invention, the communication system
comprises an IP multimedia subsystem.
[0020] In one embodiment of the invention, the communication system
comprises a packet switched network, for example, an Internet
Protocol (IP) network.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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
[0025] 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:
[0026] FIG. 1 is a block diagram illustrating the Transmission
Control Protocol (TCP) segment headers in prior art;
[0027] FIG. 2 is a message sequence chart illustrates transport
connection migration support for only client in one embodiment of
the invention;
[0028] FIG. 3A is a message sequence chart illustrating transport
connection migration in one embodiment of the invention;
[0029] FIG. 3B is a message sequence chart illustrating the
continuation of transport connection migration in one embodiment of
the invention;
[0030] FIG. 4A is a flow chart illustrating a method for the
completion of handover in one embodiment of the invention;
[0031] FIG. 4B is a flow chart illustrating the continuation of the
method for the completion of handover in one embodiment of the
invention; and
[0032] FIG. 5 is a block diagram illustrating a network node in one
embodiment of the invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS
[0033] Reference will now be made in detail to the embodiments of
the present invention, examples of which are illustrated in the
accompanying drawings.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] FIG. 4A is a flow chart illustrating a method for the
completion of handover in one embodiment of the invention.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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).
[0067] 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.
[0068] 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.
[0069] 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.
[0070] FIG. 4B is a flow chart illustrating the continuation of the
method for the completion of handover in one embodiment of the
invention.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
* * * * *