Data flow between a communication node and a mobile node in a mobile network

Data flow between communication node and mobile node in mobile network

Technical field

The present invention relates to a telecommunication system in which data flows between a mobile node and a data network. The mobile node is, for example, a personal digital assistant with wireless communication capabilities, and the data network is, for example, the Internet.

Background technique

The Internet is becoming more and more popular, and users increasingly want to be able to access the Internet on the move. For this purpose, different types of mobile nodes (ie, mobile communication units) can be used, such as mobile phones, personal data assistants (PDAs) with wireless communication capabilities.

Mobile users gradually access the Internet through different types of fixed or wireless access networks, such as cellular wireless communication networks such as Universal Mobile Telecommunications System (UMTS) networks, HiperLAN/2 or IEEE802.11b local area networks, Bluetooth local communication systems, or Ethernet Fixed access such as the Internet and so on. The data routing between the mobile node and the Internet further includes an Internet Protocol subnet (IP subnet), so that the routing is as follows: mobile node-access network-IP subnet-Internet (for the Internet to the mobile node Data routing is in reverse order).

At present, for example, by using a mobile IP (Mobile-IP), it is possible to seamlessly switch the Internet from one access network to another.

Traditional mobility support aims to provide continuous Internet connectivity for mobile hosts, allowing individual mobile users to connect to the Internet when they are mobile and when they move their Internet access locations. On the contrary, network mobility support is related to the situation where the entire network changes the point where it joins the Internet topology and its accessibility in the topology. Such a moving network is called a mobile network.

There are a large number of situations that exist in such mobile networks. For example, a personal area network (PAN, that is, a network in which several personal devices join a single device) is known, whereby the PAN can change the point at which it joins the Internet topology when a user is walking in a shopping mall. In addition, the network can be embedded in a bus or airplane to provide passengers with Internet access on the vehicle. Passengers can use a separate communication device (e.g. laptop) or it can become a mobile network (e.g. PAN). In particular, this configuration illustrates the situation where the mobile network accesses the mobile network (ie, nested mobility).

Similarly, a mobile network can be defined as a group of nodes consisting of one or more IP subnets joined to a mobile mobile router (MR). These IP subnets can also be regarded as a mobile unit relative to other components of the Internet, namely MR or all its joining nodes (so-called mobile network nodes or MNNs).

The document [1] IETFInternet-Draft draft-ernst-monet-terminology-00.txt written by Thierry Ernst and Hong-Yon Lach in February 2002 describes a list of definitions of mobile network terms that can be used in this application. Specifically, the following terms can be defined as follows: (i) Local Fixed Node (LFN): A node that is permanently located in the mobile network and does not change its joining point. The LFN can be a local fixed host (LFH) or a local fixed router (LFR).

(ii) Local mobile node (LMN): A local mobile node is a node that belongs to the mobile network and changes its joining point from one link of the mobile network to another link inside or outside the mobile network. At this point, it is assumed that the home link of the LMN is a link within the mobile network. The LMN can be a local mobile host (LMN) or a local mobile router (LMR).

(iii) Visiting mobile node (VMN): VMN does not belong to the mobile network and changes its joining point from outside the mobile network to inside the mobile network (that is, the origin link of the VMN is not a chain in the mobile network Road). The VMN that joins the link in the mobile network gets an address on that link. The VMN can be a mobile host (VMN) or a mobile router (VMR).

(iv) Mobile network prefix: A bit string composed of many initial bits of an IP address, which identifies a mobile network in the Internet topology. The nodes belonging to the mobile network (ie, at least MR, LFN, and LMN) share the same IPv6 "network identifier". For a single mobile IP subnet, the mobile network prefix is the "network identifier" of the subnet.

(v) MR exit: This is the interface where the mobile network joins the home link when the mobile network is home. As an alternative, it is the interface through which the mobile network joins the external link when it is in the external network.

(vi) MR entry: This is the interface on the link that joins the mobile network. The concept of egress and ingress can be extended to other types of nodes in the mobile network as follows: (a) All host (fixed or mobile) network interfaces in the mobile network are considered egresses. None of them are entrances.

(b) The fixed router (ie LFR) in the mobile network can have several exits and entrances. The type of each interface should be pre-configured on this router. The egress is usually the interface on the shortest path to a mobile router. The fixed router in the mobile network should have at least one exit.

(vii) An MR can have multiple outlets and inlets.

(viii) A mobile network can have multiple MRs.

Recently, as described in the document [2]: IETFInternet-Draft draft-ietf-mobileip-ipv6-15.txt written by David B. Johnson in July 2001, there has been a lot of attention and research on the mobile IPv6 specification. One of the main considerations regarding mobile IPv6 is that studies have proved that the IPv6 standard cannot fully address network mobility at present. In particular, the document [3] written by Thierry Ernst and Hong-Yon Lach in June 2001: IETF Internet-Draftdraft-ernst-mobileip-ipv6-02.txt details some of the problems encountered in supporting mobile IPv6 in mobile networks .

In short, it has been determined that even if the home agent (HA) of an MR can interpret the packets addressed to the MNN operating behind the MR, the HA of the MR obviously still cannot encapsulate them to the appropriate MR care-of address. Note that each data packet consists of a source address and a destination address. A tunnelled packet is a packet in which another packet is encapsulated. Therefore, the encapsulated packet has a pair of source and destination addresses. Further, the encapsulated packet has additional source and destination addresses.

The lack of knowledge of the true location of a particular MNN is due to the HA not knowing any (preferred or not) data routing to the mobile network once the mobile network has moved to a "visiting" location. Unfortunately, when an MR registers with its HA, the MR only informs the HA to record a host-specific route in its routing table. The inventors of the present invention have realized that a preferred network route generated using an appropriate MR mobile network address will greatly contribute to this problem.

In the field of the present invention, in the IEFT RFC 3220 of C. Perkins in February 2002, "IP Mobility Support for IPv4", the mobile IPv4 specification detailed in Standards Track [4] describes that in the case of IPv4 mobility How to support network mobility. However, it has also been determined that IPv4 cannot support the routing optimization of the MNN behind the MR.

Therefore, all traffic (inbound and outbound) between the MNN and its corresponding node (CN) is transmitted to the MR's home agent. The problem is exacerbated in the case of nested mobility, in which case the CN wants to transmit data to an MNN behind the MR link or a mobile node that visits a mobile network. In the case of nested mobility, the packet is encapsulated several times due to routing through all home agents of all nested MRs. This is obviously a very inefficient routing.

Similarly, in the case of IPv6, the document written by TJKniveton in November 2001 [5]: IETF Internet-Draft draft-kniveton-mobrtr-00.txt, which describes the situation without modifying the mobile IP (v4 or v6) How to support the mobile network. The proposed mechanism for solving nested mobility support is described with reference to FIG. 2. It has the same problem, which is the multiple tunnelling of the home agent of the nested mobile router as described in the previous paragraph. When an MR, such as MR2 260, has joined an access network 110 (via another mobile network MR1 link), a two-way tunnel 210, 215, 220 is established between MR2 260 and its HA-HA 250. When a node such as LFN2 165 joins MR2 260 and wants to send an IP packet to CN via Internet 115, that is, CN2 255, that packet is tunneled by MR2 260 (to HA2 250) and then by MR1 150 (to HA1 240) Tunneling. The data packets that have been tunneled multiple times are then transmitted to the HA of the last MR, that is, HA1 240, so as to tunnel the data. The HA1 240 then forwards it to the intended recipient CN2255 via the HA of the source MR, that is, the HA2 250.

