Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
  • H04L12/2854—Wide area networks, e.g. public data networks
  • H04L12/2856—Access arrangements, e.g. Internet access
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/09—Mapping addresses
  • H04L61/25—Mapping addresses of the same type
  • H04L61/2503—Translation of Internet protocol [IP] addresses
  • H04L61/256—NAT traversal
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/50—Address allocation
  • H04L61/5084—Providing for device mobility
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/14—Reselecting a network or an air interface
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/26—Network addressing or numbering for mobility support
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/0005—Control or signalling for completing the hand-off
  • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
  • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
  • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
  • H04W80/08—Upper layer protocols
  • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]

Definitions

• 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.
• 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.
• 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.
• MT mobile terminal
• a major theme in data and multimedia communication today is that of 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.
• 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.
• MIP Mobile Internet Protocol
• SIP Session Initiation Protocol
• 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.
• 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.
• NAT network address translation
• the second background of the present disclosure relates to the wireless aware quality of service (QoS) improvements using the end-to-end approach.
• QoS quality of service
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a mobile micronode is transparent to the applications and TCP/UDP stack running on the terminals.
• Figure 1 depicts a communication system in accordance with one embodiment.
• Figure 2 outlines a structure of an MT in accordance -with one embodiment.
• Figure 3 shows an example structure of a packet communicated between a fixed micronode and a mobile micronode, in accordance with one embodiment.
• Figure 4 shows some applicable structures of a packet communicated between a mobile micronode and a network interface, in accordance with one embodiment.
• Figure 5 is a flowchart showing operations that may be performed by an m- node for an outgoing packet, in accordance with one embodiment.
• Figure 6 is a flowchart showing operations that may be performed by an m- node for an incoming packet, in accordance with one embodiment.
• Figure 7 depicts a method for m-adport correction in accordance with one embodiment.
• Figure 8 shows internal and external segments of a TCP connection between an MT and a remote host, in accordance with one embodiment.
• Figure 9 depicts a method for TCP data path processing at an m-node, in accordance with one embodiment.
• Figure 10 depicts a method of frame dropping at an m-node for video quality improvement, in accordance with one embodiment.
• CT Corresponding Terminal
• 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.
• 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.
• TAB adportl, adport2
• TAB and TBA are opposite tuples, they refer to the same connection.
• 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.
• Connection-tuple of a packet 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>.
• Original tuple (or f-tuple) of a connection 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.
• IP packets i.e., initial connection-establishing packets that are exchanged by two hosts in order to establish their respective states for that connection.
• 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.
• 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).
• 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.
• the micro-network architecture solves die identity ambiguity problem; and thereby providing the foundation for the present disclosure.
• 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.
• E-MTM end-to-end mobile-to-mobile
• 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.
• FIG. 1 depicts a communication system in accordance with one embodiment.
• 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.
• IP Internet Protocol
• 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.
• 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.
• LANs local area networks
• 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.
• IP Internet Protocol
• 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.
• 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.
• 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.
• 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.
• 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.
• the mobile micronode 204 can be implemented as an NDIS driver.
• an MTID a byte sequence carried in packets from an MT 102, is provided to uniquely identify it to any node corresponding with it.
• 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.
• 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.
• 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.
• N may be fixed a priori and known to the MT 102.
• the f-adport at the MT 102 for a connection can be chosen as the temporary MTID for the duration of that connection.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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).
• the source f-adport and the destination f-adport may constitute an f-tuple 308.
• 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.
• 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.
• 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).
• 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)>.
• 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.
• 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.
• 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.
• 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:
• 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.
• the packet 402 may include the mobility state information.
• 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:
• 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)).
• 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)).
• 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.
• MTU Maximum Transmission Unit
• 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.
• the signaling information may be piggybacked using IP-in-IP tunneling (see e.g., Figure 4(b)):
• IP-in-IP tunneling see e.g., Figure 4(b):
• 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.
• 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)).
• 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.
• 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).
• TMC(S,I) 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).
• 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.
• 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).
• 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 M C(S,I)) (S510).
• TMC(S) connection tuple
• T M C(S,I) connection tuple
• S510 connection tuple
• ⁇ 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.
• 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.
• 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 J I 1 ) 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.
• the TCP connection termination may apply only when the connection is a TCP connection.
• 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.
• 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
• 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.
• 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 1 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.
• the MT may start inserting its own n-adport value in a source n- adport field in each packet it sends to the CT.
• the source n-adport field replaces the source f-adport field in the packet.
• the source n- adport field is an extra field added alongside the source f-adport field in the packet.
• 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.
• E-MTM architecture automatically solves this blockade problem using the mobility signaling embodiment previously discussed (see Figure 4(e)).
• 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.
• Both may be implemented in networks that have an Ethernet-like MAC addressing scheme (e.g. WiFi 3 WiBro, and WiMax networks).
• both may be implemented in the m-node of the MT.
• 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.
• 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 2 where N is the pool size. This method may be supported by the full collision resolution method described next.
• ASMA Address-Sense-Multiple-Access
• 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.
• 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.
• the MT will similarly signal the release of the reserved IP address to other MTs.
• 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.
• Multi-Access-Network Packet Forwarding (MAPF)
• 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.
• 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.
• 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.
• 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.
• 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).
• E-MTM's Transparent One-Sided TCP Trans-TCP
• Trans-TCP Transparent One-Sided TCP
• 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.
• the following tasks may be carried out by the MT's m-node 808:
• 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)).
• BAB Bottleneck Available Bandwidth
• D Packet Delays
• L Packet Loss
• E Error Rate
• S Signal Strength
• 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.
• 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.
• T and N can be tunable parameters or could change dynamically with time.
• 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.
• 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.
• the m-node 808 may send back a Proxy TCP ACK packet to the f-node 806 (S906).
• 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.
• MSS Max-Segment-Size
• 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.
• 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).
• 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.
• the m-node estimates the first L' of the unacked packets as lost. [0128] • Here L and L 1 are determined in general as a function of the number DA of
• TR Transmit Rate 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.
• the m-node Upon receiving an incoming packet of the TCP connection, the m-node queues it in the T-receive buffer.
• 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.
• 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.
• 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.
• 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.
• the frame dropping for wireless video improvement performs the following tasks:
• 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.
• E-MTM 1 S Circuit-Packet (C-P) Handoff
• 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.
• 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.
• 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.
• 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.
• 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.
• the C-P handoff may consist of two components:
• 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).
• 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.
• the monitored estimates and the location tracking of the MT 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.
• 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. .
• 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.
• the CT's m-node immediately starts delivering the advance bits to the f-node. At this point, the handoff is complete.
• 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.
• a transducer for producing each type of real-time content for the call, such as a microphone for voice or camera for video conferencing
• different encoders may be used for calls over the circuit and packet
• 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.
• 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.
• 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.
• 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.
• 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.
• the m-node may decide to reroute the payload of an IP packet as a c-packet over a circuit-switched link.
• 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.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Databases & Information Systems (AREA)
• Mobile Radio Communication Systems (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (6)

Publications (1)

Family

ID=38256866

Family Applications (1)

Country Status (4)

Family Cites Families (6)

• 2007
  • 2007-01-04 WO PCT/US2007/000044 patent/WO2007081689A2/en active Application Filing
  • 2007-01-04 JP JP2008549535A patent/JP2009523334A/ja active Pending
  • 2007-01-04 EP EP07716219A patent/EP1974050A2/de not_active Withdrawn
  • 2007-07-19 KR KR1020087018982A patent/KR20080102367A/ko not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events