HK1138981B - A method and system for a low-overhead mobility management protocol in the internet protocol layer - Google Patents

Description

Method and system for low overhead mobility management protocol in internet protocol layer

The patent application of the invention is a divisional application of an invention patent application with the international application number of PCT/USO2/04372, the international application date of 2002, 2 month and 14 day, the application number of 02805273.0 entering the China national stage and the invented name of a method and a system for a low overhead mobility management protocol in an internet protocol layer.

Technical Field

The present invention relates to a system and method for mobile internet communication capable of high data transmission rate, which also supports multiple communication flows (traffic flows) including both real-time and non-real-time services. Specifically, the present invention relates to a method for managing mobility of a Mobile Node (MN) in multiple administrator domains. In one embodiment, the multiple administrator domains use Network Address Translation (Network Address enabled routers, NATs) for internet communications.

Background

In a mobile network, each Mobile Node (MN) communicates with a single Access Point (AP) and receives communications via an Access Router (AR) associated with the AP. This represents a single point of attachment between the MN and the internet. Conventionally, mobility management plans employ a two-phase hierarchical scheme for mobile Internet Protocols (IPs). In the case where an MN has moved from its home AP, the home AR receives communications in the form of a data packet (datagram) from a source Node, commonly referred to as a Correspondent Node (CN), and repackages the communications by adding a new header to a received datagram to redirect and "tunnel" the CN communications to the MN's current IP address. This new/repackaged data envelope encapsulates the in-place CN data envelope within its data portion, which is commonly referred to as dual internet protocol (IP-in-IP) encapsulation.

Network address translation capable routers (NATs) may be used to connect private networks to the internet. As shown in fig. 7, conventional internet communications are performed by establishing 48-bit links (bindings) between NATs that identify nodes with which they are in contact. The Address space is divided into a set of registered 24-bit global addresses and a set of unregistered 24-bit local addresses formulated by the Internet Address Number Authority (IANA). The private network has to use any address with this unregistered address space. Public or global addresses are registered and each NAT obtains a designation of an address in this cluster.

The inventors have identified a need to modify conventional network address translation functions to handle situations that allow Mobile Nodes (MNs) to migrate within their own private networks and situations that allow MNs to migrate from one private network to another.

Disclosure of Invention

The present invention is directed to a novel system and method that combines mobility management with optimal routing for a mobile air interface.

The invention provides a network system for supporting mobile internet communication, which comprises a plurality of Routers (Routers) and a plurality of Mobile Nodes (MNs). Each router has a unique communication address. Each MN can move to a number of different locations to communicate with the internet via different routers at different locations. Each MN is associated with a home router.

Each router has an associated Mobile Node Location List (Mobile Node Location List) identifying each MN for which the router is the home router and a communication address of the router corresponding to a current Location of each of the MNs. Each MN is movable from an old location where the MN is in contact with the internet via a router to a current location where the MN is in contact with the internet via a different router. Communication via the different router at the current location is performed by contacting the home router of the MN with the communication address of the different router as the communication address corresponding to the current location of the MN. Thus, a data communication from a Correspondent Node (CN) to a selected MN is communicated to the selected MN by accessing the mobile node location list of the selected MN's home router to determine a communication address corresponding to the current location of the selected MN and directing the data communication to the determined communication address.

In one embodiment, the network includes a plurality of Access Routers (ARs) as Routers. Each AR has a unique Internet Protocol (IP) address and a geographic access range for ARs to MNs contact data. Each MN is associated with a home AR and each AR has an associated Node Location Table (NLT) as its mobile Node Location list. The NLT identifies each MN with the AR in place and the IP address of a current location of each of these MNs.

Each MN may move to a position outside the access range of its home AR to within the access range of any selected one of the other ARs to receive data via the selected AR. To this end, the MN informs its home AR of the IP address of the selected AR as its current location. Thus, a data communication from another node, generally referred to as a Correspondent Node (CN), to a selected MN is communicated to the selected MN by issuing a query for the IP address of the selected MN's home AR, receiving the IP address of the selected MN's current location from the NLT of the selected MN's home AR, and directing the data communication to the received IP address.

Preferably, the network system includes a plurality of Access Points (APs). Each AR accompanies at least one AP to allow MNs to communicate with ARs via the APs. Each AP has an access range within which to communicate data to MNs. The access scope of APs associated with a given AR is collectively defined as the access scope of the AR.

Preferably, the Network system also includes a plurality of Access Network Gateways (ANGs). Each ANG accompanies at least one AR and each ANG connects with the internet.

The present invention provides a novel method for communicating between a Correspondent Node (CN) and a Mobile Node (MN) within the Internet using standard format data encapsulation. Generally, the internet data packet standard format is a data packet having a header portion and a data portion, wherein the header portion includes a source Internet Protocol (IP) address, a destination IP address, and a protocol type. In the method of the present invention, the CN contacts the internet via an AR having a first IP address, the MN is associated with a home AR having a second IP address and the MN contacts the internet via an AR having a third IP address. In the case where the MN communicates via its home AR, the second and third addresses are the same.