The proposed data routing method and its related problems are best described by examples. Therefore, let us assume that LFN2 165 sends a data packet to CN2 255. The data packet is first routed 205 to MR2 255. The data packet is then tunneled by MR2 260 to HA2250. The data packet tunneling process from MR2 260 to HA 250 first routes 210 to the MR connected to it, namely MR1 150, as needed. MR1 150 further tunnels the data and forwards the multiple tunneled packets to its HA, HA1240. The HA1 240 tunnel de-tunnels the data packet transmitted by the MR1 150 tunnel and forwards 220 the partially de-tunneled packet to its original intended recipient HA2250. The HA2 250 further tunnels the packet transmitted by the MR2 260 tunnel and further forwards all the data packets unpacked in the tunnel to the CN2 255.

Obviously, the proposed solution cannot provide any support for routing optimization, because both inbound and outbound packets are routed through the MR150, 260's home agent. In fact, packets from CN2 255 to LFN2 165 will follow the same path (in reverse order) and then be encapsulated by each home agent 240, 250 of each nested MR 150, 260. This is obviously also a very inefficient routing, especially for the actual situation where there are more than two levels in a nested network.

In June 2001, Thierry Ernst and Hong-Yon Lach wrote a document: IETFInternet-Draft draft-ernst-mobileip-v6-network-02.txt gave a solution, proposed a method for mobile The way to support network mobility in the IPv6 framework. The solution introduces the following concept: When a mobile router roams to the visited network, it sends a prefix scope binding update to its home agent (HA). Unlike the typical mobile IPv6 binding update message, the prefix range binding update does not bind the home address and the care-of address together.

On the contrary, for a specific MR, the MR prefix is bound to the MR care-of address. Upon receiving a packet with a prefix matching the prefix of the MR, the home agent must tunnel the packet to the care-of address of the MR, which has been identified as being able to transmit the tunneled packet to the intended recipient. Similarly, the MR can send a prefix-scope (prefix-scope) BU to the corresponding node of the node it serves. This solution introduces a more effective mobile network support into Mobile IPv6 because it can provide limited improvements to routing optimization.

However, the scope of the draft clearly excludes the case of nested mobility, which poses great obstacles to the optimization of effective routing. Similarly, the solution proposed in the document IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt of Thierry Ernst in June 2001 cannot provide a useful solution for routing optimization in many practical applications. . In the case of examples, some problems in the document are more highlighted, especially in the case of nested mobility.

Referring now to Figure 3, a description of a method of routing data packets in an IPv6 network using the IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt suggested by Thierry Ernst and Hong-Yon Lach in June 2001 mechanism. In particular, some problems stemming from the use of this mechanism in nested mobility are highlighted.

The mobile router MR1 150 joins the access link 110. The mobile router MR2 260 joins the link 155 of MR1. The local fixed node LFN2 165 joins the link 210 of MR2. Here, let us assume that LFN2 165 attempts to communicate with the corresponding node CN2 255.

Let us further assume that at the beginning of the simple scenario detailed in Figure 3, MR1150 and MR2 260 have sent BU messages to their respective HA 240, 250. That is, HA1 240 knows that the prefix of MR1 150 can be obtained at the care-of address of MR1. Similarly, HA2 250 knows that the prefix of MR2 260 can be obtained at the care-of address of MR2.

When a data packet sends the LFN2 165 from CN2 255, CN2 255 has no knowledge about the actual location of LFN2 165. Thus, the data packet it sent is therefore routed 325 to the home link-2 105. HA2 250 interprets the data packet and tunnels it to the care-of address of MR2. This is understandable because the HA2 250 knows that the MR2 prefix can be obtained at the care-of address of MR2.

The tunnel packet (from HA2 250 to the care-of address of MR2 260) is routed 320 to link-1 245 because the care-of address of MR2 260 matches the prefix of MR1 150. HA1 240 interprets the data packet and tunnels it to the care-of address of MR1, that is, towards the access link 110, because HA1 240 knows that the care-of address of MR1 can obtain the prefix of MR1.

MR1 150 then tunnels the data packets received from HA1 240. MR1 150 then forwards the content to the original recipient MR2 260. At the same time, MR1 150 sends a binding update to the sender of the encapsulated packet (it is HA2 250) to inform it that the prefix of MR1 can be obtained at the care-of address of MR1. Note that from the point of view of MR1, HA2250 is a corresponding node but not its home agent (ie, no'H' is set in the BU). Until the HA2 250 receives or does not receive the binding update.

MR2 260 tunnels the data packet it receives (ie the part of the data packet encapsulated by HA2 250) and forwards the content (original packet from CN2255) to LFN2 165. At the same time, MR2 260 sends a binding update message to the sender of the encapsulated packet (ie, CN2255) to inform it that the prefix of MR2 (covering the address of LFN2 165) can be obtained at the care-of address of MR2. The message is stored in the CN-bound cache 370.

Once an initial packet reaches its destination, the second or subsequent packet transmission from CN2 255 to LFN2 165 will appear as shown in Figure 4. After checking its binding cache 370, CN2 255 recognizes that LFN2 165 is available at the care-of address of MR.

Therefore, it sends the data packet to MR2's care-of address, which has a routing header for LFN2 165. The care-of address of MR2 belongs to the link of MR1, so it is routed to the home link-1 245. In this way, a slight improvement in routing optimization can be obtained by bypassing the transmission of data packets to and from the HA2 250.

HA1 240 then interprets the data packet and tunnels the packet to the care-of address of MR1, because HA1 240 knows that the prefix of MR1 can be obtained at the care-of address of MR1.

MR1 150 tunnels the packet from HA1 240 and forwards the content to the mobile router MR2 260 of the original intended recipient LFN2 165. At the same time, MR1 150 sends a binding update to the sender of the encapsulated packet (ie, CN2 255) to inform it that the prefix of MR1 can be obtained at the care-of address of MR1.

When receiving the original packet sent by CN2 255, MR2 260 replaces its address in the destination field of the packet with the address contained in the routing header (ie, LFN2 165), and forwards the data packet to the final recipient.

The inventors of the present invention have recognized a significant problem in the situation described in FIG. 4. All subsequent packets from CN2 255 to LFN2 165 will be routed in exactly the same way as the second data packet. That is, there is no continuous improvement for routing optimization. This is even more obvious with regard to Figure 5.

Referring now to FIG. 5, a known bonded cache 500 is illustrated. The binding cache includes a list of entries dedicated to each MR in the nested mobility scenario. The binding cache entry includes, for example, an MR3 prefix and prefix length 530, which has a link 532 to the determined MR3 care-of address 534 (if a care-of address has been determined). The MR3 entry 535 is linked 536 to the next entry in the bound cache, that is, the entry for MR2. The MR2 prefix, the prefix length 520, includes a link 522 to the determined MR2 care-of address 524 (if a care-of address has been determined). Perform similar configuration and link 526 for MR1, and so on.

In addition, the binding cache entry includes a tag entry (not shown). The'P' mark is a "prefix scope registration" mark. When it is set, a "home address" field is filled with the mobile network prefix (the prefix advertised by the mobile router) and the "prefix length" corresponds to the length of the mobile network prefix.

In June 2001, the document IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt of Thierry Ernst stipulated that the binding super-high-speed buffer should be searched once, and the one corresponding to the destination address of the packet should be searched. entry. As a result of the search, nothing is found (no entry), or the complete address has been found (128 bits match for an IPv6 address, and the P flag is not set) or for the registered prefix length, the first part of the destination address is the same as The registered prefix matches. In the latter case, the destination is located in a mobile network.

