WO2007081689A2 - End-to-end architecture for universal mobility and wireless-aware transport - Google Patents

Abstract

Embodiments of the present disclosure may provide a network node that communicates data with a second network node over a plurality of networks. The network node includes a fixed micronode and a mobile micronode. The fixed micronode sends a packet to the mobile micronode, where the packet includes a portion of the data and a fixed connection-tuple. The mobile micronode includes replaces the fixed connection-tuple in the packet with a mobile connection-tuple, and forwards the replaced packet to the second network node.

Description

END-TO-END ARCHITECTURE FOR UNIVERSAL MOBILITY AND

WIRELESS-AWARE TRANSPORT

[0001] The present application claims the benefit of U.S. Provisional Application No. 60/756,656, filed on January 5, 2006; U.S. Provisional Application No. 60/774,502, filed on February 16, 2006; U.S. Provisional Application No. 60/774,720, filed on February 16, 2006; U.S. Provisional Application No. 60/790,240, filed on April 6, 2006; and U.S. Provisional Application No. 60/791,689, filed on April 12, 2006.

BACKGROUND

1. Field

[0002] The present disclosure generally relate to seamless data networking services for mobile and nomadic devices, and, particularly, to using an end-to-end approach for providing universal mobility with wireless awareness for TCP/UDP connections and circuit- switched voice connections.

2. Background

[0003] With the rapid progress of wireless communication, the need for universal mobility has arisen. As used herein, the term "universal mobility" means connection establishment or maintenance between any two devices with data communication ability, such as cell phones, PDAs, laptops, desktop computers, and etc., which may either remain stationary for a period of time or move/roam across different wireless or wired access networks. For simplicity, any device with data communication capability that can be re- attached to different points in data networks will be referred herein as a mobile terminal (MT), regardless how mobile it may actually be.

[0004] A major theme in data and multimedia communication today is that of convergence. By convergence, different kinds of mobile terminals are to communicate with one another via different wireless or wired access networks with one or multiple network interfaces. In the case of IP networks, the terminals are often assigned with private or dynamic IP addresses. Accordingly, there is a need for seamless connections between any two MTs while moving across different data access networks, with possibly private or dynamic IP addresses.

[0005] While there exist numerous mobility support protocol suites for IP networks, most if not all require gateways to be inserted in the network infrastructure. Two prominent suites are the Mobile Internet Protocol (MIP), and the Session Initiation Protocol (SIP) suites, both being IETF standards. SIP mobility support is often offered together with the IMS protocol suite as a complete package, known together as SIP/IMS in the industry.

[0006] Therefore, there is urgent need for mobility support without any network infrastructure support: the functionalities needed are only implemented in the end hosts (the MTs) that communicate with one another. Such approach is called the end-to-end approach, which is preferred by most enterprises for its scalability and reduced costs associated with zero network infrastructure support.

[0007] MIP adds mobility management at tlie IP layer of the data traffic while SIP/IMS adds it only on a signaling plane (i.e., used only during the call or connection setup phase). Both of them are only suited for macro-mobility (i.e., for infrequent movements of MTs across different networks). Moreover, both MIP and SIP/IMS require complex and costly upgrades to existing network infrastructures.

[0008] Accordingly, there is required a method to seamless handoff between a VoIP connection and a circuit-switched voice connection inside the same terminal, which is a special case of mobility support between cellular voice and VoIP over WiFi. Current solutions include UMA (unlicensed mobile access), Mobilelgnite, and SCCAN. However, all these solutions require network infrastructure support. Thus, there is still a need for an end- to-end solution wherein no network infrastructure support is needed. An aspect of the present disclosure, while only providing a special case of the general mobility solution between VoIP over WiFi and cellular voice, is light weight, scalable, and efficient compared to the popular solutions, by virtue of the end-to-end approach.

[0009] Architecture in accordance with an embodiment of the present disclosure is named end-to-end mobile-to-mobile, or in short form, E-MTM. This name reflects the emphasis on the end-to-end approach to provide mobility and wireless-aware QoS (quality of service) support from mobile terminals to mobile terminals, without any network infrastructure support.

[0010] The E-MTM architecture is a purely terminal-based decentralized solution which affords certain advantages over existing systems (e.g., MIP, SIP/IMS, etc.). For example, the E-MTM architecture may have a shorter time-to-market as compared to solutions requiring network-side upgrades. In addition, the E-MTM architecture may be highly scalable without the need to scale the mobility management nodes inside the network as the number of terminals using the network increases. [0011] According to one aspect of the present disclosure, the E-MTM architecture enables data packets to routed correctly even if packets have to traverse NAT (network address translation) or firewall boxes, or if the MT's IP address changes dynamically, e.g. in a CDMA2000 network after a wireless-disconnect-and-PPP-reconnect. As of this writing, there exists no solution to provide dynamic NAT travel with an end-to-end approach except the solution disclosed in the co-depending PCT application no. PCT/US2006/035630.

[0012] The second background of the present disclosure relates to the wireless aware quality of service (QoS) improvements using the end-to-end approach. As used herein the term "wireless-aware transport" means that the functionalities implemented in the mobile terminals will optimize their transport behaviors to satisfy the application QoS requirements, and to adapt to the dynamic wireless link characteristics, both uplinks and downlinks.

[0013] While there exist numerous schemes to improve TCP and UDP for wireless- aware-transport, it is desirable to provide a pure end-to-end approach that still attains almost the same performance as the gateway or in-network (infrastructure support required) approaches.

[0014] Finally, an aspect of the present disclosure relates to a wireless-aware striping of data flow for a single connection, even when the mobile terminals involved in the connection are moving. Similar software technologies that exist require multiple TCP/UDP connections to be used, while embodiments of the present disclosure may use one single TCP/UDP connection. For example, the solutions provided by Mushroom Networks and WiBoost must set up one TCP/UDP connection per network interface, while embodiments of the present disclosure may retain one single TCP/UCP connection while utilizing multiple network interfaces. In a sense, the present disclosure relates to a software bonding technology that bonds bandwidths from multiple access networks. There exist numerous hardware bonding technologies that bond bandwidths from multiple wireless access networks, all requiring specialized chip sets.

SUMMARY

[0015] Particular embodiments of the present disclosure provide a system and method for providing seamless handoffs for mobile terminals to move across different data networks, with zeto network infrastructure support.

[0016] Other embodiments of the present disclosure provide a system and method for providing mobility management and signaling for mobile terminals to move across different data networks, with 2ero network infrastructure support.

[0017] Other embodiments of the present disclosure provide a system and method for ensuring data packets are correctly routed, even if packets have to traverse NAT/ firewall boxes, or if the IP addresses of the mobile terminals are dynamically changing, with zero network infrastructure support.

[0018] Other embodiments of the present disclosure provide a system and method for directly routing data packets between mobile terminals moving across different IP networks, without network infrastructure support.

[0019] Other embodiments of the present disclosure provide a system and method for providing striping the data packet flow from a mobile terminal while moving across different IP networks, without network infrastructure support. [0020] Other embodiments of the present disclosure provide a system and method for providing seamless handoff between a circuit switched voice/video phone connection and a packet switched VoIP connection inside a mobile terminal while moving across different networks, without network infrastructure support.

[0021] Other embodiments of the present disclosure provide a system and method for providing transparent one-sided TCP behavior modification in one mobile terminal, without modification on the original TCP module in the same terminal, and without any modification of the TCP module at the other end of the connection, without any network infrastructure support.

[0022] Other embodiments of the present disclosure provide a system and method for providing universal mobility and wireless-aware transport without requiring complex and costly upgrades to existing network infrastructures.

[0023] Other embodiments of the present disclosure provide significant application- relevant QoS improvements over traditional mobility, handoff and roaming schemes.

[0024] In one embodiment, networking intelligence is added purely at the mobile terminals (end-hosts in a network) any gateways or servers are not required to be added in the network. In one embodiment, a mobile micronode is transparent to the applications and TCP/UDP stack running on the terminals.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Arrangements and embodiments may be described in detail with reference to the following drawings in which like reference numerals refer to like elements and wherein: [0026] Figure 1 depicts a communication system in accordance with one embodiment.