The CN sends a first data packet to confirm that the first IP address is the header source IP address, the second IP address is the header destination address, an Internet Control Message Protocol (ICMP) is the header Protocol type, and a query for the location of the MN is included in the data portion of the first data packet. The home AR receives the first data packet from the CN and replies with a second data packet, wherein the second IP address is the header source IP address, the first IP address is the header destination IP address, an ICMP is the header protocol type, and a query reply containing the third IP address is included in the data portion of the second data packet. The CN receives the second data packet and sends at least one third data packet, wherein the first IP address is used as a header root IP address, the third IP address is used as a header destination IP address, a data information protocol is used as a header protocol type, and a data part of the third data packet contains an identification code of the MN and communication data for the MN. The MN receives the communication data contained in the third data packet via the AR with which it is in contact.

Preferably, the home AR maintains a Node Location Table (NLT) to identify each MN with which the AR is the home AR and the IP address of a current location of each such MN. Thus, the in-place AR references the Node Location Table (NLT) to create the data portion of the second data envelope.

The method preferably also includes sending a standard format data packet by the MN when the MN is in contact with the internet via an AR other than its home AR. The MN Data envelope includes a third IP address as a header root IP address, a second IP address as a header destination IP address, a User Data Protocol (UDP) as a header Protocol, and an identifier of the local AR and the third IP address within a Data portion of the MN Data envelope. The home AR receives the MN data envelope and updates the NLT accompanying the home AR with the data portion of the data envelope.

In another embodiment, each router is a Network address translation router (NAT). The system then preferably includes a plurality of networks, each having a different NAT with a unique global address, at least one Host (Host) accompanying the NAT, and at least one Mobile Node (MN). The Mobile Nodes (MN) communicate within the system via the hosts.

Each host is associated with a NAT and has a service area where it can contact data with the MNs. Each MN has a home host in a home network that defines a default local address that is paired with the global address of the home network's NAT to define a default connection for the MN.

The present invention provides each network's NAT with an accompanying Mobile-Home database (MHD) as its Mobile node location list, which integrates each MN with the network as its home network with either a) a local address of the MN with a current association with a host in the network or b) a link defined by an associated local address of the MN with a host in a different network and the global address of the NAT of the different network. The MHD of each network's NAT also treats as a single entity each visiting MN (i.e., an MN that is currently associated with a host associated with the NAT but has a different home network) with a local address associated with the MN's current host.

Each MN is moved from a location of the MN via first associated host contact data in a first network having a first NAT to a location of a second host service area in the first network for contact data via the second host. MN communication via the second host is facilitated by the MHB to the first NAT contacting a local address reflecting the association of the MN with the second host.

Each MN is also moved from a location where the MN contacts data via the first associated host in the first network to a location within the access range of a third host in a different second network having a second NAT to contact data via the third host. MN communication via the third host is facilitated by the MHB to the second NAT contacting a local address reflecting the association of the MN with the third host. In the case where the second network is not the MN's home network, the MN also contacts an MHB of the MN's home network NAT with a link containing a new local address reflecting the association of the MN with the third host and the global address of the second NAT.

The system enables a data communication from a Correspondent Node (CN) to a selected MN to be communicated to the MN by establishing a connection that is local to a predetermined connection of the selected MN or reflected within the MHB of the MN's home network NAT. The NAT establishing the connection directs the communication to the local address of the MN identified in its MHB.

A preferred system comprises at least one network with a plurality of hosts and at least one host that is an in-place host for a plurality of MNs. Nodes that are not mobile may also be associated with hosts within the system. The nodes may be identified by the MHD of the network of the associated host or the NAT of the network may be set to skip the MHD directing traffic to the non-mobile nodes.

Preferably, the MHD of the NAT of each network identifies a 24-bit local and global address and a location bar. Each MN with this network as its home network is treated within the MHD of the NAT as a whole with a) a local address, an empty global address, and a home flag (home flag) in the location bar that the MN is currently associated with a host within the network, or b) a link defined by a local address associated with a host within a different network and a global address of a NAT of the different network, and an away flag (away flag) in the location bar. Each visiting MN is preferably treated as a whole within the MHD of the visited network's NAT with a local address, an empty global address, and an in-place tag within the location bar associated with the MN's current host. A connection is established between a source/Correspondent Node (CN) and a MN for the connection reflected within the MHD of the MN's home network NAT when the corresponding location field has an exit flag.

The present invention can be used to implement an internet architecture consisting of a large number of private networks individually connected to the internet backbone via NATs. The hosts in the same private network can communicate with each other and with external hosts through the internet backbone. Routers within each private network maintain their own local routes and routers within the backbone maintain their own external routes. More specifically, routers within a particular network domain are not aware of routers outside the network domain. Likewise, the backbone (public) router does not recognize routers that are destined for any regional address.

Other objects and advantages of the system and method of the present invention will become more apparent to those skilled in the art from the following detailed description of the invention.

10. 12, 20: private network

40. 42, 50: network

Word list for abbreviations

The following abbreviations are used in this specification:

ANG Access Network Gateway

access network gateway

AP Access Point

Access point

AR Access Router

Access router

BER Bit-Error Rate

Bit error rate

CN Corresponding Node

Corresponding node

COA Care of Address

Forwarding addresses

DNS Domain Name Server

Domain name server

FN Foreign Network

External network

HA Home Address