Therefore, referring to FIG. 4, when CN2 255 must send a packet to LFN2 165, CN2 255 still checks its binding cache and looks for an entry of'MR2 260 prefix available at MR2260Co@520, 524'. CN2 255 does not even consider the'MR1 150 prefix available at MR1 150Co@'510,514' entry, because this does not seem to be carried in the LFN2 address. The inventor has realized that this deficiency is due to the fact that the address of LFN2 165 has nothing to do with the MR1 prefix. CN2 255 neither sees nor even uses the fact that MR2 260Co@ belongs to the MR1 prefix.

Therefore, Thierry Ernst suggests that the only optimization that can be supported is related to the HA (HA2250) of the MR (MR2 260) of the service communication MNN (LFN2 165 in the example above). The solution actually describes a method for sending packets directly from CN2 255 to HA1 240, rather than from CN2 255 to HA2 250 and then to HA1240. However, if there are n consecutive levels of nested mobility, then the solution provides minimal routing optimization, only CN2 255 HAn-1HAn-2...HA1 path instead of CN2 255 HAnHAn-1HAn-2 ...HA1 path. This suggestion is therefore obviously still insufficient, especially in the case of nested networks.

Therefore, there is a need for a mechanism, equipment, and related method to support routing optimization in network mobility, especially in the case of IPv6. Specifically, it is necessary to support routing optimization in the case of nested mobility, which can greatly alleviate the aforementioned problems.

Summary of the invention

According to an aspect of the present invention, as described in claim 1, a method for sending data packets from a first communication node to a second communication node in a mobile communication network is provided.

According to the second aspect of the present invention, as claimed in claim 13, a communication message is provided.

According to a third aspect of the present invention, as described in claim 14, a communication message is provided.

According to the fourth aspect of the present invention, as described in claim 16, a communication message is provided.

According to the fifth aspect of the present invention, as claimed in claim 17, a communication node is provided.

According to the sixth aspect of the present invention, as claimed in claim 18, a communication node is provided.

According to a seventh aspect of the present invention, as claimed in claim 19, a storage medium is provided.

According to an eighth aspect of the present invention, as described in claim 20, a method for establishing an extended bound cache is provided.

According to a ninth aspect of the present invention, as described in claim 21, there is provided a method for constructing and sending a care-of-route announcement message at a mobile network node.

According to a tenth aspect of the present invention, as described in claim 22, a method for constructing and sending a mobile network prefix advertisement message in a mobile router is provided.

According to an eleventh aspect of the present invention, as recited in claim 23, a storage medium is provided.

According to a twelfth aspect of the present invention, as claimed in claim 24, an apparatus is provided.

According to a thirteenth aspect of the present invention, as claimed in claim 25, a communication unit is provided.

According to a fourteenth aspect of the present invention, as claimed in claim 26, a communication system is provided.

Other aspects of the invention are described in the dependent claims.

Description of the drawings

Figure 1 illustrates the movement of mobile networks in the Internet; Figure 2 illustrates a known packet data routing mechanism for mobile networks when applied to nested mobility; Figure 3 illustrates when applied to nested mobility A known packet data routing mechanism used in mobile networks highlights the inefficiency of data routing;

Figure 4 illustrates a known packet data routing mechanism used in mobile networks when applied to nested mobility, highlighting that the improved processing efficiency of data routing is very low; Figure 5 illustrates a routing in a mobile node network A known binding cache of data packets.

Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which: Figure 6 illustrates a network topology for advertising the mobility of a mobile router in a mobile network according to a preferred embodiment of the present invention; Figures 7, 8 and Fig. 9 illustrates a flow chart of the construction of an MNN router and sending forward route advertisements according to a preferred embodiment of the present invention; Fig. 10 illustrates a network topology for sending an extended BU to a CN according to a preferred embodiment of the present invention; Figure 11 illustrates a flow chart of MNN generating a hand-off route according to an embodiment of the present invention; Figures 12 and 13 illustrate a flow chart of MNN sending an extended BU message to its CN according to a preferred embodiment of the present invention; Figure 14 And Figure 15 illustrates a flow chart of the MNN sending an extended BU message to its CN according to a preferred embodiment of the present invention; Figure 16 illustrates a mobile network prefix of the MNN in a mobile network according to a preferred embodiment of the present invention Dynamic discovery method; Fig. 17, Fig. 18 and Fig. 19 illustrate the processing flow of the MNN router sending the mobile network prefix advertisement message according to the preferred embodiment of the present invention; Fig. 20 illustrates the first node sending a message according to the preferred embodiment of the present invention The flow of data packet to the second node; Figure 21 illustrates an example of the data packet format sent by the first node to the second node according to the preferred embodiment of the present invention; Figure 22 and Figure 23 respectively illustrate the data packet format according to the preferred embodiment of the present invention Mobile network prefix request message and mobile network prefix announcement message; Figure 24 and Figure 25 respectively illustrate the forwarding route request message and forwarding route announcement message according to the preferred embodiment of the present invention; Figure 26 and Figure 27 illustrate the preferred embodiment of the present invention , The extended BU message sent from LFN and VMN; Figure 28 illustrates an extended binding cache according to the preferred embodiment of the present invention; Figure 29 illustrates the process from a received extended BU according to the preferred embodiment of the present invention The construction of the forwarding source route; and FIG. 30 illustrates the process of receiving an extended BU from a second node by a first node according to a preferred embodiment of the present invention.

detailed description

There is currently no standard mechanism to fully support network mobility, especially in the case of IP6 for nested mobility data networks. In particular, it cannot provide and support routing optimization.

This is a major problem, because nested mobility is a very realistic situation for mobile router applications. In addition, route optimization is more important for the movement of the mobile network than for the movement of a single mobile node because of the larger amount of traffic to be processed.

The preferred embodiment of the present invention is described with respect to routing optimization in sending at least one data packet between a corresponding node (communication unit) and a local fixed node (or, vice versa). In this regard, routing Optimization is seen as the "shortest path" direct communication between a mobile network node (MNN) and its corresponding node (CN), especially for mobile networks with nested mobility (mobile network accessing mobile network) Inside the MNN.

It is envisaged that the corresponding node may be any communication unit capable of sending data packets through a data network (such as the Internet), such as a web server, a PC, or a workstation running a web server such as www.yahoo.com, and so on. The CN can also be any mobile data communication unit connected to the data network through any type of access, such as a general packet radio system (GPRS) device or third-generation (3G) cellular phone, personal data assistant, and so on. Note that the CN itself can also be located in the mobile network.

As explained in the previous section, when the mobile router (MR) moves to an external network, it must send a binding update (BU) message to its home agent (HA). By sending a BU message to its HA, the MR can maintain IP acquisition capabilities for itself and the node (MNN) it serves.

According to the preferred embodiment of the present invention, there are no restrictions on the mechanism used by the mobile network to notify its home agent about its own new location. In this regard, any known method can be modified and used, for example in June 2001 Thierry Ernst, Hong-YonLach [3]: IETF Internet-Draft draft-ernst-mobileip-ipv6-02.txt or November 2001 TJKniveton[5]: Those methods described in IETF Internet-Draft draft-kniveton-mobrtr-00.txt. Modifications to these technologies can facilitate routing optimization in nested mobility situations.

In addition, in the enhanced embodiment of the present invention, it is shown how to supplement the method of Thierry Ernst, [3]: IETF Internet-Draft draft-ernst-mobileip-ipv6-02.txt and [5] in June 2001 in order to Obtain the route optimization on the path HA->MN (where MN is a host or router).

The preferred embodiment of the present invention utilizes three key concepts, which are used individually or preferably in combination. The three key concepts are: (i) advertise the mobility of the mobile router in the mobile network of the mobile router, and (ii) send one or more extended binding update messages to their respective CNs through the MNN. The extended binding update message sent by MNN should include a "care-ofroute" instead of a single address in vanilla mobile IP. The forwarding route is an ordered list of IP addresses. CN uses this list to route its packet source to MNN on the shortest path.