[0027] Figure 2 outlines a structure of an MT in accordance -with one embodiment.

[0028] Figure 3 shows an example structure of a packet communicated between a fixed micronode and a mobile micronode, in accordance with one embodiment.

[0029] Figure 4 shows some applicable structures of a packet communicated between a mobile micronode and a network interface, in accordance with one embodiment.

[0030] Figure 5 is a flowchart showing operations that may be performed by an m- node for an outgoing packet, in accordance with one embodiment.

[0031] Figure 6 is a flowchart showing operations that may be performed by an m- node for an incoming packet, in accordance with one embodiment.

[0032] Figure 7 depicts a method for m-adport correction in accordance with one embodiment.

[0033] Figure 8 shows internal and external segments of a TCP connection between an MT and a remote host, in accordance with one embodiment.

[0034] Figure 9 depicts a method for TCP data path processing at an m-node, in accordance with one embodiment.

[0035] Figure 10 depicts a method of frame dropping at an m-node for video quality improvement, in accordance with one embodiment.

DETAILED DESCRIPTION

[0036] A detailed description may be provided with reference to accompanying drawings. One of ordinary skill in the art may realize that the following description is illustrative only and is not in any way limiting. Other embodiments of the present disclosure may readily suggest themselves to such skilled persons having the benefit of this disclosure.

[0037] The following terminologies are employed throughout this disclosure only for the purpose of explaining embodiments of the present disclosure, without limiting the scope of the present disclosure:

[0038] Corresponding Terminal (CT): This term is used herein as the terminal at the other end of a connection associated with an MT.

[0039] Adport of a packet: An adport of a packet is a pair <IP address, port number> where the IP address is an IP header field of the packet and the port number is carried in the corresponding layer 4 port number field of the packet.

[0040] f-node, m-node: A fixed micronode and a mobile micronode, which will be described later, are abbreviated as f-node and m-node respectively.

[0041] IP Connection: This is a transport layer connection over IP networks between two MTs (e.g., MT A and MT B), and is defined by a tuple TAB = (adportl, adport2) where the adportl and adport2 are adports allocated for this connection at f-nodes at MT A and MT B respectively. In addition, as all connections are assumed to be full-duplex, while TAB and TBA are opposite tuples, they refer to the same connection.

[0042] f-adport, m-adport: Adports of an IP connection at any given time at f-node and m-node of a terminal are called f-adport and m-adport, respectively.

[0043] Connection-tuple of a packet: This term refers to a tuple <source adport, destination adport, protocol> where the source adport is an adport carried in source IP address and source port number fields of the packet and similarly for destination adport. The protocol is a number specified in an IP protocol field of the packet. However, since the protocol is not modified by the E-MTM scheme, it can be omitted to effectively define the connection-tuple as <source adport, destination adport>.

[0044] Original tuple (or f-tuple) of a connection: This term refers to a connection- tuple carried inside connection-establishing IP packets i.e., initial connection-establishing packets that are exchanged by two hosts in order to establish their respective states for that connection. During mobility a connection-tuple carried inside packets of a connection may change, but an original tuple of the connection is fixed and kept unchanged. The original tuple is also called fixed connection-tuple (f-tuple) since it is the tuple seen in the connection's packets at an f-node interface of an m-node.

[0045] Overview

[0046] One idea of the present disclosure is to add networking intelligence purely in the mobile terminals by die use of micro-networks. The fundamental problem of the current Internet architecture is that there is no distinction between host identity and attachment point identity (commonly known as address).

[0047] The use of micro-network solves the identity ambiguity problem. The host identity is retained in die present disclosure in the form of fixed node in the micro-network. The attachment point is modeled as the mobile node in the micro-network, and it is allowed to change during the lifetime of the connection. Since the fixed node is never changed during the connection lifetime, there will be no confusion between the mobile host and the ever changing network attachment point. Thus the micro-network architecture solves die identity ambiguity problem; and thereby providing the foundation for the present disclosure.

[0048] Thus, an embodiment in accordance with the present disclosure does not require any gateways or servers to be added in the network, and hence is named end-to-end mobile-to-mobile (E-MTM) architecture.

[0049] An embodiment of the present disclosure is a generalization of the MTM architecture, which is described in the co-pending patent applications with the PCT application no. PCT/US2006/035632, which have been hereby fully incorporated by reference.

[0050] Figure 1 depicts a communication system in accordance with one embodiment. In the system 100 of Figure 1, an MT 102 is communicating with a CT 104 through networks 106-1, 106-2 and/or 110. The MT 102 may be in communication with the networks 106-1 and 106-2 via wireless or wired links and may be mobile or stationary. Access points 108-1 and 108-2 may be used to connect the MT 102 to the networks 106-1 and 106-2, respectively. The MT 102 may have an Internet Protocol (IP) address assigned to it by the network 106-1 or 106-2 with which it is in communication or it may be programmed into the MT. For example, an MT 102 that is a cellular phone may have an IP address assigned to it by the network 106-1 or 106-2 that is an access network, where the wireless provider thereof is a cellular data network.

[0051] Continuing to refer to Figure 1, exemplary types of the networks 106-1 and 106-2 include Code Division Multiple Access 2000 Ix (CDMA2000 Ix) networks, Code Division Multiple Access 2000 Ix Evolution Data Only (CDMA2000 IxEVDO) networks, General Packet Radio Services (GPRS) networks, Universal Mobile Telecommunications System (UMTS) networks, Universal Terrestrial Radio Access Network (UTRAN) networks, Enhanced Data for GSM Evolution (EDGE) networks, High-Speed Downlink Packet Access (HSDPA) networks, WiFi networks, WiMax networks and WiBro networks. The networks 106-1 and 106-2 may also be wired networks including dial-up networks and local area networks (LANs) such as Ethernet and Token Ring networks. The above lists of applicable networks are for the purpose of illustration only and it should be appreciated that any network that may be connected to another network through the use of one or more network layer protocols, such as IP, may be used.

[0052] The network 110 may consist of a single network or multiple interconnected networks. Examples of networks that may make up the network 110 include the Internet, LANs, wide area networks (WANs), digital subscriber line (DSL) networks, and cable networks. They may be packet-switched networks or circuit-switched networks. The above list of networks that may make up the network 110 is exemplary only and it should be appreciated that any network that may be connected to another network through the use of a network layer protocol, such as the Internet Protocol (IP), may be used. An MTID (MT identifier, to be introduced later) name server 112 may optionally exists in connection with the network 110. In this case, the MT 102 and the CT 104 may communicate with the MTID name server 112 through the network 110. However, it should be appreciated that the MTID name server may exist anywhere in the network environment comprising the networks 106-1, 106-2 and 110.

[0053] Hereinafter, various embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. [0054] Transparent (Hidden) Mobile Micronode

[0055] One aspect of the E-MTM architecture in accordance with the present disclosure is die separation of the usual IP protocol processing inside an MT 102 into a fixed micronode (f-node) 202 and a mobile micronode (m-node) 204 for the purpose of mobility management, as shown in Figure 2. In one embodiment, the fixed micronode 202 includes a existing networking stack inside the terminal from a socket layer down to an IP layer. The network 106-1 and 106-2 and the remote CT 104 may only communicate with the mobile micronode 204 of the MT 102, while an application layer 206 in the MT 102 may only see the fixed micronode 202 - the actions of the m-node 204 remain hidden from the application 206 in the MT 102. When the MT 102 moves/roams from a network 106-1 to a new network 106-2, a new IP address assigned to the MT 102 (e.g., by DHCP, static allocation or any other suitable address allocation methods) is immediately assumed by die mobile micronode 204, while die fixed micronode 202 acquires that new address only if no TCP/UDP connections with a CT 104 are currendy running in the MT 102.

[0056] In one embodiment, if an operating system running on the MT 102 is Unix or its variants such as Linux, the m-node 204 can be implemented as a kernel module. This module can be dynamically loaded into a memory or unloaded from it even as die MT 102 is running network application connections.

[0057] In another embodiment, if the operating system running on the MT 102 is from the Windows series, the mobile micronode 204 can be implemented as an NDIS driver. [0058] Terminal Identification and Addressing