In-place address

HNI Home Network Identifier

In-place network identifier

IANA Internet Address Numbers Authority

Internet address number authorization center

ICMP Internet Control Message Protocol

Internet control information protocol

IETF Internet Engineering Task Forces

Internet engineering task promotion team

IP Internet Protocol

Internet protocol

IP in IP Internet Protocol-In-Internet Protocol

Dual internet protocol

MCN Mobile Communication Network

Mobile communication network

MHD Mobile-Home Database

Mobile-in-place database

MN Mobile Node

Mobile node

NAT Network Address Translation Router

Network address translation router

NDP Neighborhood Discovery Protocol

Neighborhood discovery protocol

NLT Node Location Table

Node position table

OSPF Open Shortest Path First

Opening shortest path with priority

QoS Quality of Service

Quality of service

TCP/IP Transmission Control Protocol/Internet Protocol

Transmission control protocol/internet protocol

UDP User Datagram Protocol

User data encapsulation protocol

VA Visiting Address

Visiting address

3GPP Third Generation Partnership Project

Third generation partnership project

Drawings

Fig. 1 is a simplified diagram of the architecture and layout of a mobile network associated with the internet.

FIG. 2 is a table of node locations for an access router in accordance with the present invention.

Fig. 3 is a diagram of a conventional internet data envelope.

Fig. 4 is a diagram of an internet control information protocol (ICMP) format according to the present invention.

FIG. 5 is a diagram of a user data protocol (UPD) in accordance with the present invention.

Fig. 6 is a simplified diagram of the architecture and layout of an internet-related mobile network that can be applied to a second embodiment of the present invention.

Fig. 7 is a diagram of a conventional internet communication link.

An eighth figure depicts a portion of a mobile-home database (MHD) depicted in one of the network address translation routers (NATs) of figure 6, in accordance with the present invention.

FIG. 9 illustrates a portion of a Mobile-Home database (MHD) depicted in one of the network address translation routers (NATs) of FIG. 6, in accordance with the present invention.

Detailed Description

The present invention proposes an improvement over the current mobility management protocols, particularly the current 3GPP mobile IP. The present invention eliminates the need for IP-in-IP encapsulation from a CN to a MN while including the identity (identity) of the original CN within the IP data envelope, using OSPF to optimize routing from the transmitter to the receiver, i.e., without requiring in-place AR tunneling as in mobile IP. Although the present invention is applicable to both wireless and wireline networks, the reduction in overhead time of the present invention makes it particularly suitable for wireless air interface communications in 3GPP mobile IP networks.

Referring to fig. 1, the architecture and layout of a conventional Mobile Communication Network (MCN) is shown. The components shown in the figures are subject to the following terminology and definitions. A Mobile Node (MN) means an IP mobile terminal capable of changing its attachment point with the internet. An Access Point (AP) is an access point that provides wired or wireless air interface connections to MNs. The invention is typically only used in connection with wireless MN interfaces when applied to facilitate a handover-off of a continuous communication. The Access Router (AR) is an IP router connected to one or more APs. Each AR represents a single IP address. An Access Network Gateway (ANG) is an IP gateway that connects subnetworks to an internet backbone. Combinations of ARs connected to the same ANG belong to the same sub-network. Instead, ARs connected to different ANGs are part of different subnetworks.

Each MN is pre-assigned to a single sub-network called its "home network". Each home network is identified by an identifier called the Home Network Identifier (HNI). The MN is connected within its home network to an access point referred to as "home ap", which is then connected to a router referred to as "home ar". Each AR has a unique IP address so that the link between a MN and its home AR represents a single point of connection to the internet. Each MN within the network is assigned a fixed value called its host name, also commonly referred to as its node name. This MN host name does not change as the MN moves within the MCN. More specifically, whenever any MN connected to the AR queries an internet Domain Name Server (DNS) for a < HNI, hostname > pair for a given MN, the DNS returns the IP address of the home AR for the given MN.

It is known to send TCP/IP (transmission control protocol/internet protocol) data packets to complete a data transmission from a source node to a destination node. The packet is routed to the target AR using a target IP address of the IP header. The AR then broadcasts the data packet to all APs attached to it. The TCP "destination port number" column contains the host name of the destination MN. Each AP logs in the host name of the MNs it is currently attached to. If an AP receives a packet whose port number (hostname) matches one of its registered hostnames, the packet is transmitted to the MN via this interface. Otherwise, the packet is discarded.

Fig. 1 schematically depicts two sub-networks 10, 20, each of which is in contact with the internet via its own ANG. The first subnetwork 10 includes ARS, AR0, and AR 1. The router AR0 accompanies AP0, 0 and AP0, 1. A mobile node MN0, 0 has AP0, 0 as its home AP and AR0 as its home AR. A mobile node MN0, 1 has AP0, 1 as its home AP and AR0 as its home AR. The second access router AR1 of the subnetwork 10 is accompanied by the access point AP1, 0. Mobile nodes MN1, 0 and MN1, 1 have AP1, 0 as their home AP and AR1 as their home AR.