(iii) The CN receives the extended BU message. In response to the received BU message, the source route packet goes to the MNN through the route obtained from the care-of-route address in order to obtain route optimization.

(A) The mobile router advertises its mobility in the mobile network: For the MNN in a single mobile network and a multi-layer aggregate mobile network (nested network), in order to achieve routing optimization, the concept of the present invention is described here It is recommended that MNNs know the mobility of the mobile network (or mobile router) they join. This is directly opposite to the method proposed in [3], in which the mobility of the mobile router in [3] is hidden from each of its MNNs.

In order to announce that it has moved to a new join point, the mobile router (such as MR1) sends a "care-of-route announcement" message addressed to all nodes behind it (ie, any LFN, LMN, VMN) to the mobile it serves Network. In nested network mobility, the message includes MR1's own care-of address and the care-of addresses of all mobile routers on MR1 in the collective mobile network architecture. The care-of address list of the above mobile routers is preferably arranged in order and constructed dynamically through care-of-route advertisements sent at each level of the architecture of the collective mobile network.

Referring now to FIG. 6, a network topology 600 for advertising the mobility of such a mobile router in a mobile network according to a preferred embodiment of the present invention is illustrated. In particular, the topology according to the preferred embodiment of the present invention shown in FIG. 6 illustrates that nested mobility is supported. Those skilled in the art should recognize that the limited number of elements shown in the network of FIG. 6 is only for clarity purposes.

The network topology shown in Figure 6 illustrates that a second mobile network (MR2) accesses a first mobile network (MR1) that joins the visited network. The first mobile network includes a fixed router (LFR1), which serves its own link.

Since MR1 650 is accessing the external network 110, it has obtained the care-of address {MR1_CoA}652. The external network 110 is fixed, so there is no forwarding route advertisement in the link between the access link 110 and the MR1 650. According to the preferred embodiment of the present invention, MR1 650 constructs its own care-of-route advertisement message and includes its own care-of address 652 in the advertisement message.

The message is multicast to all nodes in its own link (MR1 link 155) through its entrance. Therefore, all nodes on the link receive the notification message. When receiving such a message, routers (LFR, LMR, VMR) should extract the ordered list of care-of addresses 652 and forward the list to the link they serve. At this point, the second MR (MR2) 660 forwards the care-of address 652 to its own link (MR2 link) 230. If the router is the highest router of a mobile network that is not in its home network (ie, VMR as in the case of MR2 660), then it adds its own care-of address to the received list. The MR2 660 then includes the care-of address of the MR2 in the generation of a new ordered list. MR2 then generates its own care-of-route announcement message, which will then be multicast on its own link (MR2 link) through its own entry. Therefore, when the ordered list (MR1_CoR 652, MR2_CoR 662) is announced on the second mobile network 230, MR1_CoR is announced in the first mobile network (including the MR1 link 155 and the LFR1 link 670).

The processing of using the extended BU message to notify CN2 655 of the best route to LFN2 655 via MR2 care-of address 662 will be described later. In this way, the entire routing of data packets can be determined through improved extraction, utilization, and announcement of address data in the entire network.

The process shown in Figure 6 illustrates a practical situation where there may be many nesting levels. Therefore, those skilled in the art should be aware that the aforementioned processing can easily be generalized to n consecutive levels (n mobile routers MR1,..., MRn and n corresponding home agents HA1,..., HAn). Nested mobility.

Now referring to Figures 7, 8 and 9, it will be described that according to a preferred embodiment of the present invention, any router in the mobile network, such as MR, VMR, LFR, and LMR, constructs and sends to be included in the care-of-route advertisement (CoR_Advt) message The various flowcharts 700, 800, and 900 of the care-of address list in. In addition, these processes are only effective for the MNN as a router (e.g., LFR, MR).

Basically, in response to one of the following three events, the router in the mobile network will send a CoR_Advt message: (i) As shown in Figure 7, a CoR_Advt message is received on its exit, which modifies its own CoR; (ii) Send a CoR_Advt periodically as shown in FIG. 8; (iii) As shown in FIG. 9, receive a forward routing request (CoR_Sol) message on the entry ifc.

In FIG. 7, processing starts in step 710. As shown in step 720, a new CoR_Advt message is received on its exit, and the care-of address list is extracted as further described in the processing of FIG. 11. If the corresponding MNN forwarding route (MNN_CoR) has not changed in step 740, the process ends in step 780. However, if the corresponding MNN_CoR address has been changed in step 740, as shown in step 750, the router creates a new CoR_Advt message and includes (adds) the new MNN_CoR to the message. Then, as in step 760, the new CoR_Advt message is sent to all nodes through all the entries of the corresponding MNN.

In FIG. 8, the flowchart illustrates the preferred processing if the periodic CoR_Advt message timer has expired in step 820. In this case, as shown in step 850, the router creates a new CoR_Advt message and includes (adds) MNN_CoR to it. As in step 860, the new CoR_Advt message is then sent to all nodes through all the entries of the corresponding MNN. Then, in step 870, the CoR_Advt message timer is restarted.

Only when the CoR of the router becomes non-null (that is, contains at least one address), the router (MR, LFR, LMR, VMR) in the mobile network will start the periodic transmission of the CoR_Advt message. It is assumed that when the CoR of the router becomes null/empty, the router will end the periodic transmission. For example, when the MR (or a highest-level MR) moves out of its home network, the MR will start periodic transmission and end the periodic transmission when it (or a highest-level MR) returns to its home network.

In FIG. 9, as shown in step 920, the flowchart illustrates the preferred processing when a forward-to-route request (CoR_Sol) message is received on the ingress ifc. In this case, as shown in step 950, when the (CoR_Sol) message is received on the entry ifc_j, the router creates a new CoR_Advt message and includes (adds) MNN_CoR to it. Two possible methods are envisaged for the operation of sending CoR_Advt in step 960. The first method is to send the CoR_Advt message to the source address of the forwarding route request message (CoR_Sol) through ifc_j. As an alternative, the CoR_Advt message can be sent to all nodes on the link via ifc_j. For example, when a mobile router (MR) changes its location, it should send a CoR_Sol message in order to receive a CoR_Advt message back. The MR can then calculate its new care-of address (CoR). The CoR consists of an ordered list of addresses received in the CoR_Advt message (if not empty), where the new care-of address of the MR is added to the list. Because the new CoR is not empty, the MR then starts its own periodic transmission of CoR_Advt messages.

Several methods are envisaged for the realization of forwarding route requests and forwarding route announcements. First of all, the message can be implemented as an Internet Control Message Protocol for IPv6 IETF RFC1885 (ICMPv6) extension, or as a user datagram protocol IETF RFC 768 (UDP), transmission control protocol IETF RFC 793 (TCP), etc. Any new protocol on top of IP (v4 or v6).

Secondly, the forwarding route announcement message can be sent to the IPv6 all-node link-local (all node local subnet) multicast address. In this case, the message is only sent on the local link. A preferred way should be to send the forwarding route announcement to the IPv6 all-node site-local (all node local network) multicast address, where site is the entire mobile network served by the MR. This helps to reduce the operation of intermediate routers (LFR, LMR in the home country) in the mobile network, because the forwarding route advertisement will then be forwarded transparently to all links of the mobile network. In this way, there is no need for the intermediate router (LFR, LMR at the origin) to extract and copy the CoR list.