[0059] Another aspect of the E-MTM architecture is the separation of the identification and addressing processes for MTs. For identification of MTs, an MTID, a byte sequence carried in packets from an MT 102, is provided to uniquely identify it to any node corresponding with it. In certain embodiments, the MTID is carried in an IP options field of the f-node 202's IP header in the packet. The MTID can be permanent, such as a combination of already available global identifiers such as SIP Names, Mobile Station identification number (MSID), a Network Access Identifier (NAI) such as user@provider.com, or one of its public IP addresses if it possesses one. Alternately, the MTID can be temporary where it is dynamically allocated by the network and exists only when an MT 102 is active or sending/receiving network traffic, yet remains unique during that time.

[0060] The MTID may also be a temporary per-connection MT identifier which is an N-bit number randomly chosen by the MT 102 for each connection, at the beginning of that connection. Here N may be fixed a priori and known to the MT 102.

[0061] The f-adport at the MT 102 for a connection can be chosen as the temporary MTID for the duration of that connection. However, this approach may not guarantee unique MT identification at all times. That is, there are scenarios caused by concurrent mobility of two different MTs where they may send the same f-adport in their packets to the CT at the same time. The only way for the CT to distinguish them then is using truly unique MTIDs. [0062] In certain embodiments, the MTID exchange between MT and CT may be performed using a secure authentication protocol similar to that of the MIP standard, and also using encryption method, e.g., according to the IPsec standard.

[0063] As for addressing, source and destination IP fields of the outermost IP header of an outgoing packet may contain an IP address of the m-node of the source and destination MTs respectively.

[0064] Before starting a connection with a CT 104, the MT 102 may resolve the CT 104's known MTID to its current IP address as possessed by it (or, in a particular case, by its m-node) by using the MTID Name Server 112. This resolution can be done by querying an MTID Name Server 112, akin to a Dynamic-DNS server, located at some suitable point in the network environment, e.g. in connection with the network 110. If MTID uses a conventional naming scheme, the MTID Name Server 112 may be a conventional name server for that scheme, e.g., a DNS Server for DNS-to-IP translation, a Dynamic-DNS Server for DNS to-dynamic-IP-address translation, or an SIP Registrar for SIP names.

[0065] Connection Mobility State and Signaling

[0066] With reference to Figure 3, depicted is one embodiment of a packet 302 communicated between the f-node 202 and the m-node 204. The packet may include a source IP address and a destination IP address in its IP header 304, and a source port number and a destination port number in its layer-4 header 306. An IP address and a port number can collectively be referred to as an adport. Particularly, the IP address and the port number in the packet 302 communicated between the f-node 202 and the m-node 204 can be referred to as an f-adport (fixed adport). Further, the source f-adport and the destination f-adport may constitute an f-tuple 308. For purposes of the present disclosure, the f-tuples for packets of a certain connection (say s) traveling in the MT-to-CT and CT-to-MT directions will be denoted as TMC(S) and TCM(S), respectively.

[0067] In one embodiment, the m-node 204 maintains for the connection s 1) die list of network interfaces 208 over which packets of the connection s will be sent, and 2) for each network interface 208 in that list, the associated mobile connection-tuple (called rumple) which will be die connection tuple of the data packets of die connection s when they exit die m-node 204 and enter that particular interface 208. Moreover, the m-tuple of packets of the connection s when diey exit die m-node 204 at die MT to enter a network interface I will be referred to as TMC(S,I).

[0068] Mobility state signaling includes die m-nodes of MT and CT exchanging current connection mobility state information with each other. The connection mobility state information at MT, signaled to CT, may include the following for each network interface I over which the packets of the connection s are being sent: the binding <MTID, TMC(S), T'MC(S,I)>. In one embodiment, this binding is the basic mobility state information which may be sent for every signaling. Optional additional information sent may include a) NAT adport, b) link QoS information for diis network interface.

[0069] Upon receiving the above state information from MT, CT may then store it locally in a Connection State Table from which it can retrieve an f-tuple for data packets of the connection s received in the future from MT. The connection state table may be maintained by a connection state storage such as the storage 210. Also CT may use the m- tuple conveyed in the state information to update its list of active m-tuples which ate used to send its own connection packets to MT.

[0070] In one embodiment, the mobility signaling is done at MT only when a change in the connection state occurs. However, in general it can be done on a regular basis ranging anywhere from send-once to send-every-packet. The following are the possible events at MT at which the mobility signaling is done:

[0071] (1) Connection start or finish; (2) Network Interface Set Change: change in the set of network interfaces to which MT is currently connected and at which it possesses an active IP address. Changes in network interface can be in the form of m-adport change or change in the available network interfaces.

[0072] Hereinafter, some applicable structure of the packet 402 between the m-node 204 and the network interface 208 or the CT 104, with reference to Figure 4. The packet 402 may include the mobility state information. To be specific, the mobility state information 404 for each connection can be sent by the MT 102 to the CT 104 in many possible ways including the following:

[0073] (a) The mobility state information 404 for each connection may be sent in separate E-MTM signaling packets sent over a separate TCP or UDP signaling connection set up between the m-nodes of MT and CT (e.g., as shown in Figure 4(e)).

[0074] (b) The mobility state information 404 for each connection may be sent in separate E-MTM signaling packets inserted as dummy data packets in the connection, which may be carrying the same m-adport in their layer 3-4 headers as the regular data packets of the connection to the CT (e.g., as shown in Figure 4(e)). [0075] (c) The mobility state information 404 for each connection may be piggybacked onto the data packets of the connection (e.g., as shown in Figures 4(a) to 4(d)). This approach works if there is sufficient space left in the packet to accommodate the mobility information before the packet length overflows beyond the Maximum Transmission Unit (MTU) limit imposed by the link layer. All length fields in the layer 3 and layer 4 headers may be updated to reflect the extra size contributed by the piggybacked information.

[0076] The possible locations in the data packet at which the signaling information can be piggybacked as an extra E-MTM header, as shown in Figures 4(a) to 4(d) include:

[0077] (a) The signaling information may be located in the IP options field in the IP header 304: In one embodiment (see e.g., Figure 4(a)): This approach is used when no router in the MT-CT connection path drops packets carrying IP options.

[0078] (b) The signaling information may be piggybacked using IP-in-IP tunneling (see e.g., Figure 4(b)): In this case, the piggybacked packet's original IP header 304 and the layer-4 port number field respectively contain the IP address part and port number part of the current m-adport for the network interface over which the packet is sent. The mobility state information 404 is then piggybacked in the IP options field of the packet's inner IP header. This IP-in-IP tunneling scheme will work provided the routers along the MT-CT connection path are configured to handle IP-in-IP tunneling.

[0079] (c) The signaling information may be located in the application payload of the packet: This approach avoids the problem that packets with IP options or IP-in-IP being dropped by a middle box. The mobility state information 404 can be inserted at the beginning of the packet's application payload (see e.g., Figure 4(c)), or immediately after the application-layer header (see e.g., Figure 4(c)), or at the end of the packet (see e.g., Figure 4(d)).

[0080] E-MTM Data Transfer

[0081] E-MTM data transfer refers to how the data (Le., the IP packets carrying application connection data towards/from the f-node) may be processed by the m-node. The data transfer actions at an MT for a particular connection s may be specified. As before, the f-tuple for packets of s from MT to CT by TMC(S) and the m-ruple for the packets sent over interface I shall be denoted as TMC(S,I). TO that end, there ate two methods for data transfer actions, depending on the layer at which they are completed: IP layer or TCP layer.

[0082] 1. IP-layer Data Transfer

[0083] Outgoing packets: With reference to Figure 5, in response to receiving a packet p from the f-node (S502), the m-node selects which network interface I to send it out to (S504) before sending the packet p out. The algorithms for this selection constitute the MAPF scheme described below. After the interface selection (S504), the m-node may piggyback its MTID in p in the same manner as the piggybacking embodiments of the previously discussed mobility signaling (S506). The m-node further retrieves a m-tuple TMC(S,I) based on the connection and the selected network interface (S508). Here, the connection may be identified based on the f-tuple of the packet. The m-node. may then replace the connection tuple (the f-tuple) of p (i.e. TMC(S) to T_MC(S,I)) (S510). Recall that the <MTID, TMC(S), T'MC(S,I)> binding is already conveyed to CT inside p in some packet prior to p, and then stored by CT. Thus CT, upon receiving p, may extract TMC(S,I) from p, look up the corresponding original tuple TMC(S) which may then be replaced back into p before delivering p to the f-node at CT.