The second subnetwork 20 comprises an access router ARi and an accompanying access point APi, 0. The mobile nodes MNi, 0 to MNi, k have their home access points APi, 0 as their home access points and access routers ARi as their home ARs. Only mobile nodes MNi, 0, MNi, 1 and MNi, k are shown for simplicity. The mobile node MNi, k is shown communicating with the internet via the first subnetwork 10 via the access point AP1, 0 and the access router AR 1.

The mobility management protocol of the present invention is designed for Mobile nodes migrating throughout a Mobile core network (Mobile CoreVetwork). The protocol is applicable to MNs moving within a single subnetwork or across multiple subnetworks. According to the protocol of the present invention, whenever a target moves to a new AR, the root is informed of the new location of the target. If the MN moves to a new AP but still attaches to the same AR, this means that the IP address accompanying the MN has not changed. Conversely, if a MN becomes attached to a different AR, its IP address changes to indicate a new route. For example, the mobile node MNi, k is shown leaving its home subnetwork 20 and communicating with the internet via the address of router AR1 instead of the address of router ARi.

Mobile node MN0, 0 of figure 1 could potentially be relocated to contact via AP0, 1 instead of its home AP0, 0. In this case, MN0, 0 would remain in contact with the internet via its home access router AR0, so its accompanying IP address has not changed. However, if MN0, 0 accesses the internet via AP1, 0, its IP address is changed to the address of access router AR1, although MN0, 0 remains in its home subnet 10.

During normal operation, the MN may move throughout the MCN. To facilitate the ability to locate an MN at any given time, each AR maintains a directory called a "node location table" (NLT). The NLT contains a detailed list of node names (hostnames) of all MNs with this AR as the home AR, and the current location as reflected by the IP address of the AR used by the MN to contact the internet. If the MN is in its home AR, its IP address is the address of its home AR. However, if the MN has left its home AR, its IP address is unique to that of the foreign AR.

Fig. 2 depicts a node location table 30 with access routers ARi of subnets 20, having the entry contents of MNs as shown in fig. 1. The current location of the mobile node in "home" is the IP address of the ARi. Table 30 reflects that the current IP address of MNi, k is the IP address of router AR1 of sub-network 10, which coincides with the icon position of MNi, k.

Before an IP packet can be sent to a target MN, a TCP connection must be established between the AR of the source or Correspondent Node (CN) and the AR of the target MN. Before doing so, the root CN determines the current location of the target mobile node. This is accomplished by exchanging a pair of ICMP (internet control information protocol) messages between peers (peers) using standard format data packets. ICMP is a well known protocol used within the data portion of standard format internet data packets. ICMPs have a TYPE column, TYPEs 20 and 21 of which have not been used so far.

FIG. 3 illustrates a standard format data packet for Internet communications. The data packet includes a header portion and a data portion. The header section includes a root IP address field, a destination IP address field, and a protocol type field. The data portion corresponds to the protocol type indicated in the header protocol type column.

FIG. 4 depicts an ICMP format for communication within the data portion of a standard format Internet data packet. The ICMP of fig. 4 includes a type field, a code field, a checksum field, an identifier field, an order field, and an on-demand data field according to conventional ICMP formats. The ICMPs of the present invention preferably use type 20 or 21 in the type column (see details below), although previously undefined types may also be used for the purposes of the present invention.

To contact data from a CN to a MN, the CN first compiles a DNS with the node name of the target MN and retrieves the MN's home IP address according to conventional protocols. Next, the CN constructs a standard format data packet containing a header portion and an ICMP node location query message in a data portion. The CN data envelope header has the IP address of the CN's AR as the header source IP address, the IP address of the MN's home AR as the header destination address, and the '1' currently assigned to ICMPs as the header protocol type. The ICMP node location query message has the following field settings:

type-20-node location query

Node name-node name of target MN

The remaining fields are filled in a conventional manner and the completed ICMP message is placed into the data portion of the IP data packet framework of the CN. And sending the completed IP data packet to the original AR of the target MN in an encapsulating way. The home AR of the target MN, upon receipt, evaluates checksum data to confirm whether the ICMP query was correctly received from the CN. If the checksum fails to indicate a correct ICMP message, no response is made and the CN must resend its query. If the ICMP message is correctly received, the home AR of the target MN uses the ICMP identifier of the CN to program into NLT and retrieves the current IP address of the target MN. The home AR of the target MN then constructs a response data packet with an acknowledgement ICMP message and sends it back to the CN. The header of the response packet is headed by the IP address of the home AR of the target MN as the header source IP address, the IP address of the AR of the CN as the header destination address, and the '1' currently assigned to the ICMPs as the header protocol type. The ICMP node position inquiry response message has the following field settings:

type 21-node location query response

Node name of CN as identifier

Data on demand being current IP address of target MN

The code 1 or 13- '1' indicates that the MN is not currently available,

and '13' indicates that the MN is currently available.

The remaining fields are filled in a conventional manner and the completed ICMP information is placed in the data portion of the response packet frame. The MN's home AR can optionally send a message to the target MN with the IP location indicated by its NLT to determine if the MN is actively connected to the internet. If the acknowledgement of the query has not been received within a selected timeout period, the home AR of the MN responds to the CN with the code '1'. In this case, the AR may also be set to reset the current location of the target MN to the home AR within the NLT.