The preferred implementation of these messages is to define them as extensions of ICMPv6 route request and ICMPv6 router advertisement messages. The care-of-route advertisement message should be an ICMPv6 route advertisement message (RA), which includes a new "care-of-route advertisement" option. The forwarding route request message should be an ICMPv6 router solicitation message (RS), which includes a new "forwarding route announcement" option. When a router must announce its (non-empty) _CoR in the mobile network, the forwarding route advertisement option should be included in the RA. An MNN explicitly requests the RA to forward the route advertisement option, and the forward route advertisement option can be included in the RS. If the option is not included in the RA, it means that the CoR of the router is null/empty.

Referring now to FIGS. 24 and 25, the forwarding route request message and the forwarding route announcement message according to the preferred embodiment of the present invention are respectively described.

The care-of-route request (CoR_Sol) message 2400 in FIG. 24 is an ICMPv6 router solicitation message extended with the new "care-of-route request" option. It includes a single IP header 2425, which includes an IP source address 2410 for the host and an IP destination address 2420 indicating the IP multicast addresses of all routers. The IP header 2425 is followed by a router solicitation message 2430, which contains a forward-route request (CoR_Sol) option.

The care-of-route advertisement (CoR_Advt) message 2500 in FIG. 25 is an ICMPv6 router advertisement message extended with the new "care-of-route advertisement" option. It includes a single IP header 2525, which includes an IP source address 2510 for the router's ingress and an IP destination address 2520 indicating the node (or all nodes on the link) that is to receive the packet. The IP header 2530 contains a care-of-route advertisement option, which includes the care-of-route advertised by the router (ie, an ordered address list).

B) MNNs send extended binding updates to their corresponding CNs: Any MNN in the mobile network, including LMN or VMN, should send a so-called extended binding update to its CN in order to obtain the path CN-> The best route on MNN. According to a preferred embodiment of the present invention, the extended BU message sent by the MNN includes a "care-of-route" instead of a separate care-of address known in mobile IP. As mentioned above, the care-of route is an ordered list of IP addresses from which the CN can obtain the source route in order to route its packets to the MNN through the shortest path (ie, route optimization).

Referring now to FIG. 10, a network topology 1000 for sending an extended BU to a CN according to a preferred embodiment of the present invention is described. For clarity purposes only, this topology continues the topology described above with reference to FIG. 6.

Each MNN in the mobile network obtains its forwarding route from the forwarding route notification message it receives from the upper-layer router. For example, the LFN1 675 care-of route is a single-hop route equal to the care-of address {MR1_CoA}652 of MR1650. LFN1 675 then sends an extended BU message 1010 to CN1 1030 indicating its care-of address.

On the contrary, the care-of route of LFN2 665 is a double-hop route equal to {MR1_CoA->MR2_CoA}. In this regard, the LFN2 665 forwarding route uses the MR2 CoA 662 and the upper router from MR2, which is the CoA 652 of MR1 650. LFN2 665 then sends an extended BU message indicating MR1_CoA 652 and MR2_CoA 662 to 1020.

Referring now to FIG. 11, a preferred algorithm for MNN to generate its own care-of-route (MNN_CoR) according to a preferred embodiment of the present invention is described. This process (process A) starts at step 1110. When the MNN receives a new CoR_Advt message on its interface ifc_i in step 1120, it determines whether it is an exit in step 1130. If it is not an exit, then the CoR_Advt is ignored and the process ends in step 1190. In this case, the MNN's forwarding route has not been changed.

If ifc_i is at the exit, then in step 1140 the MNN extracts a new CoR(new_CoR)-IP address ordered list from CoR_Advt, and in step 1150, it checks whether the MNN is in its hometown (that is, ifc_i joins its home IP subnet) ) Is determined. If the MNN is in the hometown, then if there is a difference between routers in step 1170, the MNN_CoR is replaced with new forwarding routing information in step 1180. If the MNN is not in the hometown, then in step 1160, the care-of address of the MNN (obtained in the visited location) is added to the ordered list of care-of addresses received in the care-of-route announcement message to construct the care-of route of the MNN.

Note that if the MNN does not intend to benefit from path optimization on the path CN->MNN or on the path HA->MNN, then the MNN may not maintain such a handover route. However, in the preferred embodiment of the present invention, it is recommended that such care-of routing knowledge should be maintained in order to support the methods described in [3] and [5]. As described later, in this way, it is possible to achieve route optimization on the path HA->MN, where MN is a host or a router.

Note that the method described in Figure 11 is valid for any MNN, regardless of whether the MNN is a router or a host, fixed or mobile.

Referring now to FIGS. 12 and 13, the flow chart of the MNN sending an extended BU message to its CN (and Home Agent-HA) according to a preferred embodiment of the present invention will be described. The flow chart can be applied to any MNN, no matter if the MNN is a router or a host, it is fixed or mobile.

FIG. 12 illustrates a flowchart 1200 of sending an extended BU message after receiving a CoR_Advt message at its exit in step 1215. Upon receiving the CoR_Advt message, the MNN performs the process'A' described in FIG. 11 to generate its own CoR as shown in step 1220. If its CoR has not changed in step 1225, then the process ends in step 1265. However, if the CoR changes in step 1225, then in step 1230 the MNN determines that all of its CNs need to receive an update CoR message. In order to send an extended BU message containing the update CoR message in step 1240, the MNN gradually passes through each CN from the first CN in step 1235. If the CN that received the extended BU message containing the update CoR message transmission in step 1245 is not the last CN identified by the MNN, then in step 1250 the processing proceeds to the next CN until all CNs have received the transmission.

For the MNN not in the home country, as shown in steps 1255 and 1260, a preferred optional step is to send a message including its new care-of-route (CoR) to its home agent (HA), which is either an extended BU or Is the extended prefix range BU (if the MNN uses [3] to send the BU to its HA).

FIG. 13 depicts an alternative flowchart 1300 for sending an extended BU message to its CN (or its HA) after periodically sending an extended BU (EBU) to the CN (HA if the MNN is a mobile host or router). In step 1320, the periodic transmission only occurs when the CoR of the MNN is not null after the periodic EBU timer related to the specific CN (such as CNi) or the HA of the MNN expires. In step 1330, the extended BU message containing the updated CoR message is sent to CNi (or HA). In step 1340, the timer function associated with the respective CN (e.g. CNi or HA) is then restarted.

Note that with regard to Figures 12 and 13, the CN can be a fixed or mobile host in the Internet and another MNN (from the same or different mobile network).

Still referring to Figures 12 and 13, if the MNN (host or router) is in the home country (that is, the LFN, LMN in the home country), then the MNN sends an extended binding update to all its CNs (not to its HA, because It is in the country of origin). If the MNN (host or router) is accessing the network (ie, VMN), then the MNN sends an extended binding update to all its CNs and preferably its home agent.

If the MNN wants to obtain route optimization on the path HA->MNN, the MNN can send an extended binding update to its home agent. This method extends the techniques proposed in [3] and [5] by sending BUs to replace their basic binding updates. In the case of [3], the mobile router (MR) sends a so-called prefix range BU message to its HA. Regarding this point, we define here a binding update message extension called "extended prefix range binding update", which includes the MR forwarding route instead of the only MR forwarding address. The extended prefix range binding update can be sent by the MR to its HA, so as to achieve route optimization on the path HA->MR.

In the case of [5], the mobile router (MR) sends a basic mobile IP binding update. At this point, we define an extension of the BU message as an "extended binding update" (as described above). This includes MR care-of routing instead of the only MR care-of address. The extended binding update can be sent by the MR to its HA to achieve route optimization on the path HA->MR.

It is worth mentioning that each MNN that sends an extended BU message preferably maintains an extended'extended binding list' defined as an extension of the mobile IP binding list, and the care-of-route is used instead of the care-of address in the extended binding list.