[0084] Incoming packets: ^"With reference to Figure 6, after receiving a packet p from CT on a network interface I (S602), and before forwarding p to the f-node (S610), the m- node of MT may remove the E-MTM signaling header from the packet, if present. The m- node of MT may then extract from the removed E-MTM header, the source MTID of CT and the connection tuple TCM(S_JI¹) of p (S604). Thereafter, the binding b for TCM(S,I) from its connection state table may be looked up in order to extract TCM(S,I) (S606). The m-node may then translate the connection-tuple of p to its original, i.e. TCM(S,I) (S608). If p is a pure E-MTM signaling packet, the m-node will drop it after processing and recording the state information inside the packet as described above under Connection State Storage.

[0085] 2. TCP Layer Data Transfer

[0086] The TCP connection termination may apply only when the connection is a TCP connection. Here, the m-node effectively performs the same actions as outlined above on an outgoing or incoming packet during the time the packet spends in the m-node. However, in addition the m-node also acts as a hidden TCP proxy for the original end-to- end TCP connection between the f-nodes of the MT and its CT. That original connection therefore gets spliced into 3 parts each of which behaves as a TCP connection: MT-f-node

^■^MT-m-node^CT-m-node^→CT-f-node. The splicing, however, may remain transparent

to the f-nodes and the TCP applications on MT and CT. [0087] E-MTM's Solution to the NAT Traversal Problem

[0088] A NAT (Network Addtess Translation) router in the path of a packet traveling from an MT to a remote CT can change the packet's m-adport field. This new adport value set by the NAT router may be referred to as the packet's nat-adport or n- adport. During the MT's mobility from one network or subnet to another, or when the MT reconnects after a disconnection, its n-adport may change thereby causing the TCP/UDP connections between MT and CT to drop. E-MTM architecture's solution to this problem is to first have the CT¹ s m-node inform the MT's m-node of the n-adport value of the MT that it is seeing in the packets it is receiving from the MT. When the MT receives its own n- adport information from the CT, it may start inserting its own n-adport value in a source n- adport field in each packet it sends to the CT. In one embodiment, the source n-adport field replaces the source f-adport field in the packet. In another embodiment, the source n- adport field is an extra field added alongside the source f-adport field in the packet.

[0089] 1. M-adport Correction to SIP Messages

[0090] The following tasks may also be carried out at the MT and CT to correct the source f-adport values in SIP signaling messages sent out:

[0091] (a) With reference to Figure 7, upon receiving (S702) any SIP signaling message M (in one or several packets) from the MT's f-node, carrying the source f-adport value, the MT's m-node will 1) buffer a copy of M (S704) before sending it out (S706) and 2) wait until it receives from the CT, its own n-adport value for the packets carrying M (S708). Upon receiving that n-adport value, the MT replaces the source f-adport value written in M to the n-adport value (S710). This is known as SIP message correction and the resulting corrected packets of M are known as SIP-corrected packets. Optionally, the MT may also insert its n-adport field in the buffered packets of M. MT then retransmits to the CT, all these SIP-corrected buffered packets of M (S712).

[0092] (b) Upon receiving the original packets of message M, the CT buffers them but does not forward them to its own f-node. Instead it sends back to the MT, the n-adport value seen in those packets. Later upon receiving the SIP-corrected packets of M, the CT forwards those packets to its f-node.

[0093] 2. NAT Hole Punching

[0094] Handling NAT Blockade of 'Unsolicited' Incoming Packets: A NAT router at the edge of MT's access network may be configured to block a packet p sent by the CT to the MT unless the MT has first sent at least one packet to CT in the opposite direction and belonging to the same connection as p via the NAT router.

[0095] The E-MTM architecture automatically solves this blockade problem using the mobility signaling embodiment previously discussed (see Figure 4(e)). In that embodiment, dummy E-MTM signaling packets carrying the same connection-tuple as the regular data packets of the connection get sent from the MT's m-node .to the CT even when there are no regular data packets to send. These dummy packets ensure that a hole is punched inside the NAT router for their connection (i.e. the router recogniaes that one of its MT clients has initiated a connection to an outside host CT and accordingly sets up state for that connection). The router may subsequendy be able to forward all incoming packets from the CT to the MT's current m-node IP address under the router's jurisdiction. [0096] E-MTM's Fast Handoff

[0097] When an MT moves into a new network, there is usually a substantial latency in acquiring a new IP address from the new network's address allocator such as DHCP server. During this time, even though MT possesses no valid IP address, the E-MTM can maintain uninterrupted data flow to /from the CT via the new network using MAC-layer methods. Thus, the handoff delay gets reduced to only the smaller time required for the MT to acquire a new access point's MAC address. For example, in WiFi, only 20-30 ms are needed to acquire a new network's access point MAC address while more than 100-500 ms is usually needed to acquire a new IP address from the DHCP server of the network.

[0098] Two complementary methods providing the above kind of handoff acceleration are described below. Both may be implemented in networks that have an Ethernet-like MAC addressing scheme (e.g. WiFi₃ WiBro, and WiMax networks). In addition, both may be implemented in the m-node of the MT.

[0100] 1. Fast Handoff Using pure MAC-layer routing

[0101] This approach is a partial solution in the sense that it only maintains data flow from MT to CT during the pure-MAC routing phase, but not in the opposite direction, unless the MT and CT can directly exchange MAC frames. The approach proceeds as follows: The m-node does a fast detection of the MAC address of its new MAC access point in the new network. If the CT is detected as connected to same access point, the m-node sends a MAC frame carrying a connection's IP packet directly to the CT. Otherwise, the m- node requests the MT's MAC driver to set the destination MAC address to that of the new access point. The assumption here is that the access point is bundled with an IP router which will extract the IP packet inside the received MAC frame from the MT and forward it to its destination IP address at the CT.

[0102] 2. Fast Handoff Using reserved IP address pool

[0103] This approach is virtually end-to-end since it requires some configuration at the access points. Namely, a pool of IP addresses is reserved by the access point supporting the fast handoff for temporary use by MTs. This address pool, or parts of it, are known apriori to all MTs that implement this fast handoff scheme. When the MT moves into the vicinity of and acquires the MAC address of a new access point, its m-node selects some address from the reserved pool to use as its temporary IP address. Until it acquires its new IP address from the new access point's network, the m-node uses the temporary address in the m-adports in all data packets of currently active connections that terminate at some remote E-MTM-enabled CT. The change to/from this temporary address is handled using the same mobility signaling and data transfer scheme described above. One important issue is that of collision (i.e., two MTs choosing the same temporary address during the same time). The methods to avoid/resolve collisions are as follows:

[0104] • Random IP address for Minimizing Chance of Collision: In this method, the

MT selects a random IP address from the pool. Since the different MTs take independent random decisions, the probability of two MTs selecting the same address is as small as 1/N² where N is the pool size. This method may be supported by the full collision resolution method described next.

[0105] • Address-Sense-Multiple-Access (ASMA): This is an IP-layer version of

Ethernet's Carrier Sense Multiple Access (CSMA) scheme. It is only possible when the different MTs connected to the same access point can sniff/inspect each other's packets, e.g. in Ethernet-based network media such as WiFi or WiMax. The method at an MT is as follows and is described in the context of Ethernet though it should apply to other MAC schemes similar to Ethernet: The MT inspects, in the 'promiscuous' mode, all MAC frames transmitted by other MTs in the network medium, to collect all the reserved IP addresses currently being used by other MTs. It uses this information to carefully select/reserve an IP address that is not currently being used nor will be used by another MT during this MT's handoff interval. Different resource allocation protocols such as token passing, time- division-multiplex, etc. can be used to ensure that the MTs coordinate each other's IP address reservations in a decentralized manner without need to involve any network element such as access point itself in the coordination. In all these protocols, special bits in MAC frames are placed by the MT on the network medium to signal other MTs that it has currently reserved a particular IP address. When the fast handoff is complete, the MT will similarly signal the release of the reserved IP address to other MTs.