The completed IP data packet is sent to the CN. Upon receipt, the AR of the CN evaluates the checksum data to confirm whether the ICMP query response message was correctly received. If the checksum fails to indicate a correct ICMP message no action is taken and the CN must resend its query since it will not receive an acknowledgement. If the ICMP message is correctly received, the AR of the CN forwards the current IP address of the target MN to the CN using the ICMP identifier and information on whether the CN is available.

Once the IP address is known, a TCP connection is established and data transfer takes place between the sender CN and the receiver MN. Assuming that the MN is available, the CN constructs one or more TCP/IP data packets with data intended for the target MN and sends them directly to the MN at its current IP address. The headers of the TCP/IP data packets are headed by the IP address of the AR of the CN as the root IP address, the IP address of the current AR of the target MN as the destination address, and the '6' currently assigned to TCP/IP data as the type of header protocol.

If a target MN relocates to a new AP while still in contact with the CN, then a "handoff off" is performed. In the case of handoff, the CN is notified of the new location of the target MN so that the target MN can continue to receive data without leakage. After relocation, if the new AP of the target MN is connected to the same AR, i.e. the current IP address of the MN is unchanged, the connection can continue normally. On the other hand, if the MN moves to an AP with a different AR, the current IP address of the MN changes and the CN must be notified of the new IP address. Once notified, the CN uses the new current IP address of the target MN as the header destination address within the TCP/IP datagram.

To redirect data traffic, the MN sends a User Data Protocol (UDP) message to each CN containing the new current IP address of the target MN and the MN's home AR. In the case where an online communication is not being made with a CN, a UDP communication packet is sent only to the MN's home AR. This also occurs after MN reconnection is made by the MN relocating it to a location outside the access range of all compatible APs or simply leaving the internet altogether by turning it off. Fig. 5 depicts a format of UDP information used in accordance with the present invention.

The UDP message includes a source host name field, a destination host name field, a UDP message field, and a checksum field. In the UDP information of the MN, the node name of the MN is placed in the root host name column, and the node name of the CN or the node name of the MN's home AR is placed in the target host name column, respectively. The new MN's current IP address is placed in the UDP information field of the UDP message. The UDP information length is usually set to 12 bytes because it is 3 words long.

The UDP packet is contained within the data portion of a standard format data packet as shown in fig. 3. The data envelope header of the target MN is headed by the IP address of the AR of the CN or the IP address of the home AR of the MN, respectively, and the protocol type is denoted "17", which is the identifier currently assigned to UDP information.

The root IP address of the header of the UDP datagram of the MN is designated as either the "old" MN current IP address or the "new" MN current IP address depending on the type of handoff (handoff) being performed. A preferred method of performing handoff is "make before break" (where the MN obtains the address of the new AR it is about to contact before stopping communication via the existing ("old") AR. In such cases, the MN's packet header root IP address would be the existing ("old") IP address, and the MN's new location IP address is stored in the UDP field of the UDP information for the MN's packet. Otherwise, the UDP message is contacted after communication with the target MN via the new AR has been started, and the UDP message packet of the MN will use the address of the new AR as the root IP address of the header.

In order for a target MN to obtain the address of a new AR it will contact, the MN sends a conventional Neighbor Discovery Protocol (NDP) message. The NDP message is a standard protocol that is sent back to the router IP address associated with an AP having an access range within which the target MN has been relocated. The MN then sends a UDP message packet to inform the CN and the MN's home AR of the NDP result. The home AR updates its NLT with the new IP address received in the UDP datagram of the MN.

The home AR may optionally send an acknowledgement UDP message or other acknowledgement message to the MN to confirm the update of the NLT. It is important to handle the case where the checksum of the UDP received by the MN's home AR is erroneous. In this case, the NLT will not be updated because the home AR will not process the information in the UDP. In the absence of an acknowledgement, an acknowledgement sent by the home AR to the MN within a selected timeout period permits the MN to resend the UDP message.

In the case where a target MN moves while receiving data from a CN, the MN sends UDP information containing an NDP result to the CN. The CN then redirects the TCP/IP packets by using the IP address of the new AR as the header destination IP address within the TCP/IP packets. In the case of blocks of data transmitted during the transition, the MN contacts the CN to determine the ultimate successful receipt of TCP/IP data packets by the target MN from the CN, enabling the CN to resend any missing TCP/IP data packets to the target MN at the new IP address. Alternatively, steps may be taken to forward data packets not received by the target MN from the "old" AR to the "new" AR.

As shown in fig. 6, a second embodiment of the present invention is implemented in which private networks 10, 12, 20 are connected to an external internet backbone via network address translation capable routers (NATs). By using the system, a large number of private networks can be connected to the external Internet backbone. Hosts within different private networks can communicate with each other via the backbone using NAT registration addresses assigned by IANA. Hosts within the same private network can communicate with each other using one of the unregistered addresses. Thus, these registered addresses are globally unique, while unregistered addresses have only local validity. The local and global addresses are mutually exclusive and are conventionally 24 bits each.

For example, networks 40, 42, and 50 are connected to the Internet via NAT-capable routers NAT-A, NAT-B and NAT-N, respectively. NAT-A, NAT-B and NAT-N are each assigned a unique global address by IANA. Nodes within each private network 40, 42, 50 have the assigned area address as the host to which the node is connected. For example, node MN is shown_0，A0Via Host_A0Connected to the private network 40, and therefore at Host_A0Node MN_0，A0Is a 24-bit code that represents this connection. For convenience, in fig. 6 and 7, the global address of a NAT is identified by the NAT name, and indicates a specific node MNX and a Host_XThe area address of a connection between them is denoted as MN_XHost_X。

If a communication and/or data packet is to be sent from a node in one network to a node in another network, a conventional NAT table is established before data transfer can occur. The node that is engaged in at the beginning is conventionally referred to as the Correspondent Node (CN). For node-to-node communications, a first action is to establish a connection as NATs of the network currently connected by the nodes. Conventional procedures are found in the Internet Engineering Task Force (IETF) solicitation recommendation documents (RFCs) 1631 and 3032. Once a connection is established, an Internet Protocol (IP) data packet is sent by a Corresponding Node (CN) that traverses the global internet and reaches the NAT of the receiving node with the established connection as its own.

FIG. 7 illustrates the format of a conventional link table established between the CN and the receiving node. These links are made up of a combination of the global and local addresses of the nodes. For example, node MN as CN in network 40_0，A0Within the reachable network 50Node MN_0，B0. Just node MN_0，A0In particular, the combined global address NAT-A and local address MN are linked to data_0，A0Host_A0. Just node MN_0，B0In particular, the link data is a combined global address NAT-B and local address MN_0，B0Host_B0。

A data packet is sent from node MN_0，A0Is sent out to node MN_0，B0The procedure of (2) is as follows. A packet encoded with the global address NAT-A as a source address and the global address NAT-B as a destination address is sent from the source node MN_0，A0And (4) sending out. The terminating NAT (NAT-B in this example) checks the nexus in its table and retrieves the Host (Host in this example) of the terminating node_B0) The area address of (2). Then forwards the packet to the MN which will make the node MN_0，B0And (4) the received host. In the case where a node is not a mobile node, its association data represents a permanent address to which any CN may send data under conventional association systems and protocols. However, the mobile node MN may change location so that simply sending data to a past known address without some system accommodating the change in connection of the MN does not ensure delivery.