Referring now to FIG. 14 and FIG. 15, a flow chart of the optimization process in which the MNN sends an extended BU to its CN (and its HA) for communication between mobile networks according to a preferred embodiment of the present invention will be described. It is envisaged that this enhanced processing improves network performance by avoiding sending'useless' extended BU messages in the case of mobile network communication. In fact, when two nodes (fixed or mobile in the hometown) of the same mobile network (that is, not isolated from the hometown by the mobile router) send packets to each other, the routing infrastructure in the mobile network can naturally achieve optimal routing.Chemical. Likewise, they do not need to exchange extended BU messages between each other.

In Fig. 14, as an extension of the flowchart of Fig. 12, when the MNN is the host at the hometown (that is, the LFH or LMH at the hometown), as in step 1410, the MNN only sends an extended binding update to its CN, these CNs are not in the same mobile network. Also, when the MNN is in the router of origin (that is, the LFR or LMR of the origin), as in step 1410, the MNN only sends an extended binding update to its CNs, and these CNs are not in the same mobile network. If the MNN (host or router) is accessing the network (ie, VMN) in step 1420, then in step 1240 the MNN only sends an extended binding update to its CNs, and these CNs are not in the accessing mobile network. For the CN in the visiting mobile network, in step 1430, the MNN may send an extended binding update or preferably a modified extended binding update, where only the forwarding route is specified in the modified extended binding update An address, that is, only MNN's own care-of address.

In steps 1260 and 1450, the mobile MNN (host or router) preferably also sends a binding update to its home agent. At this point, consider these two cases below. When the MNN moves out of its home agent network, the MNN preferably sends an extended binding update to its HA. When the MNN is in an external IP subnet within its home mobile network, the MNN can send an extended binding update. As an alternative, the MNN may send a modified extended binding update, in which only one address is specified in the care-of route in the modified extended binding update, that is, only its own care-of address.

It is assumed that in the case where the MNN wants to achieve routing optimization on the path HA->MNN, the MNN can send the extended BU in the operation of [3] or in the operation of [5] as described above The extended prefix range BU to send an extended BU message to its home agent.

In FIG. 15, a similar enhancement to FIG. 13 is described. As shown in steps 1510, 1520, and 1530, an extended message containing only MNN_CoA is sent to each CN, and these CNs and MNNs operate in the same mobile network.

Referring now to FIGS. 26 and 27, the extended BU message sent from the LFN or VMN according to the preferred embodiment of the present invention is respectively explained.

The extended BU sent from the LFN message 2600 in FIG. 26 includes a single IP header 2625 that includes the IP source address 2610 of the LFN and the IP destination address 2620 for the CN address. The IP header 2625 is followed by a mobile IPv6 BU message 2630, which contains the forward-route mobility option, which contains the forward-route of the LFN.

The extended BU sent from the VMN message 2700 in FIG. 27 includes a single IP header 2725, which includes the IP source address 2710 of the VMN care-of address and the IP destination address 2720 for the CN. The IP header 2725 is followed by a mobile IPv6 BU message 2730, which contains the hand-off route mobility option, which contains the hand-off route of the VMN.

Referring now to FIG. 16, a flowchart 1600 of a method for dynamic discovery of a mobile network prefix for any MNN in a mobile network according to a preferred embodiment of the present invention is illustrated. In this regard, as described above, when sending an EBU to the said CN, a node such as MNN can know whether the second node, that is, its CN is in the same current mobile network as it.

The process (process B) starts at step 1610. When the MNN receives a new mobile network prefix advertisement message (Mobile_Network_Prefix_Advt) on its interface ifc_i in step 1620, it determines whether it is an egress in step 1630. If it is not an exit, then the Mobile_Network_Prefix_Advt is ignored and the process ends in step 1670. In this case, the mobile network prefix (MNN_Mobile_Network_Prefix_Advt) of the MNN has not been changed. If ifc_i is at the exit, then in step 1640 the MNN extracts a new Mobile_Network_Prefix (new_Mobile_Network_Prefix) and its prefix length (new_Mobile_Network_Prefix_Length) from Mobile_Network_Prefix_Advt, and in step 1650 whether the MNN origin address in ifc_i is the same as the first part It is determined that the MNN_Mobile_Network_Prefix on the MNN_Mobile_Network_Prefix_Length bit matches. If it matches, then in step 1650 the MNN_Mobile_Network_Prefix and MNN_Mobile_Network_Prefix_Length are replaced with new information, and the process ends in step 1670. If there is no match, then the process directly ends in step 1670.

Note that the method described in Figure 16 is valid for any MNN, regardless of whether the MNN is a router or a host, fixed or mobile.

Referring now to FIG. 17, FIG. 18, and FIG. 19, a flowchart 1700, 1800 of a fixed router (ie, LFR) in a mobile network constructing and sending its own mobile network prefix advertisement (Mobile_Network_Prefix_Advt) message according to a preferred embodiment of the present invention will be described. And 1900.

Basically, the fixed router in the mobile network will send a Mobile_Network_Prefix_Advt message in response to one of the following three events: (i) As shown in Figure 17, it receives a Mobile_Network_Prefix_Advt message on its exit, which modifies its own MNN_Mobile_Network_Prefix; (ii) Send a Mobile_Network_Prefix_Advt periodically as described in FIG. 18; (iii) As shown in FIG. 19, receive a forwarding route request (Mobile_Network_Prefix_Sol) message on the entry ifc.

In FIG. 17, processing starts in step 1705. As shown in step 1710, a new Mobile_Network_Prefix_Advt message is received at its exit, and the new mobile network prefix (Mobile_Network_Prefix) and its length are extracted as further described in the processing of FIG. 16. If the corresponding MNN_Mobile_Network_Prefix and MNN_Mobile_Network_Prefix_Length have not been changed in step 1720, then the process ends in step 1735. However, if the corresponding MNN_Mobile_Network_Prefix and MNN_Mobile_Network_Prefix_Length have been changed in step 1720, then as shown in step 1725, the router creates a new Mobile_Network_Prefix_Advt message and includes (adds) the new MNN_Mobile_Network_Prefix and MNN_Mobile_Network_Prefix_Length to the message. As in step 1730, the new Mobile_Network_Prefix_Advt message is then sent to all nodes through all the entries of the corresponding MNN. The flowchart described in Figure 17 can only be applied to fixed routers in mobile networks.

In FIG. 18, the flowchart illustrates the preferred processing if the periodic Mobile_Network_Prefix_Advt message timer has expired in step 1810. In this case, as shown in step 1815, the router creates a new Mobile_Network_Prefix_Advt message and includes (adds) MNN_Mobile_Network_Prefix and MNN_Mobile_Network_Prefix_Length to it. As in step 1820, the new Mobile_Network_Prefix_Advt message is sent to all nodes through all the entries of the corresponding MNN (fixed router). Then in step 1825, the CoR_Advt message timer is restarted.

Only when the CoR of the router becomes non-null (that is, contains at least one address), the router (MR, LFR, LMR, VMR) in the mobile network starts the periodic transmission of the Mobile_Network_Prefix_Advt message. It is assumed that when the CoR of the router becomes null/empty, the router will end the periodic transmission. For example, when an MR (or a highest-level MR) moves out of its home network, the MR will start periodic transmission and end the periodic transmission when it (or the highest-level MR) returns to its home network.