[0106] 3. Predictive-Handoff Enhancement of the above two methods [0107] Latency may be further reduced by eliminating even the time (20-30ms) to detect the new access point. This may be done by caching neighboring access point addresses seen in the recent past and multicasting the same IP packet in different MAC frames each to one of those cached access point addresses. For QoS, the MT may choose the access points to which to multicast based on their current available bandwidth and link quality. [0108] Multi-Access-Network Packet Forwarding (MAPF)

[0109] This embodiment is a generalized end-to-end IP-layer version of the physical layer soft handoff schemes such as of CDMA2000. This embodiment is also a form of bandwidth pooling or bonding where an MT is able to simultaneously use multiple network bandwidths with a single TCP /UDP connection. In MAPF, a packet flow between an MT and its CT gets intelligently striped (i.e., split and routed via multiple access networks to which the MT and CT are connected). An example is a tri-mode MT with a WiFi, WiMax and CDMA interface.

[OUO] The m-node maintains a MAPF state which contains link/route state information such as bandwidth, delay, losses, error rate and signal strength per access network of the MT. It uses this link/route state information to select which interface each packet of a connection must be sent to. Two different cases of MAPF are (i) soft handoff which multicasts copies of the same packet to multiple access networks, and (ii) select-cast which selects the current best access network link to route the packets over. In one embodiment, MAPF does QoS-aware load balancing (i.e., stripes packet flows over the multiple access networks according to application-wise QoS and network load balancing criteria).

[0111] E-MTM's Transparent One-Sided TCP (Trans-TCP) [0112] The Trans-TCP scheme for improving quality of a TCP connection between an MT and any other remote host (not necessarily running E-MTM or Trans-TCP) is as follows. The term "transparent" as used herein means that the applications running on the MT and the sockets and TCP/IP stack in the MTs f-node do not have to be modified.

[0113] Each TCP connection 810 between MT 802 and the remote host (RH) 804 gets spliced into an internal segment 812 and an external segment 814 as shown in Figure 8. The internal segment 812 is between f-node 806 and m-node 808 of the MT 802 and uses ordinary TCP as seen by the applications and sockets running in the MT 802. The external segment 814 is between the RH 804 and the m-node 808 of the MT 802. It uses a flow control and retransmission scheme whose behavior is jointly optimized to adapted to all bottleneck links, such as wireless links, in the path between the MT 802 and the RH 804.

[0114] In one embodiment of the Trans-TCP described above, the following tasks may be carried out by the MT's m-node 808:

[0115] 1. Connection Path State Monitoring for Trans-TCP

[0116] The MT's m-node 808 regularly monitors the state of the external segment 814's network path. This external path state is evaluated in general as a BDLES (i.e. some combination of Bottleneck Available Bandwidth (BAB), Packet Delays (D), Packet Loss (L), Error Rate (E), and Signal Strength (S)). The path state monitoring may be based on some suitable combination of B, D, L, E, and S, depending on the kind of bottleneck networks expected in the external segment 814's path.

[0117] In one embodiment, only the BAB in the upstream (MT-to-RH) path may be estimated at the MT 802. This may proceed as follows: the MT's m-node 808 updates its upstream BAB estimate T seconds or N received TCP ACKs after the previous such update. Here T and N can be tunable parameters or could change dynamically with time. The BAB estimate update may be computed as: BAB = X/T¹ where X is the amount of upstream TCP bytes of the connection acknowledged inside the TCP ACKs received since the previous such BAB update, and T' is the time elapsed since previous such BAB update.