Eighth figure and 9 illustrate an architecture for implementing a micro mobility protocol between icon private networks. The architecture includes, with each NAT, an entity called a mobile-home database (MHD). Which is a large directory closely coupled to each NAT to keep track of MNs within the private networks. It also indicates when the MN moves to a Foreign Network (FN).

The MHD of each NAT preferably includes an index field for each mobile node, an in-place/out-of-place flag field indicating whether a mobile node is associated with the NAT, a home address or forwarding address (COA) field, and a NAT address field. Each MN HAs a home host in the home network that defines a Home Address (HA) similar to the permanent area address of a non-mobile node in that it is the address that a CN would use to access the MN. A default connection for a MN is a combination of the global address of the NAT of the MN's home network and the MN's home address. If the MN is in place, a NAT/NAT connection is established by using the preset connection to carry out CN/MN communication.

All MNs that the home host accompanies a particular NAT (i.e., the home network's NAT) have data records in the NAT's MHD. A convenient way of identifying the mobile node is to use its default or Home Address (HA), which is the index field of the MHD of the NAT of a network, preferably to specify the hass of all MNs of the network that are home to identify the data records of each MN.

The tag field presents a logical field, preferably having a value of 0 or 1, to represent either an in-place status or an out-of-place status with respect to the network. In this example, 0 indicates that the MN is connected to a host in the network, and 1 indicates that the MN is connected to a different network. The local address bar (COA) is used to indicate which host the MN is currently attached to. In the case where the local address bar entry is a host accompanying a foreign network, the global address bar contains the global address of the NAT of the foreign network. In this case, the mark column is 1. The tag column is 0 and no global address value is needed, since the relevant global address is the address of the NAT of the MHB.

Eighth and 9 depict example records of respective MHDs of NAT-B and NAT-N of networks 42 and 50 at a given point in time as shown in fig. 6.

In the case of a MN contacting its home host (e.g., as shown for the mobile node MN)_0，B0、MN_0，B1And MN_0，NKShown) whose companion flag is set to 0 and whose area or COA column has the same item content as its home address. NAT address information is not required.

For MNs that are hosts that are not home hosts but are hosts within the home network, the MHD of the MNs 'home network's NAT has a data entry labeled as 0 and the current association of the MN with its non-home host as the area address (COA). For example, the mobile node MN_1，B0There is an in-place Host HostB0, but it is shown in FIG. 6 as connected to Host_B1. The MN uses its HA (MN) in the index column_1，B0Host_B0) Identify 0 in the label bar and MN as shown in the eighth figure_1，B0Host_B1Is COA. NAT address bar information is not required because Host_B1And Host_B0The global address remains the same along with the same network with the companion global address (i.e., NAT-B).

In the case of a MN connecting from a network to a host of a different network, the MN registers with a visiting address within the NAT of the network. For example, node MN_i，NkWithin the network 50 is its home host HostNk, which communicates with the internet via NAT-N. In FIG. 6, nodes MNi, Nk are shown connected to Host accompanied by NAT-B_B1Visiting the network 42. Thus, for the mobile node MN_i，NkWithin MHD of NAT-B with MN_i，NkHost_B1A representative visiting address VA is assigned a label bar 0 and a MN which represent the contact with the Internet through NAT-B_i，NkHost_B1The address of the area.