In FIG. 19, as shown in step 1910, the flowchart illustrates the preferred processing when the mobile network prefix request message (Mobile_Network_Prefix_Sol) is received on the entry ifc. In this case, as shown in step 1920, when receiving the (Mobile_Network_Prefix_Sol) message on the entry ifc_j, the router creates a new Mobile_Network_Prefix_Advt message and includes (adds) MNN_Mobile_Network_Prefix and MNN_Mobile_Network_Prefix_Length to it. Imagine two possible methods for the operation of sending Mobile_Network_Prefix_Advt in step 1925. The first method is to send the message to the source address of the mobile network prefix request message (Mobile_Network_Prefix_Sol) through ifc_j. As an alternative, the mobile network prefix announcement message can be sent to all nodes on the link through ifc_j. The flowchart in Figure 19 can be applied to any router (MR, LMR, LFR, VMR) in a mobile network.

Note that when a mobile router (MR) changes its location (and thus gets a non-zero (null) CoR), it should send a Mobile_Network_Prefix_Advt message on its entrance.

The mobile router can know the prefix from its internal configuration. On the other hand, fixed routers (i.e., IFR) in the mobile network cannot know in advance the mobile network prefix to which they belong, but can dynamically discover it through the steps described in FIG. 17. Such a fixed router can of course send a Mobile_Network_Prefix_Sol message in order to receive a Mobile_Network_Prefix_Advt back.

Several methods are envisaged for mobile network prefix request and mobile network prefix announcement messages. First, the message can be implemented as an extension of ICMPv6 or as any new protocol on top of IP, UDP, TCP, etc. ICMP, UDP and TCP are protocols based on IP (v4 or v6): -ICMPv6: Internet Control Message Protocol for IPv6, IEFT RFC 1885 -UDP: User Datagram Protocol, IETF RFC 768-TCP: Transmission Control Protocol, IETF RFC 793 Secondly, you can send a network prefix advertisement message to the IPv6 all-node link-local multicast address. In this case, the message can only be sent on the local link. A preferred way should be to send the forwarding route announcement to the all-node site-local multicast address of IPv6, where site is the entire mobile network served by the MR. This will help reduce operations on intermediate routers (ie LFR) in the mobile network, because the message will then be forwarded transparently to all links of the mobile network. In this way, there is no need for the intermediate router (ie, LFR) to extract and copy the mobile network prefix.

The preferred implementation of these messages is to define them as extensions of ICMPv6 router solicitation and ICMPv6 router advertisement messages. The mobile network prefix advertisement message should be an ICMPv6 router advertisement message (RA), which includes a new "mobile network prefix advertisement" option. The mobile network prefix announcement message should be an ICMPv6 router solicitation message (RS), which includes a new "mobile network prefix announcement" option. When a router must announce the mobile network prefix in the mobile network, the mobile network prefix advertisement option should be included in the RA. An MNN explicitly requests the mobile network prefix notification option from the RA, and the mobile network prefix request option may be included in the RS.

Referring now to FIG. 22 and FIG. 23, a mobile network prefix request message and a mobile network prefix announcement message according to the preferred embodiment of the present invention are respectively described.

The mobile network prefix request message 2200 in FIG. 22 is an ICMPv6 router request extended with a new mobile network prefix request option. It includes a single IP header 2255, which includes an IP source address 2210 for the host and an IP destination address 2220 indicating the IP multicast addresses of all routers. The IP header 2225 is followed by a router request message 2230, which contains the mobile network prefix request option suggested in this document.

In FIG. 23, the mobile network prefix advertisement message 2300 is an ICMPv6 router advertisement message extended with a new mobile network prefix advertisement option. It includes a separate IP header 2325, which includes an IP source address 2310 for router ingress and an IP destination address 2320 indicating the node receiving the packet. The IP header 2325 is followed by a router advertisement message 2330, which includes the mobile network prefix and the mobile network prefix length advertised by the router.

C) The corresponding node and the home agent receive the extended binding update: Referring now to FIG. 20, a flowchart 2000 illustrates a preferred embodiment of the present invention, the first node is based on its extraction in the extended binding cache (EBC) , Send a data packet to the second node. As shown in step 2020, the first node, such as CN or HA, receives an indication that a data packet is to be sent to the second node. The second node is, for example, an MNN. In step 2023, the CN searches for the MNN address in an extended binding cache (EBC) storing the care-of route, where the care-of route is obtained from the care-of-route information received in the extended BU.

If an MNN is found in step 2024, as in step 2050, the CN (or HA) can route the packet source to the MNN through the forwarding source route found in the EBC, thereby realizing route optimization. Otherwise, as shown in step 2060, the CN uses known techniques to directly send the data packet destined for the MNN to the home address of the MNN.

Referring now to FIG. 21, a preferred example of the data packet format sent by the first node, that is, a CN, to the second node, that is, MNN, according to the preferred embodiment of the present invention is described.

The format of the data packet 2100 includes a single IP header 2110, which includes an IP source address 2112 and an IP destination address 2114, the destination address being equal to the first IP address in the CN forwarding source route to the MNN. The single IP header 2110 is followed by a routing header 2120, which contains (m-1) other addresses in the route to the second node (from the CN forwarding source route to the MNN). The data payload 2130 immediately follows the routing header.

The second format of the data packet 2150 includes'm' consecutive IP headers, each of which includes respective IP source addresses 2112, 2152, 2162, 2172 and respective destination addresses 2114, 2154, 2164, and 2174. Therefore, the'm' consecutive IP headers do not need a separate routing header, and the data payload 2180 immediately follows these IP headers. Each of the consecutive IP headers has its own IP destination address, which is set to be equal to one of the IP addresses forwarded to the source route by the CN to the MNN. The first header contains the first address of the care-of-source routing (CoSR), the second header contains the second address, and so on to the last header. The final IP header 2172, 2174 and the data payload 2180 together form the original packet 2190 sent from the first node to the second node.

Each node (CN, MNN, HA) that should receive extended binding updates should maintain an extended binding super cache (EBC). The EBC is defined here as an extension of the mobile IP cache, in which the "care-of-source route (CoSR) obtained from the care-of-route (CoR) received in the extended binding update is used instead of the care-of address. It is worth mentioning that the forwarding route listed in the extended binding cache may be slightly different (ie shorter) from the forwarding route received in the extended binding update.

Referring now to FIG. 28, an extended binding cache 2800 according to a preferred embodiment of the present invention will be described.

The extended binding cache 2800 includes a list of entries 2810, 2840, 2870, each entry dedicated to a home address of an MNN. The extended binding cache entry 2810 includes, for example, a first home address 2815 and a link 2818 to the first care-of source route 2820 (if a care-of route has been determined). The first care-of source route 2820 includes inter-linked care-of source route addresses 2825, 2830, and 2835, which are used to identify routes to the first home address. The first entry 2810 links 2837 to a second entry 2840, which has a link 2848 from the second home address 2845 to the second care-of route 2850 (if a care-of route has been determined). The second care-of route 2850 includes inter-linked care-of-route addresses 2855, 2860, and 2865 for identifying routes to the second home address. A similar arrangement and link 2867 are performed for the third entry 2870, and so on.

In consideration of the present invention, the extended BU may also include entries for mobile router (MR) prefix and prefix length. As an extension to [3], this is particularly useful when the MR sends an extended prefix range BU to its HA or CN, and CoR is used instead of CoA in the prefix range binding update. In this case, replace the home address field with a'prefix or prefix length' field in the EBC of each HA or CN.

Referring now to FIG. 29, a structure for forwarding source routing 2900 from a received extended BU structure according to a preferred embodiment of the present invention will be described. The first node care-of route (N1_CoR) contains an ordered list of care-of-route addresses (N1_CoR[1], N1_CoR[2],...) 2910. When the first node N1 receives an extended BU message containing the N2 care-of route (N2_CoR) from the second node N2, the first node compares the two ordered lists of care-of routes to determine when there is a difference 2940 between them. The addresses from N2_CoR and all subsequent addresses from N2_CoR that are determined to be different are then used to generate a new care-of source route 2930 for the data packet transmission from N1 to N2. This processing is further described with reference to the flowchart of FIG. 30.