[01181 In another embodiment, the RH 804 is also E-MTM-enabled with a corresponding m-node (not shown). Then the m-nodes of MT 802 and RH 804 will exchange their own upstream and downstream BAB estimates to make those estimates more accurate.

[0119] 2. Data Path Processing for Trans-TCP

[0120] With reference to Figure 9, the MTs m-node 808 receives IP packets belonging to the TCP connection 810 from the f-node 806 (S902). The IP packets will be put in the T-send buffer 816 later (S908) so that they are sent to the RH 804.

[0121] Meanwhile, upon receiving M outgoing packets of the TCP connection 810 from the f-node 808 (S902), the m-node 808 may send back a Proxy TCP ACK packet to the f-node 806 (S906). In this case, M is a parameter and normally is either 1 or 2, but can be made tunable or change dynamically. Each such Proxy TCP ACK is an IP packet with a source adport set to that of the RH and destination adport set to that of the MT's f-node. The other TCP and IP header fields of the proxy ACK are set to exactly those values expected to be carried in the corresponding real ACK going to be received from the RH in the future. The payload of the proxy TCP ACK is constructed by moving R payload bytes extracted from the T-receive buffer to the payload field of the proxy ACK, where R is not larger than the Max-Segment-Size (MSS) of the TCP. connection. If the T-receive buffer is currently empty, the payload is set to null. The m-node sets the advertised window field value in the proxy ACK to some suitable fraction of the empty space available in the T-send buffer.

[0122] Also, the m-node sets the Acknowledgement Number field of the proxy ACK to A + 1, where A and 1 are respectively the Acknowledgement Number of the previous proxy ACK sent to the f-node and the total TCP payload length of all the outgoing packets of the connection received from the f-node since the previous proxy ACK was sent to the f- node.

[0123] Loss Detection for Trans-TCP: The m-node uses the following methods to detect which TCP bytes sent out previously got lost:

[0124] • Packets sent out to the RH 804, but not yet acknowledged by the RH 804,

will be referred to as "unacked packets." The m-node 808 saves a copy of each unacked packet (S904) and removes that copy (S912) once the packet gets ACKed by the RH 804 (S910).

[0125] • If the TCP connection is using SACK, the packets lost are found from the

SACK block information carried in the real ACKs from the RH.

[0126] • If a TCP ACK is not received from the RH within rto (retransmit time-out)

seconds of the latest received real ACK, the m-node estimates the first L of the unacked packets as lost. The value of rto can be made static and tunable or could be adapted with time as a function of the BAB and the round-trip time statistics obtained from the path state monitoring.

[0127] • Upon receiving DA number of "duplicate ACKs" (i.e. ACKs carrying the

same Acknowledgement Number field value) from the RH, the m-node estimates the first L' of the unacked packets as lost. [0128] • Here L and L¹ are determined in general as a function of the number DA of

latest received duplicate ACKs, the number U of currently unacked packets and the current BDLES path state of the connection. In a simple embodiment, L = U and L' = U - DA.

[0129] Retransmission for Trans-TCP: When new lost packet estimates are obtained as per the above steps, the m-node 808 adds previously saved copies of those packets to the head of the T-send buffer 816 (S908) in the order of their TCP sequence numbers.

[0130] Transmit Rate (TR) Control: The m-node transmits packets from the T-send buffer to the network at a regulated transmit rate denoted by TR. The value of TR is determined in general by the current BDLES path state. In one specific embodiment, TR is updated whenever BAB is updated, as TR = BAB + Q/D where Q is an estimated sum of the queue space available for this connection at the bottleneck links in the path plus some suitable fraction of the advertised window size in the latest received real ACK from RH.

[0131] Transmit Window Control: When a packet is ready to be transmitted as per the TR control, it is transmitted only if U+l <= W where U is the number of currently unacked packets. After a packet is transmitted, U is incremented by 1. Here W is the send- window size which is adapted based on the current BDLES state of the connection. In a simple embodiment, W is set to a tunable initial value at the TCP connection start and later to W = TR*D every time TR gets updated based on the BDLES estimates.

[0132] Upon receiving an incoming packet of the TCP connection, the m-node queues it in the T-receive buffer.

[0133] 3. Handling TCP Signaling Packets for Trans-TCP

[0134] In one embodiment, the m-node applies the actions described above under the TCP Data Path Processing only after it detects the TCP connection has completely established between MT and RH i.e. after detecting the initial SYN-SYNACK-ACK sequence. When a connection reset (ElST) packet is received from the f-node, the m-node sends it out to the network and stops sending any more proxy ACKs to the f-node until the T-receive buffer becomes non-empty.

[0135] E-MTM's Transparent Wireless Video Quality Improvement

[0136] Another aspect of the present disclosure is to improve streaming video quality by making sure that the bottleneck link in the MT-CT path gets filled with video bits in the order of their importance to video quality. Unlike previous approaches, this approach enables the improvement of video quality transparendy for applications, without requiring special QoS or transcoding gateways in the network path.

[0137] In certain embodiments, 3 components inside the m-node are used to achieve the improved streaming video quality. They are path BDLE monitoring, intelligent video frame dropping, and flow control. The BDLE monitoring proceeds in the same way as described above for Trans-TCP. Meanwhile, with reference to Figure 10, the frame dropping for wireless video improvement performs the following tasks:

[0138] According to an embodiment, video frame types carried in each packet received from the f-node are detected via deep packet header inspection (S 1002). For example, distinguish MPEG I-frames, P-frames, and B-frames.

[0139] One embodiment divides outgoing packet stream into individual sub-streams each containing one frame type (Sl 004). Let outgoing rate of i_th most important frame type (called type i) be r_i. If bottleneck available bandwidth obtained from the BDLE monitoring is B, then let x be the frame type such that sum__{i<=x}(r_i) > B. That is, the bottleneck bandwidth in the MT-CT route will just start to fill up when all the substreams up to frame type x are completely transmitted out of the terminal (S1006, S1008). Hence some frames from type x or larger have to be dropped.

[0140] The embodiment drops B out of surn_{i<=x}(r_i) frames for type x or larger using a rate-based or credit-based approach (SlOlO).

[0141] E-MTM¹S Circuit-Packet (C-P) Handoff

[0142] In certain embodiments of the present disclosure, the seamless transfer of a call between a circuit switched and packet-switched path between the MT and CT on purely end-to-end basis may be enabled without requiring any network-side upgrades. In one embodiment, the fixed micronodes in the terminal contain the circuit-switched call stack in addition to the packet-based TCP/IP stack. The C-P handoff scheme is general and can be used for handoff of any application which can be used by both MT and CT over both the circuit and packet networks of their respective carriers or ISPs. It is assumed that both MT and CT have circuit-switched and packet-based network access interfaces (e.g. multi-mode CDMA cell phones with WiFi or WiMax cards). Voice and video conferencing are the examples of applications using the C-P handoff. For example, the C-P handoff will enable switching to a VoIP call from a circuit-based cell phone call when the terminal moves into an ISP zone such as a WiFi hotspot or WiMax cell.

[0143] In the following description, a 'link' simply refers to the link-layer connectivity from a network interface of the MT up to the network's link-layer access point (such as base station, Ethernet switch, etc). Also the term 'connection' now also encompasses circuit- switched calls, such as phone calls.

[0144] This handoff protocol runs between the m-nodes of the MT and CT. At any given time, the m-node uses either the circuit network interface or a suitable combination of available packet network interfaces. A set of links not currently being used for the call is called an alternate link set. In one embodiment, the C-P handoff may consist of two components:

[0145] (a) Location and Link Quality Monitoring and Prediction for C-P Handoff:

[0146] The m-node may perform link state monitoring (i.e. signal quality and/or BDLE monitoring of its network interface links including the circuit-switched link). The location tracking, if available, combined with learning of past MT movements, may be useful for making accurate link state prediction. In particular, the monitored estimates and the location tracking of the MT, if available, may be combined to make a prediction of whether the best state of any alternate link set in terms of BDLE and signal quality will remain sufficiently better than the state of the currendy used links for a sufficiently long period of time into the future. If so, the handoff status may become 'switch-ready' and the call switching component activated.

[0147] (b) C-P Connection Switching:

[0148] Once activated, this component in the m-node immediately does an advance connection setup over the alternate link set selected by the prediction module even before terminating the connection over the current link. The appropriate application for initiating this call may be invoked by the m-node. For example, if a circuit voice call is in progress and a wireless packet interface, such as WiFi, becomes strong enough in signal quality, the VoIP application in the MT is invoked to set up a VoIP call in advance to the CT's VoIP application, even before the current circuit voice call is terminated. In general, after the advance call setup is over, the data flow over the alternate link can also begin in advance. .

[0149] The data bits belonging to diis flow during the time when the current call has not yet terminated at an MT are called advance data bits at that MT. The m-node at the CT will keep dropping the advance data bits which reach it, as long as the current call's link quality is good enough. The call application (such as VoIP app) for which advance bits are destined, must be configured so as not to drop the call even when it is not receiving data bits. This configuration may be kept under the control of the m-node. When the current link's quality has degraded for a predetermined amount of time, or the current call has terminated, the CT's m-node immediately starts delivering the advance bits to the f-node. At this point, the handoff is complete.

[0150] The C-P scheme described above assumes that (i) there is one transducer for producing each type of real-time content for the call, such as a microphone for voice or camera for video conferencing, (ii) in general, different encoders may be used for calls over the circuit and packet based interfaces. The output of a transducer is then fed in parallel to each of these encoders (e.g., a CDMA voice call and VoIP-over-WiFi call may use different encoders suited for respective CDMA and WiFi characteristics), and (ϋi) the encoder outputs then get application- framed and possibly packetized and fed into the f-node's call stack such as CDMA call stack or TCP/IP stack. The resulting bits or packets of content for both circuit and packet calls are finally intercepted by the m-node.

[0151J Circuit-Packet E-MTM is a generalization of mobility support of the present disclosure for IP networks to include circuit-switched networks. The f-adport as a connection endpoint in the f-node is now generalized to include endpoint identifiers of call circuits. Similarly, the MTID is now generalized to include circuit-based phone numbers. When the phone number is used as MTID, there is no need for a separate MTID Name Server. Instead, an end-to-end method for MTID name resolution may be used. For example, a Phone-Number-to-IP -Address-Translation may be performed as follows: An MT sends a message, such as SMS message, over its circuit-switched link to the CTs phone number requesting the CT's IP addresses. The CT then sends its current IP addresses in a reply message to the MT. This circuit-based messaging can also be used for carrying the E- MTM signaling.

[0152] The term 'packet' should be read to include not only the usual IP packets, but also the content payloads of frames carried on the circuit-switched link. We call these circuit frame payloads as the "c-packets." The m-node may decide to encapsulate one or more outgoing c-packets inside IP packets copies of which it then reroutes on to one or more selected network interfaces. Thus, a normal content flow (such as voice bits of a phone call) destined for a circuit-switched network now gets rerouted or striped or possibly multicast over different circuit-switched networks or over multiple packet-based networks. The exact striping and multicasting algorithm depends on the QoS criteria.

[0153] Conversely the m-node may decide to reroute the payload of an IP packet as a c-packet over a circuit-switched link. In the incoming packet direction, the m-node may ensure that the received c-packets or packets get translated back to their f-adports. If that f- adport was a circuit endpoint, the m-node may extract the application payload of the received packet and encapsulate that back into a circuit frame destined for that circuit endpoint.

[0154] The methods in accordance with the embodiments of the present disclosure can be performed along computer-executable instructions stored in a computer-readable medium. To be detail, in accordance with the practices of persons skilled in the art of computer programming, the disclosure described above with reference to operations may be performed by a computer system or a like electronic system. Such operations are sometimes referred to as being computer-executed. It will be appreciated that operations that are symbolically represented include the manipulation by a processor, such as a central processing unit, of electrical signals representing data bits and the maintenance of data bits at memory locations, such as in system memory, as well as other processing of signals. The memory locations where data bits ate maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits. The term "network node" is understood to include any electronic device, which may contain a processor, such as a central processing unit.

[0155] When implemented in software, the elements of the disclosure may be code segments to perform the necessary tasks. The code segments can be stored in a processor readable medium or transmitted by a computer data signal embodied in a carrier wave over a transmission medium or communication link. The "processor readable medium" may include any medium that can store or transfer information. Examples of the processor readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory or other non-volatile memory, a floppy diskette, a CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc.

[0156] Any reference in this specification to "one embodiment," "an embodiment," "example embodiment," etc., means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with any embodiment, it is submitted that it is within the purview of one skilled in the art to affect such feature, structure, or characteristic in connection -with other ones of the embodiments.

[0157] Although embodiments have been described with reference to a number of illustrative embodiments thereof, it should be understood that numerous other modifications and embodiments can be devised by those skilled in the art that will fall within the spirit and scope of the principles of this disclosure. More particularly, various variations and modifications are possible in the component parts and/or arrangements of the subject combination arrangement within the scope of the disclosure, the drawings and the appended claims. In addition to variations and modifications in the component parts and/or arrangements, alternative uses will also be apparent to those skilled in the art.

Claims

WHAT IS CLAIMED IS:

1. A network node communicating data -with a second network node over a plurality of networks, the network node comprising: a fixed micronode; and a mobile micronode, wherein the fixed micronode includes a unit adapted to send a packet to the mobile i micronode, the packet including a portion of the data and a fixed connection-tuple, wherein the connection-tuple includes an IP address, a source port number, a destination IP address and a destination port number, and wherein the mobile micronode includes: a unit adapted to replace the fixed connection-tuple in the packet with a mobile connection-tuple, wherein the mobile connection-tuple is used to deliver the packet between the mobile micronode and the second network node; and a unit adapted to forward the replaced packet to the second network node.

2. The network node of Claim 1, wherein the mobile micronode further includes: a unit adapted to receive a packet including a mobile connection-tuple from the second network node; a unit adapted to replace the mobile connection-tuple in the packet received from the second network node with a fixed connection-tuple; and a unit adapted to deliver the replaced packet to the fixed micronode.

3. The network node of Claim 1, further comprising: a plurality of network interfaces adapted to interface with the plurality of networks, wherein the mobile micronode includes a storage unit adapted to store: a list of a plurality of connection-tuples; and a table configured to relate the connection-tuples with the network interfaces, wherein, when the packet is to be delivered through one of the network interfaces, the corresponding connection-tuple is used as the mobile connection-tuple.

4. The network node of Claim 3, wherein the mobile micronode further includes: a unit adapted to select a network interface over which the packet is to be delivered.

5. The network node of Claim 3, wherein, when the network node is assigned with a new adport, the fixed connection-tuple remains unchanged as long as there is a connection established between the network node and the second network node, while the mobile micronode reflects the new adport in the table, wherein the adport includes an IP address and a port number.

6. The network node of Claim 1, wherein the fixed micronode maintains a fixed adport which is an element of the fixed connection-tuple, and the mobile micronode maintains a mobile adport which is an element of the mobile connection-tuple, where the adport is a pair of an IP address and a port number, wherein the mobile adport changes as the network node moves among the plurality of networks, while the fixed adport remains unchanged.

7. The network node of Claim 1, wherein the mobile micronode further includes: a module adapted to exchanges mobility state information with the second network node, wherein the mobility state information includes binding of the fixed connection- tuple and the mobile connection-tuple.

8. The network node of Claim 1, further comprising: an application module communicating the data with the fixed micronode, wherein the mobile micronode is transparent to the application module.

9. The network node of Claim 8, wherein the fixed micronode includes: a TCP/IP module adapted to packetize the data into die packets; or a UDP/IP module adapted to packetize the data into the packets.

10. The network node of Claim 1, wherein the packet accompanies an MTID (mobile terminal identification) that identifies the network node.

11. The network node of Claim 10, wherein the MTID is carried in an IP option field in an IP header of the packet.

12. The network node of Claim 1, wherein the mobile micronode includes: a unit adapted to detect connection of the network node to a new network; a unit configured to detect an MAC address of an access point in the new network, in response to the detection of the new connection; and a unit adapted to perform MAC-layer routing based on the detected MAC address.

13. The network node of Claim 1, wherein the mobile micronode includes: a storage unit adapted to cache a plurality of addresses of past access points, wherein the mobile micronode multicasts the packet to at least one of the cached addresses.

14. The network node of Claim 1, -wherein the mobile micronode includes: a storage unit adapted to maintain link/route state information, wherein the link/route state information contains at least one of bandwidth, delay, losses, error rate and signal strength information for each of the plurality of networks; and a unit adapted to select at least one of the plurality of networks for each packet, over which the packet is to be delivered, based on the link/route state information.

15. The network node of Claim 1, wherein the mobile micronode further includes: a buffer configured to buffer the packet when the packet is received from the fixed micronode; a unit adapted to send a TCP ACK to the fixed micronode when the packet is received from the fixed micronode; and a unit adapted to transfer the buffered packet to the second network node under a flow control and retransmission scheme.

16. The network node of Claim 1, wherein the mobile micronode further includes: a monitoring unit adapted to monitor a state of a network path between the mobile micronode and the second network node, wherein the state contains an available bandwidth of the network path.

17. The network node of Claim 16, wherein the mobile micronode further includes: a class distinguishing unit adapted to inspect information in packets received from the fixed micronode to classify the packets into a plurality of classes, wherein the classes are given with priorities; and a packet dropping unit adapted to drop some packets in classes of low priorities, based on the available bandwidth of the network path.

18. The network node of Claim 17, wherein the classes are related to kinds of frames in a streaming data communication.

19. The network node of Claim 1, wherein the fixed micronode includes: a packet-switched protocol stack for packet-switched communication with the second network node; and a circuit-switched protocol stack for circuit-switched communication with the second network node, and wherein the mobile micronode includes: a connection switching unit adapted to perform a connection switching between a packet-based connection using the packet-switched protocol stack and a circuit-based connection using the circuit-switched protocol stack.

20. The network node of Claim 19, wherein the connection switching unit includes: a link state monitoring unit adapted to monitor state of link-layer connectivity between the mobile micronode and the second network node; a prediction unit adapted to predict whether a state of any alternate link will remain better than a state of a current link for a predetermined period, based on the monitored state of the link-layer connectivity; a connection setup unit adapted to set up an advance connection over the alternate link selected by the prediction unit; and a data flow unit adapted to send the data over the alternate link as well as over the current link, until the current link becomes unavailable.

21. The network node of Claim 19, wherein the mobile micronode further includes: an encapsulation unit adapted to encapsulate outgoing circuit frame payloads inside IP packets; and a rerouting unit adapted to reroute copies of the IP packets over one or more network interfaces.

22. The network node of Claim 1, wherein the packets collectively form a packet flow, and wherein the mobile micronode further includes: a unit adapted to maintain a list of available networks among the plurality of networks; a unit adapted to split the packet flow to be striped into one or more substreams; and a unit adapted to send the striped substreams over the available networks.

23. A data communication system comprising: a first network node adapted to communicate data with a second network node over a network, the first network node including a fixed micronode and a mobile micronode, wherein the fixed micronode communicates a packet with the mobile micronode, the packet including a portion of the data and a fixed connection-tuple, the connection-tuple including an IP address, a source port number, a destination IP address and a destination port number, and wherein the mobile micronode delivers the packet between the fixed micronode and the second network node; and an access point in the network, the access point including a pool of reserved IP addresses, wherein the mobile micronode uses at least one of the reserved IP addresses when the first network node is connected to the access point.

24. The system of Claim 23, wherein the mobile micr onode includes: a unit adapted to randomly selects said at least one of the reserved IP addresses to use.

25. The system of Claim 23, wherein the mobile micronode includes: a unit adapted to inspect MAC frames transmitted by other network nodes in the network, to collect currently occupied IP addresses; and a unit adapted to select said at least one of the reserved IP addresses, based on a result of the inspection.

26. A data communication system comprising: a first network node configured to constructing mobility state information for a connection, wherein the mobility state information includes binding of a fixed connection- tuple and a mobile connection-tuple, wherein the connection-tuple includes an IP address, a source port number, a destination IP address and a destination port number; and a second network node connected to the first network node through the connection, and adapted to receive the mobility state information from the first network node, wherein the second network node includes: a storage unit configured to store a connection state table containing the mobility state information.

27. The system of Claim 26, wherein the first network node includes a fixed micronode and a mobile micronode, wherein the fixed connection-tuple is used to communicate a packet between the fixed micronode and the mobile micronode, and the mobile connection- tuple is used to communicate the packet between the mobile micronode and the second network node,

^■wherein the second network node includes: a module adapted to look up the connection state table for the fixed connection-tuple corresponding to the mobile connection-tuple in response to receipt of the packet.

28. The system of Claim 27, wherein the fixed micronode includes a unit adapted to assign the fixed connection-tuple for a packet to be sent to the second network node, and the mobile micronode includes a unit adapted to replace the fixed connection-tuple with the mobile connection-tuple.

29. The system of Claim 28, wherein the first network node further includes a plurality of network interfaces adapted to interface with a plurality of networks, and wherein the mobile micronode further includes a unit adapted to select a network interface over which the packet is to be sent.

30. The system of Claim 28, wherein the second network node includes: a unit adapted to extract the mobile connection-tuple from the packet received from the mobile micronode of the first network node; a unit adapted to retrieve the fixed connection-tuple corresponding to the extracted mobile connection-tuple from the connection state table; and a unit adapted to replace the mobile connection-tuple in the packet with the retrieved fixed connection- tuple.

31. The system of Claim 27, wherein the mobile micronode includes: a unit adapted to extract the mobile connection-tuple from a packet received from the second network node; a unit adapted to retrieve the fixed connection-tuple corresponding to the extracted mobile connection-tuple from the connection state table; and a unit adapted to translate the mobile connection-tuple in the packet to the fixed connection-tuple.

32. The system of Claim 26, wherein the first network node signals the mobility state information to the second network node when a connection starts or finishes between the first network node and the second network node.

33. The system of Claim 26, wherein the first network node communicates data with the second network node over a plurality of networks, wherein the first network node further includes a set of network interfaces adapted to interface with the plurality of networks, and wherein the first network node signals the mobility state information to the second network node "when the set of network interfaces changes.

34. The system of Claim 26, wherein the mobility state information is delivered (a) in a separate packet sent over a separate connection, (b) in a separate packet as a dummy data packet in the connection, or (c) piggybacked onto a data packet in the connection.

35. The system of Claim 26, wherein the system further comprises: a NAT (network address translation) router between the first network node and the second network node, the NAT router adapted to replace the mobile connection-tuple in the packet with a third connection-tuple including a NAT adport, wherein the second network node includes: a unit adapted to retrieve the NAT adport from a packet received from the first network node; and a unit adapted to inform the first network node of the NAT adport.

36. The system of Claim 35, wherein the first network node includes a unit adapted to send a dummy packet to the second network node so that the second network node may retrieve the NAT adport.

37. The system of Claim 35, wherein, after the NAT adport is informed to the first network node, the first network node inserts the informed NAT adport in a packet to be sent to the second network node.

38. The system of Claim 36, wherein the first network node includes a unit adapted to replace a source adport field in the packet with the informed NAT adport.

39. The system of Claim 36, wherein the first network node includes a unit adapted to add the NAT adport alongside a source adport field in the packet.

40. The system of Claim 35, wherein the first network node includes: a storing unit configured to buffer a copy of an outgoing SIP signaling message; a unit adapted to insert the NAT adport to the buffered SIP signaling message after the NAT adport is informed; and a unit adapted to resent the SIP signaling message after the NAT adport is inserted.

41. A method for transferring data from a network node over at least one network, the method comprising: constructing a packet at the network node, the packet including a portion of the data and a fixed connection- tuple, wherein the connection- tuple includes an IP address, a source port number, a destination IP address and a destination port number; extracting the fixed connection-tuple from the packet at the network node; retrieving at least one mobile connection-tuple corresponding to the fixed connection-tuple at the network node, wherein the mobile connection-tuple is used to route the packet in said at least one network; inserting the respective mobile connection-tuple into the packet.

42.. The method of Claim 41, further comprising: selecting a subset of said at least one network; and transferring the packet with the mobile connection-tuple over the selected subset of said at least one network, wherein said at least one mobile connection-tuple is retrieved further based on the selected subset of said at least one network.

43. The method of Claim 42, wherein the operation of selecting includes: evaluating state of said at least one network based on at least one of bottleneck available bandwidth, packet delay, packet loss, error rate and signal strength; and selecting the subset of said at least one network based on the evaluated state.

44- The method of Claim 41, further comprising: detecting an adport newly assigned to the network node; generating a connection tuple based on the detected adport; and storing the generated connection tuple as the mobile connection-tuple, wherein the fixed connection-tuple remains unchanged as long as there is a running connection on the network node.

45. The method of Claim 44, wherein the operation of detecting includes: selecting an address among a pool of IP addresses reserved by an access point connected to the network node.

46. The method of Claim 41, further comprising: exchanging mobility state information with a corresponding terminal, wherein the mobility state information includes the fixed connection-tuple and the mobile connection- tuple.

47. The method of Claim 46, wherein the mobility state information further includes an MTID, the MTID being a unique identifier of the network node.

48. The method of Claim 46, wherein the operation of exchanging is performed when a connection starts or finishes, or when the set of said at least one network changes.

49. The method of Claim 41, further comprising: receiving a signal informing an NAT adport of the network node; and inserting the NAT adport in the packet.

50. The method of Claim 49, further comprising: buffering a copy of the packet until the NAT adport is informed; and resending the copy of the packet after the NAT adport is inserted.

51. The method of Claim 41, further comprising: detecting an MAC address of a new access point when a connection is established between the network node and the new access point; determining whether a destination node of the packet is connected to the new access point; if it is determined that the destination node of the packet is connected to the new access point, sending a MAC frame carrying the packet to die destination node; and if it is determined that the destination node of the packet is not connected to the new access point, setting a destination MAC address of the packet to the MAC address of the new access point.

52. The method of Claim 41, wherein the packet collectively forms a packet flow, and wherein the method further comprises: splitting the packet flow into one or more substreams; and transferring the substreams separately over said at least one network.

53. The method of Claim 41, wherein the data is streaming data and the packets collectively form a packet flow, and wherein the method further comprises: measuring bottleneck available bandwidth of said at least one network; distinguishing streaming frame type carried in each packet; dividing the packet flow into a plurality of substreams each of which contains packets of one frame type; determining if a data rate of the packet flow exceeds the measured bottleneck available bandwidth; and if it is determined that the data iate of the packet flow exceeds the measured bottleneck available bandwidth, dropping substreams of low importance.

54. The method of Claim 41, -wherein the network node includes a fixed micronode and a mobile micronode, wherein the operation of constructing is carried out in the fixed micronode, and the operations of extracting, retrieving and inserting are carried out in the mobile micronode.

55. The method of Claim 54, further comprising: the mobile micronode sending a TCP ACK packet to the fixed micronode; the mobile micronode buffering the packet; the mobile micronode sending the packet to a corresponding terminal; the mobile micronode receiving an acknowledgement for the packet from the corresponding terminal; the mobile micronode removing the buffered packet in response to the receipt of the acknowledgement; and the mobile micronode resending the buffered packet when the acknowledgement is not received for a predetermined duration.

56. A method for receiving data from a remote network node, the method comprising: receiving a packet on a network node, the packet including a mobile connection-tuple, wherein the mobile connection-tuple includes a mobile adport that changes during mobility; extracting the mobile connection-tuple from the packet at the network node; retrieving a fixed connection-tuple corresponding to the mobile connection-tuple at the network node, wherein the fixed connection-tuple corresponds to a connection-tuple carried inside connection-established packets; replacing the mobile connection-tuple in the packet with the fixed connection-tuple; and delivering the packet with the fixed connection-tuple to a TCP/IP or UDP/IP protocol stack.

57. The method of Claim 56, further comprising: receiving mobility state information, wherein the mobility state information includes mapping information of the fixed connection-tuple and the mobile connection-tuple; and storing the mobility state information in a storage unit, wherein the operation of retrieving includes: looking up the fixed connection-tuple mapped to the mobile connection-tuple from the storage unit.

58. A computer-readable medium storing computer-executable instructions for performing the method as recited in any one of Claims 41 to 57.