At a mobile node (e.g., MN)_i，Nk) First, when contact with an external network (e.g., network 42) is initiated, a communication is sent to the NAT (in this case NAT-N) of its home network to facilitate efficient redirection of the communication. Communications to the NAT of the MN's home network change the data in the MHD of the NAT about the contents of the MN's list by setting the flag to 1 and providing the link data for subsequent Internet communications. The connection data consists of the assigned visiting address VA and the global address of the NA of the network visited by the MN.

With a mobile node MN_i，NkFor example, the MHD of NAT-N in FIG. 9 reflects a flag value of 1 and a region address of MN_i，NkHost_B1And one NAT address is NAT-B. An intention and mobile node MN_i，NkThe correspondent node that contacts may not be able to establish a connection with NAT-N because the flag in the MHD of NAT-N is set to 1. In this case, the connection is by the MN in MHD of NAT-N_i，NkThe link represented by the area address of the entry and the NAT address column is established. Then communicates to establish a connection with the external NAT (NA in this example)T-B).

Once the visiting MN has not established an association with a host of a different network, it preferably maintains its visiting address VA identity within the MHD of the NAT of its visited network, this VA also being reflected in the MHD of the mobile node's home network's NAT.

If the visiting mobile node establishes an association with another host in its visited network, it retains its same VA identity in the MHD of the visited NAT, but has a new area address. The new area address is stored in the COA field of the MHD record of the visiting MN, and the NAT of the visited network directs the communication to the MN by using the COA data as the address. In which case the MHD of the NAT of the MN's home network need not be changed. For example, if MN_i，NkSwitch it with Host_B1Is connected to Host_B0COA entries in the MHD of NAT-B will be from the MN_i，NkHostB1 changed into MN_i，NkHost_B0And none of the entries within the MHD of NAT-N change.

Preferably, the host periodically determines whether a connection is still established with a visiting MN. If the visited host determines that the MN has lost contact and the MN has not established a connection with another host, the visited host will communicate this fact to its companion NAT, which will change the COA entry for the visiting MN to a null data state. An example of this is the visiting node MN shown in figure 8_h，PqThe item (2). The item displays MN_h，PqHost with external Host_B1Connected, however, it is not already connected to network 42. Thus, there is no MN in FIG. 6_h，PqConnection to any host. This entry also lets a CN know that the MN has not established a connection with another host because at the MN_h，PqIn case the MHD record of the home network's NAT has not been updated, the CN will only go through the MN_h，PqVA (i.e., MN)_h，PqHost_B1) The network 42 is engaged. If a CN attempts to contact the visiting node at this time and submits to the visited network's NAT with the MN's home host's NAT, a connection cannot be established and communication will fail.

When a MN's home network NAT receives a communication to change the MN's connection information from one foreign NAT to another, it preferably sends a message to the first foreign NAT reflecting that the MN is no longer visiting the network of the NAT, so that the visiting node record is deleted from the MHD of the first foreign NAT. This information is preferably also sent when an MN returns to its home network after visiting other networks.

The CN never needs to know the current location of the MN. The CN only needs to pay attention to the static default links that are local to the Home Address (HA) of a MN and the global address of the home network. This arrangement eliminates the need for a global Internet-sent group of login information.

The tight coupling of MHDs to NATs means that an IP data packet does not have to first go to the home network. The packet can be tunneled directly to the foreign network where the MN is located. This avoids the problem of famous-wolf triangular routing.

Micro-mobility protocols for MNs roaming in multiple Foreign Networks (FNs) begin with the NAT of the CN attempting to establish a connection with the NAT of the MN's home network. This procedure fails when the status bit in the MHD of the NAT of the MN home network is 1. This represents that the MN is not currently within its Home Network (HN); which is within a FN. The FN has assigned to the MN a VA that is stored in the MHD of the NAT of the MN's home network along with the static global address of the FN. The association data is sent back to the NAT of the CN, which then establishes an association with the NAT of the FN. The remainder of the protocol is then carried out in the same manner as if the MN were attached to a host within its home network.

During a process in which a MN contacts a CN, moving from a foreign network FN1 to a different foreign network FN2, it is preferable to set the entries of the MN within the MHD of the FN1 to 0, NULL when the MN loses contact with the FN 1. When the MN later moves to the different FN2, it contacts FN2 via a Host2 accompanying NAT (NAT-FN2) of FN 2. The MN is assigned a VA of MNHost2, and the entries of the VA in the MHD of NAT-FN2 are set to 0, MNHost2, NULL. The association data (MNHost2, NAT-FN2) is sent to the NAT of the MN's home network and the NAT of the CN. A new connection is established between the CN's NAT and NAT-FN 2. The remainder of the protocol is then carried out as described previously.