Referring now to FIG. 30, a flowchart 3000 of the process of determining a care-of source route to be included in the extended binding cache according to the preferred embodiment of the present invention is illustrated. The first node (N1) receives an extended binding update from the second node (N2) and needs to determine the care-of source route to be included in the extended binding cache for this entry (N2).

The process starts in step 3002. When in step 3004 a first node (N1, which can be an MNN in the home or an external network, or any host in the topology) receives an EBD, the EBD contains a new one for the second node (N2) In step 3006, N1 determines whether the N2 forwarding route (received in the EBU) is empty.

If the new forwarding route for N2 received in the EBU in step 3006 is empty, then as shown in step 3008, N1 searches through its extended binding cache to check whether there is any The entry of the second node (that is, forwarded to the source route). If there is no entry in the EBC, then no entry for N2 is needed in the extended binding cache of N1. When the packet is sent to the home address of N2, the data packet from N1 will be directly on the shortest path (route optimization can be achieved without source routing). However, if there is an entry in the EBC in step 3008, the second node entry (ie, N1_CoSR(to N2)) is deleted in step 3010 before the processing ends in step 3046.

If the new N2 care-of route received in the EBU in step 3006 is not empty, a determination is made 3012 as to whether a care-of route entry is available for the first node in step 3012. If the forwarding route cannot be used for the first node in step 3012, as shown in step 3014, a first node (N1) forwarding source route (N1_CoSR(to N2):=N2_CoR) equal to the second node forwarding route is generated. As shown in step 3016, N1 then carefully searches its extended binding cache to check whether there is an entry for the second node in the EBC (ie, a care-of route). If there is no entry in the EBC, an entry for N2 is added to the EBC in step 3020 (N1_CoSR(to N2)). When the packet is sent to the home address of N2, the data packet from N1 will be directly on the shortest path (to achieve routing optimization without source routing). However, if there is an entry in the EBC in step 3008, the second node entry (ie, N1_CoSR(toN2)) is deleted in step 3010 before the process ends in step 3046, and the process ends in step 3046. If there is an entry in the EBC in step 3016, the second node entry (ie, N1_CoSR(to N2)) is updated in step 3018 before the process ends in step 3046.

If the first node has its own care-of route in step 3012, then all addresses in the care-of routes (N1 and N2) of the two nodes are searched, starting from setting a counter (i=0) in step 3022. In step 3024, N1 compares the IP addresses in its own care-of route (N1_CoR) and the IP addresses listed in the care-of route of the extended binding update received from node N2 one by one.

It starts from the first address N1_CoR(1) and N1_CoR(1), and then continues. If a specific address of the first and second care-of routes is found to match in step 3026, then in step 3028, a determination is made as to whether the second node's care-of route address is the last address. If it is the last address in step 3030, then all the care-of routes of N2 have been searched, and the process proceeds to step 3008 as described above. If the second node care-of routing address is not the last address in step 3008, then in step 3032, whether the first node care-of routing address is the last address for the first node is performed. If in step 3032, the first node care-of-routing address is not the last address, then in step 3034 the counter is incremented, and in step 3024, the next address is searched. If the first care-of-route address is the last address in step 3028, or no match is found in step 3026, the search process stops in step 3036 and the care-of-route from N1 to N2 is set in 3038.

In 3038, the care-of route from N1 to N2 is set equal to the ordered list of the address parts of the N2 care-of route starting from the i-th address to the last address. The i-th address is the address where the loop in the care-of-routing address of N2 stops at step 3036. That is: N2_CoSR(to N2)={N2_CoSR(i)->N2 CoSR(i+1)->...->N2_CoSR(n-1)->N2_CoSR(n)}. As shown in step 3040, N1 then carefully searches its extended binding cache to check whether there is an entry for the second node in the EBC (ie, a care-of route).

If there is no entry in the EBC, then in step 3042 an entry for N2 is added to the EBC (N1_CoSR(to N2)) and the process ends in step 3046. If there is an entry in the EBC in step 3040, before the process ends in step 3046, the second node entry in the EBC of N1 (ie, N1_CoSR(to N2)) is updated in step 3044.

If N1 does not have a care-of route in step 3012 (NR_CoR is empty or does not exist), then in step 3014, the care-of route from N1 to N2 is set to be equal to the care-of route of N2. That is, N1_CoSR(to N2)=N2_CoR. Then, as shown in step 3016, N1 searches its extended binding cache carefully to check whether there is an entry for the second node in the EBC (ie, a forwarding route). If there is no entry in the EBC, an entry for N2 is added to the EBC in step 3020 (N1_CoSR(to N2)) and the process ends in step 3046. If there is an entry in the EBC in step 3016, before the process ends in step 3046, the second node entry in the EBC of N1 (ie, N1_CoSR(to N2)) is updated in step 3018.

As described with reference to Figure 21 and Figure 22, then N1 should route the packet source to N2 via the forwarding route in order to achieve route optimization. As mentioned before, this can be achieved in several ways. The first way is to use the IPv6 routing header. In this case, the first address in the care-of-route is set as the destination address in the IPv6 header and the remaining addresses of the care-of-route (CoSR) are set in the router header in the same order. The second way is to claim that the first node establishes an'n'-level data packet encapsulation to send, where'n' is the number of addresses in the forwarding route. The encapsulation #k will take the address #k in the ordered list of addresses in the forwarding route as the destination address.

In addition, the various steps described above need not necessarily be performed in the described order. Those skilled in the art should realize that alternative sequences can be used, in which case benefits can still be obtained in the routing optimization process.

It should be realized that the configurations and specific details of interfaces, address types, routers, etc. in the above embodiments are just examples, and the present invention is not limited to these examples. The present invention should be seen as being applicable to other aspects of the Internet or other types of data networks or protocols and their subnets. In addition, when other networks have subnets and access networks corresponding to the Internet situation described above, the present invention can also be applied to these networks other than the Internet.

The present invention or at least its embodiments are beneficial to provide the following advantages alone or in combination: (i) Using this improved routing optimization technology, data packets can be transmitted more efficiently.

(ii) Improved data packet transmission confidentiality, because each node in the topology is responsible for sending their own binding updates to their CN and home agent. Therefore, by sending a binding update, each node can determine whether it wants to disclose its current location in order to perform routing optimization. This is obviously better than not allowing confidentiality [3].

(iii) The IETF-defined security solution for providing authorization of "address ownership" (for example, return to Route-ability) is still applicable in the context of the present invention. This is also better than [3], because [3] requires the introduction of a new security mechanism.

(iv) The secure exchange of new messages introduced in the present invention (such as "forwarding route announcements") is very easy to implement, and can be achieved through shared secrets (in the case of nodes belonging to the same organization) or through, for example, mobile A new IEFT protocol such as PANA when a node (host or router) accesses the external network.

(v) Realize effective data routing solutions in IPv6, IPv4 or similar data network protocols, especially for systems that support nested network mobility.

The specific preferred implementations of the embodiments of the present invention are described above, and it is obvious that those skilled in the art can easily apply variations and modifications of these inventive concepts.

In this way, the mechanism, equipment, and related methods that support route optimization in the case of network mobility, especially IPv6, are described, which greatly alleviates the disadvantages related to known mechanisms, equipment, and related methods. In particular, the mechanisms, devices and related methods that support routing optimization in nested mobility are described.