During the course of a MN's contact with a CN, moving from a foreign network FN1 back to its home network HN, the entries of the MN within the MHD of the FN1 are preferably set to 0, NULL when the MN loses contact with the FN 1. When the MN later moves back to its HN, it goes through a Host of NAT (NAT-HN) accompanying its HN_HNCommunicate with its HN. Note that Host_HNWhich may or may not be the MN's home host, HostHome. The MN HAs a data record of its HA in the MHD of its HN's NAT as MNhost_Home. The record is preferably subsequently changed to set the companion data field to 0, MNHostHN, NULL. The connection data (MNHost)_HomeNAT-HN) to the NAT of the CN. A new connection is established between the NAT and NAT-HN of the CN. The remainder of the protocol is then carried out as described previously.

The NAT of the CN in the above case is typically the NAT of the CN's home network. However, if the CN is a MN visiting a FN, the NAT of the CN is that of the visited FN.

Those skilled in the art will appreciate that other variations and alternatives are within the scope of the invention.

Claims (30)

1. A method for use in wireless communications between a mobile node and a corresponding node, the method comprising:

in response to the mobile node moving to a new access router, the mobile node reporting the new access router address to the mobile node's home router as the address of the mobile node's current access router; and

sending the address of the current access router to the corresponding node;

wherein the reporting comprises sending a first message comprising a standard format data packet, the standard format data packet comprising a data portion, the data portion comprising user data packet protocol information, the user data packet protocol information comprising:

a node name of the mobile node, a node name of the home router, and a current address of the mobile node.

2. The method of claim l, wherein the address of the current access router does not match the address of a previous access router.

3. The method of claim i, wherein the address of the current access router is an internet protocol address.

4. The method of claim 1, wherein the reporting comprises sending a first message indicating an address of a current access router.

5. The method of claim 4, wherein the first message comprises an address of an in-place router.

6. The method of claim 1 wherein the user datagram protocol message includes a source host name field containing a node name of the mobile node, a target host name field containing a node name of the in-place router, a user datagram protocol message field containing a current address of the mobile node, and a checksum field.

7. The method of claim 1, wherein the standard-format data packet includes a header, the header including a header target internet protocol address, the header target internet protocol address including an address of an in-place router.

8. The method of claim 7, wherein the header contains a header source internet protocol address containing a current address of the mobile node.

9. The method of claim 1, wherein the step of transmitting the address of the current access router to the correspondent node comprises transmitting a second message indicating the address of the current access router.

10. The method of claim 9, wherein the second message contains an address of a corresponding node.

11. The method of claim 9, wherein the second message comprises a standard format data envelope.

12. The method of claim 11 wherein the standard format data packet includes a data portion including user data packet protocol information including a source host name field, a destination host name field, a user data packet protocol information field, and a checksum field.

13. The method of claim 12, wherein the source host name column contains a node name of the mobile node, the target host name column contains a node name of the corresponding node, and the user data envelope protocol information column contains a current address of the mobile node.

14. The method of claim 11, wherein the standard-format data envelope includes a header including a header target internet protocol address including an address of the corresponding node.

15. The method of claim 14, wherein the header includes a header source internet protocol address that includes a current address of the mobile node.

16. An apparatus for use in wireless communication between a mobile node and a corresponding node, the apparatus comprising:

means for reporting by said mobile node to the mobile node's home router a new access router address as the address of the mobile node's current access router in response to the mobile node moving to a new access router; and

means for sending the address of the current access router to the corresponding node;

wherein the reporting comprises sending a first message comprising a standard format data packet, the standard format data packet comprising a data portion, the data portion comprising user data packet protocol information, the user data packet protocol information comprising:

a node name of the mobile node, a node name of the home router, and the

The current address of the mobile node.

17. The apparatus of claim 16, wherein the address of the current access router does not match the address of a previous access router.

18. The apparatus of claim 16, wherein the address of the current access router is an internet protocol address.

19. The apparatus of claim 16, wherein the reporting comprises sending a first message indicating an address of a current access router.

20. The apparatus of claim 19, wherein the first message comprises an address of an in-place router.

21. The apparatus of claim 19 wherein the user datagram protocol message includes a source host name field containing a node name of the mobile node, a target host name field containing a node name of the home router, a user datagram protocol message field containing a current address of the mobile node, and a checksum field.

22. The apparatus of claim 19, wherein the standard-format data packet includes a header, the header including a header target internet protocol address, the header target internet protocol address including an address of an in-place router.

23. The apparatus of claim 22, wherein the header comprises a header source internet protocol address comprising a current address of the mobile node.

24. The apparatus of claim 19, wherein sending the address of the current access router to a corresponding node comprises sending a second message indicating the address of the current access router.

25. The apparatus of claim 24, wherein the second message comprises an address of a corresponding node.

26. The apparatus of claim 24, wherein the second message comprises a standard format data envelope.

27. The apparatus of claim 26 wherein the standard format data packet includes a data portion including user data packet protocol information including a source host name field, a destination host name field, a user data packet protocol information field, and a checksum field.

28. The apparatus of claim 27, wherein the source host name column contains a node name of the mobile node, the target host name column contains a node name of the corresponding node, and the user data envelope protocol information column contains a current address of the mobile node.

29. The apparatus of claim 26, wherein the standard-format data packet includes a header including a header target internet protocol address including an address of the corresponding node.

30. The apparatus of claim 29, wherein the header comprises a header source internet protocol address comprising a current address of the mobile node.