WO2013007131A1

WO2013007131A1 - Mobility management method and mobile access gateway

Info

Publication number: WO2013007131A1
Application number: PCT/CN2012/075500
Authority: WO
Inventors: 骆文; 霍玉臻; 江鸿; 宋军; 沈岷
Original assignee: 中兴通讯股份有限公司
Priority date: 2011-07-14
Filing date: 2012-05-15
Publication date: 2013-01-17
Also published as: CN102883298B; CN102883298A

Abstract

A mobility management method and a mobile access gateway (MAG). The method comprises: when a mobile node (MN) is handed over from a source MAG (sMAG) to a target MAG (tMAG), the sMAG or the tMAG sending a first message carrying address information pointing to the tMAG to the MAG of a correspondent node (CN) of the MN; and the MAG of the CN of the MN receiving the first message, and updating the local cache according to the first message.

Description

Mobile management method and mobile access gateway

Technical field

The present invention relates to the field of mobile communications, and in particular, to a mobility management method and a mobile access gateway.

Background technique

The Transmission Control Protocol/Internet Protocol (TCP/IP) does not consider the topology change of the terminal in the initial design. That is, the TCP/IP protocol itself does not support mobility. In the traditional TCP/IP network environment, IP provides routing for the Internet. It assigns logical addresses, ie IP addresses, to all nodes (including hosts and routers), and each port of each host is assigned. An IP address. The IP address includes the network prefix and the host part. The IP addresses of all hosts on the same link usually have the same network prefix and different host parts. This allows IP to be routed based on the network prefix portion of the destination node's IP address, allowing the router to maintain a simple network prefix route without having to maintain a separate route for each host. In this case, since the network prefix route is used, when the node switches from one link to another without changing its IP address, the node cannot receive the data packet on the new link. Therefore, it is impossible to communicate with other nodes.

As users' demand for mobility and information rises sharply, more and more people want to access the Internet at high speed during the mobile process, get much-needed information, and do what they want. Therefore, the mobile Internet has become the development direction of the future Internet, but the traditional TCP/IP protocol does not support the defect of mobility, making the mobility management of mobile nodes a major problem facing the mobile Internet.

In order to solve the mobility management problem, the industry's more popular mobility management technologies include Mobile IP (MIP), Proxy MIP (PMIP) and so on. A common feature of these technologies is the introduction of a fixed anchor (Anchor) to achieve mobility management of mobile nodes. For example, the MIP protocol uses a Home Agent (HA) as an anchor point, and the PMIP protocol uses a Local Mobility Anchor (LMA) as an anchor point. Figure 1 shows the logical architecture of the PMIP protocol, including Mobile Node (MN), Correspondence Node (CN), Mobile Access Gateway (MAG), and LMA. The MAG is the first hop router of the MN, and its main function includes assigning an IP address called a Care of Address (CoA) to the MN when accessing the MN and performing an operation with the MN's anchor LMA for the MN. PMIP Binding (PMIP Binding). The LMA is the anchor of the MN, and its main role includes assigning the MN an IP address called Home of Address (HoA) and processing the above PMIP binding. The main purpose of the PMIP binding performed between the MAG and the LMA is to let both parties know the address of the other party, the above CoA and HoA, and store the information locally. In addition, in the process of performing PMIP binding, a bidirectional tunnel is established between the MAG and the LMA for the MN. It is worth noting that the IP address finally obtained by the MN is the HoA assigned by the LMA. In a typical network deployment, the MAG is generally located at a lower topology, such as at the edge of a metropolitan area network; and the LMA is generally located at a higher topology, such as the core of the provincial backbone. The MAG and the LMA are often connected by a multi-hop router.

After obtaining the HoA (IP address), the MN uses the HoA as its communication address to interact with the CN located on the IP network to send and receive IP packets. Figure 2 shows the process of sending and receiving IP packets between the MN and the CN. For example, the MN sends an Uplink IP packet to the CN. The destination address of the IP packet is the IP address of the CN, and the source address is the HoA of the MN. The MN sends the packet to the MAG to which it is connected. The MAG locally queries the anchor LMA address of the MN according to the HoA, and then sends the IP packet to the LMA in the tunnel between the MAG and the LMA; finally, the LMA will The IP packets sent by the MN are sent to the CN using the normal IP routing mechanism. Similarly, the downlink (downlink) IP 4 message sent by the CN to the MN also needs to pass the above LMA and MAG.

The mobility management of the PMIP protocol is reflected in the fact that the MN's mobile can change the currently connected MAG while keeping the MN's IP address (ie HoA) unchanged. As shown in Figure 3, changing the currently connected MAG means changing the connection to the target MAG (Target MAG, tMAG) from the previously connected source MAG (Source MAG, sMAG). After changing to tMAG, tMAG allocates a new CoA to the MN, and performs PMIP binding with the MN's anchor LMA for the MN, updating the information saved by the two parties mentioned above, and between tMAG and LMA. The MN establishes a new two-way tunnel. Referring to FIG. 2 and FIG. 3, before and after the MN moves the MAG of the changed connection (hereinafter referred to as handover), the path of transmitting and receiving the IP address between the MN and the CN can be expressed as MN<->MAG<->LMA<-> CN, all must detour to the anchor point LMA of the MN. Even if the MAG has a routing function, and there is an IP network connection between the MAG and the CN (Fig. 1), the IP packets cannot be directly sent and received through the MAG, and there is a waste of the packet transmission path.

When the MN is currently located away from its anchor LMA, the IP 4 transmitted and received between the MN and the CN must also be forwarded through its anchor LAM. Especially when the current location of the MN is closer to the CN, the above-mentioned waste of the transmission path will be more obvious. The solid line in Fig. 4 indicates that there is a wasteful route of the transmission path, and the dotted line indicates a route that is not wasted by the transmission path. The waste of the transmission path causes the carrier to waste the transmission of the bearer resources, which leads to an increase in the operating cost. On the other hand, the delay between sending and receiving IP packets between the MN and the CN is increased, which is not conducive to improving the user experience. It is to make a large number of IP packets converge to the MN's anchor LMA (in general, an LMA can serve many MNs), making LMA easy to become a performance bottleneck, increasing the possibility of packets being congested at the node, resulting in overall The quality of the network is degraded, causing the MN service to be blocked or even impossible to implement (for example, real-time services such as voice and video).

It should also be noted that the above CN may also be located in the PMIP domain, applying the PMIP mobility management mechanism described above (for example, CN is another mobile node, that is, CN' shown in FIG. 1). At this time, CN is also connected to a MAG, and there is also an anchor LMA. In this case, the transmission and reception path of the IP packet between the MN and the CN is: MN<-> MAG of the MN<-> LMA of the MN<-> MAG<->CN of the LMA<->CN of the CN. It can be seen that in this scenario, the packet transmission and reception between the MN and the CN must bypass the anchor point LMA of both, and the waste of the message transmission path is more obvious, and the above-mentioned adverse consequences are more serious. In order to solve the above problem, the packet can be forwarded between the two MAGs. However, after the MAG of the MN is switched, the MAG of the CN does not update the local cache in time, and the packet between the MN and the CN cannot be forwarded smoothly. problem. Summary of the invention

The technical problem to be solved by the embodiments of the present invention is to provide a mobility management method and a mobile access gateway, so as to solve the problem that packets cannot be successfully forwarded after the MAG is switched.

To solve the above technical problem, an embodiment of the present invention provides a mobility management method, where the method includes: When the mobile node (MN) switches from the source mobile access gateway (sMAG) to the target mobile access gateway (tMAG), the sMAG or tMAG moves to the mobile access gateway (MAG) of the opposite node (CN) of the MN. Sending a first message, where the first message carries address information that points to the tMAG;

The MAG of the peer node of the MN receives the first message, and updates the local cache according to the first message.

Optionally, before the sending, by the sMAG, the first message, the method further includes: the sMAG receiving the first packet, where the tunnel source IP address of the first packet is directed to the MAG of the CN of the MN Address information, the destination address of the text is the node information of the MN that is cut out; the sMAG sends the first to the MAG of the CN of the MN according to the tunnel source IP address of the first packet Message.

Optionally, before the sending, by the sMAG, the first message, the method further includes:

a local mobility anchor (LMA) or the tMAG sends a second message to the sMAG, where the second message carries node information that points to the MN that is cut out;

The sMAG receives the second message, and queries a local cache according to the node information of the MN to obtain a mapping relationship between the CNs of the MN, where the mapping relationship includes the MN Address information of the MA of the CN;

The sMAG sends the first message to the MAG of the CN of the MN according to the mapping relationship of the CN obtained by the query.

The sMAG requests the local mobility anchor of the MN to obtain address information that points to the tMAG;

Or, the LMA of the MN actively notifies the sMAG to address the address information of the tMAG; or, the tMAG notifies the sMAG of the address information of the tMAG.

Optionally, before the sending, by the tMAG, the first message, the method further includes:

Obtaining, by the tMAG, a mapping relationship of the CN of the MN, where the mapping relationship includes the address information of the MAG that points to the opposite node; The tMAG sends the first message to the MAG of the opposite node according to the obtained mapping relationship of the CN of the MN.

The tMAG acquires a mapping relationship of the peer node of the MN, where the mapping relationship includes address information of the MAG that points to the peer node;

The tMAG receives the second packet, where the tunnel source IP address of the second packet is the address information of the sMAG, and the second >3⁄4 text address is the node information of the MN that is directed to the switch, triggering Transmitting, by the tMAG, the first message according to the mapping relationship of the peer node.

The tMAG receives the third packet, where the outer tunnel source IP address of the third packet is the address information of the sMAG of the MN, and the inner tunnel source IP address is the MAG of the peer node of the MN. Address information; the third >3⁄4 directory address is node information pointing to the cut-in MN;

The tMAG sends the first message to the MAG of the opposite node according to the inner tunnel source IP address of the third packet.

Optionally, the step that the tMAG acquires the mapping relationship of the CN of the MN is: the sMAG acquires address node information that points to the tMAG;

The sMAG queries the local cache, and obtains the mapping relationship of the cut CN of the MN. The sMAG sends the cut mapping relationship of the CN of the MN to the tMAG according to the address information of the tMAG. ;

Or, including:

The tMAG sends a request message to the sMAG, where the node information that points to the MN is carried;

Receiving, by the sMAG, the request message, querying a local cache according to the node information that is directed to the MN, and acquiring a mapping relationship of the CN of the MN that is cut out;

The sMAG returns a response message to the tMAG, where the NDMA carries the peer mapping relationship of the CN of the MN. Optionally, the local cache of the sMAG includes a peer mapping relationship table corresponding to all MNs and a communication peer table corresponding to each MN, and the sMAG queries the corresponding communication peer table according to the node information that points to the MN. Then, the peer mapping relationship table is queried to obtain a mapping relationship between the peer nodes of the MN.

Optionally, the local cache of the sMAG includes one or more peer mapping relationship tables respectively corresponding to one MN, where the sMAG queries the corresponding peer mapping relationship table according to the node information that points to the MN to obtain the MN. The mapping relationship of CN.

Optionally, the first message further carries the node information that is directed to the MN, and when the MAG of the peer node updates the local cache, determining, according to the node information that points to the MN, a local cache to be updated. Corresponding data.

The invention also provides a mobile access gateway (MAG),

When the mobile node (MN) switches from the source mobile access gateway (sMAG) to the target mobile access gateway (tMAG), when the MAG is used as the sMAG or tMAG, the first message sending module is configured to be: The mobile node of the MN (CN) mobile access gateway sends a first message, where the first message carries address information that points to the tMAG;

When the MAG is used as the MAG of the CN of the MN, the first message receiving module and the local cache update module are included.

The first message receiving module is configured to receive the first message sent by the sMAG or tMAG;

The local cache update module is configured to update the local cache based on the first message.

Optionally, the MAG, as the sMAG, further includes a packet receiving module, where the packet receiving module is configured to receive the first packet, where the tunnel source IP address of the first packet is a pointing address The address information of the MAG of the CN of the MN, the destination address of the first packet is the node information of the MN that is cut out; the first message sending module is configured to be according to the first message The tunnel source IP address sends the first message to the MAG of the opposite node of the MN.

Optionally, when the MAG is used as the sMAG, the second message receiving module and the local cache query module are further included, where:

The second message receiving module is configured to receive a local mobility anchor (LMA) or the tMAG Sending a second message, where the second message carries node information that points to the MN that is cut out; the local cache query module is configured to query a local cache according to node information in the second message that points to the MN Obtaining a mapping relationship of the CN of the MN, where the mapping relationship includes address information of a MAG that points to the CN of the MN;

When the second message is sent by the tMAG, the MAG further includes a second message sending module, where the second message sending module is configured to send the second message; The module is configured to send the first message to the MAG of the CN of the MN according to the mapping relationship of the CN acquired by the query.

Module and local cache query module, where:

When the MAG is used as the tMAG, the peer mapping relationship delivery module is configured to actively request or receive the mapping relationship of the CN of the MN that is sent by the sMAG, and when the request is actively requested, the request message carries the pointing location. a node information of the MN, where the MAG is used as the sMAG, the peer mapping relationship delivery module is configured to send the cut mapping relationship of the cut CN of the MN to the tMAG according to the request, where the mapping relationship is Included in the address information of the MAG that points to the CN of the MN;

When the MAG is used as the sMAG, the local cache query module is configured to: query a local cache, and obtain a mapping relationship of the CN of the MN;

When the MAG is used as the tMAG, the first message sending module is configured to send the first message to the MAG of the CN of the MN according to the obtained mapping relationship of the CN of the MN.

Optionally, the MAG, as the tMAG, further includes a packet receiving module, configured to receive a second packet, where a tunnel source IP address of the second packet is address information of the sMAG, where The destination address of the second packet is the node information of the MN that is directed to the MN. When the MAG is the tMAG, the first message sending module is configured to send the identifier according to the trigger of the received second packet. The first message.

Optionally, the MAG, as the tMAG, further includes a packet receiving module, configured to receive a third packet, where an outer tunnel source IP address of the third packet is an address of an sMAG that points to the MN that is switched in. Information, the inner tunnel source IP address is the location of the MAG pointing to the CN of the MN Address information; the third message destination address is the node information of the MN that is directed to the MN; when the MAG is the tMAG, the first message sending module is configured to be based on the received third message. The layer tunnel source IP address sends the first message.

Optionally, the MAG, as the sMAG, further includes a local cache module, configured to cache a peer mapping relationship table corresponding to the MN and a communication peer table of the MN, where the local cache query module is set to first Querying the corresponding communication peer table according to the node information of the MN, and querying the peer mapping relationship table to obtain the mapping relationship of the CN of the MN.

Optionally, the MAG, as the sMAG, further includes a local cache module, configured to cache one or more peer mapping relationship tables respectively corresponding to one MN, where the local cache query module is configured to be directed to the MN. The peer mapping relationship table corresponding to the node information query acquires the mapping relationship of all the CNs of the MN.

Optionally, the first message further carries the node information that is directed to the MN, where the local cache update module is configured to determine local cache corresponding data to be updated according to the node information that points to the MN.

The mobility management method and the mobile access gateway of the embodiment of the present invention, when the mobile node (MN) switches from the source mobile access gateway (sMAG) to the target mobile access gateway (tMAG), the sMAG or tMAG to the MN The mobile access gateway (MAG) of the peer node (CN) sends the address information of the tMAG, so that the MAG of the peer node can obtain the address information of the tMAG in time and update the local cache, so that the pair can be successfully forwarded. The packet sent by the end node to the MN.

BRIEF abstract

1 is a schematic diagram of a logical architecture of a PMIP protocol in the related art;

2 is a schematic diagram of a process of transmitting and receiving IP packets between a MN and a CN in the related art;

FIG. 3 is a schematic diagram of a process of the MN switching MAG in the related art;

4 is a schematic diagram of path analysis using an LMA as an anchor point in the related art;

5 to FIG. 8 are schematic diagrams showing an embodiment of a mobility management method according to the present invention;

FIG. 9 is a schematic diagram showing an example of a peer mapping table;

10a, 10b are schematic diagrams showing an example of a communication peer table; 11 to FIG. 15 are schematic diagrams showing the structure of a module of a MAG according to an embodiment of the present invention. Preferred embodiment of the invention

From the above, the mobility management scheme of the related art causes a waste of the transmission path, which in turn leads to a series of adverse consequences, and the essential reason is that there is an anchor point. All IP packets between the MN and the CN must bypass the MN's anchor network element (or, around the MN and CN anchor network elements). The present invention avoids the series of problems mentioned above by modifying the existing PMIP mechanism.

Compared with the logical architecture of the related technology PMIP protocol (as shown in FIG. 1 ), the modified PMIP protocol architecture includes the mobile node MN, the communication peer CN, the mobile access gateway MAG, and the LMA. The CN may be a fixed node or a mobile node, that is, has a corresponding MAG and LMA.

The MAG is the first hop router of the MN. Its main function is to allocate the care-of address CoA for the MN in the PMIP architecture of the related art, and to perform PMIP binding with the anchor LMA of the MN instead of the MN. : Query locally or to other network elements (eg, LMA) to obtain the MAG (MAG-CN) address of the currently connected CN or the CN's care-of address CoA; MAG (MAG-MN) of the MN and MAG of CN A bidirectional tunnel is established to forward IP packets between the MN and the CN.

The LMA is no longer used as the anchor of the MN. The IP data packets between the MN and the CN are no longer required to pass through the LMA. The LMA needs to save the address of the current MAG-MN and/or the CoA of the MN, and use the MN as an index, for example, the Home Network Prefix (HNP) of the MN's HoA or MN is used as an index for the MN's communication peer. The MAG of the CN or CN is queried according to the relevant information of the MN.

In the embodiment of the present invention, when the MN sends an uplink IP packet to the CN, it is consistent with the existing PMIP mechanism, and the MN needs to first send the IP packet to the MAG-MN of the MN. Subsequent to the existing PMIP mechanism, in the present invention, the MAG-MN needs to query the MAG-CN address of the CN. After querying the address of the MAG-CN (such as the IP address of the MAG-CN), the MAG-MN uses the address of the MAG-CN as the destination to establish a tunnel from the MAG-MN to the MAG-CN (for example, an IP in IP tunnel). while in the above-described IP tunnel packets, sent directly to the MAG-CN ₀ when received MAG-CN tunnel IP packets transmitted to the IP packets transmitted to CN. It should be noted that the MAG-MN can also query the CoA of the CN, and replace the address of the MAG-CN with the CoA address of the CN, and can achieve the same purpose. At this time, the MAG-MN uses the CoA as the end point and establishes the tunnel of the MAG-MN to the MAG-CN, and the effect is equivalent.

It should be noted that when the MAG-MN queries the address of the MAG-CN of the CN (or the CoA of the CN), it can first query in the local cache, and if it is not queried, it can query on other network elements. For example, the LMA (LMA-CN) to CN is queried according to the HoA of CN or the HNP of CN. After querying the desired result, MAG-MN caches the query result locally and uses CN's HoA as an index. The advantage of caching the results of the query locally is that it can avoid frequent logins to other network elements.

By the same token, when the CN sends a downlink IP packet to the MN, the same method as above is used, and the principle is the same, and will not be described again. With the method of the embodiment of the present invention, the path of sending and receiving IP packets between the MN and the CN becomes MN<->MAG-MN<->MAG-CN<->CN, without going through the MN (or MN and CN) Anchoring the LMA network element avoids a series of problems such as waste of the transmission path.

Applying the modified PMIP mechanism, when the MN needs to switch from its sMAG to the target tMAG, the direct use of the existing PMIP switching mechanism will cause the MAG-CN to still send the IP packets sent by the CN to the MN to the sMAG after the handover. Because the MAG address of the MN that is locally cached by the MAG-CN is still sMAG, and the MN is not in the sMAG at this time, the subsequent IP packets sent by the CN to the MN are lost. Therefore, based on the foregoing modification of the PMIP mechanism, the embodiment of the present invention provides a handover management method to solve the above problem, and can ensure that the IP packet transmission and reception between the MN and the CN is not wasted on the transmission path after the MAG is switched. .

It should be noted that the node information pointed to the MN or the CN in the embodiment of the present invention is information indicating which mobile node or the opposite node is, and may be an identifier of the mobile node or the opposite node ( The ID address and the home address may also be the home network prefix, or may be a combination of two pieces of information or three pieces of information. The address information directed to the MAG in the embodiment of the present invention is used to indicate which MAG is a mobile node. The information of the MAG to which the peer node is attached or attached may be the address of the MAG, or may be the proxy care-of address (CoA) assigned by the MAG to the mobile node (MN), the correspondent node (CN), or may be the MAG. A combination of address and CoA. The information of the node pointing to the MN or the CN is specifically represented by what information, and the information indicating the address information of the MAG is specifically determined by the specific application scenario or the information that may be obtained by the corresponding network element. The present invention is not limited to the specific embodiments, and the detailed description is not intended to limit the invention.

Specifically, the sMAG address information refers to the address of the sMAG, the proxy care-of address (CoA) assigned by the MN to the MN, or a combination of the first two pieces of information; the address information of the tMAG refers to the address of the tMAG, and the tMAG is The proxy care-of address (CoA) assigned by the MN or a combination of the first two information; the address information of the MAG of the opposite-end node of the MN refers to the address of the MAG of the opposite node of the MN, and the MAG of the opposite node of the MN is The CN assigned proxy care-of address (CoA) or a combination of the first two pieces of information.

In addition, the LMA allocates a home network prefix (HNP) for the MN or the CN, and after the MN or the CN receives the router advertisement message (the message carries the HNP), the address is configured to obtain the home address HoA originating from the HNP. An HNP can only be assigned to one terminal, that is, both HNP and HoA can uniquely refer to a particular MN. The LMA/MAG may not know the HoA configured by the MN or CN. In specific network applications, it is also possible for the LMA/MAG to obtain the HoA configured by the MN or CN. When the LMA/MAG does not know the HoA, the LMA/MAG saves the mapping between the HNP and the CoA or MAG address, and indexes it with HNP. When the LMA/MAG is aware of the HoA, the LMA/MAG can store the mapping between the HoA and the CoA or MAG address, and the HoA is used as the index. The mapping between the HNP and the CoA or MAG address can also be saved and indexed by HNP.

Embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that, in the case of no conflict, the features in the embodiments and the embodiments in the present application may be arbitrarily combined with each other.

Embodiment 1

FIG. 5 is a first embodiment of the present invention. Embodiment 1 of the mobility management method provides a handover management mechanism, which specifically includes the following steps:

Step 501: In the process of moving the MN, according to the related technology, the process of the MN switching from the sMAG to the tMAG is triggered, for example, when the MN moves from the service area of the sMAG to the service area of the tMAG. At this time, the sMAG needs to obtain the address information of the tMAG (for example, the IP address of the tMAG), or the CoA assigned by the tMAG to the MN (referred to as a new CoA), or obtain the above address and the new CoA at the same time.

Preferably, the sMAG can obtain the address information of the tMAG and the new CoA from the anchor LMA (LMA-MN) or the tMAG of the MN. Steps 502a-502c: The opposite CN of the MN sends an IP packet (referred to as downlink data) to the MN, and the IP packet first arrives at the MAG-CN.

It is assumed that there is already an active session between the MN and the CN (ie, there is data passing between the MN and the CN) before the MN moves across the MAG. At this time, the MAG-CN locally caches the address or sMAG of the MN's sMAG. The CoA address assigned to the MN (called the old CoA). According to the data transmission method described above, the MAG-CN will place the IP packet in the tunnel between the sMAG and the sMAG, and send the IP packet to the sMAG.

Steps 503a-503c: The sMAG parses and determines the received packet. If the IP packet is determined to be from the tunnel between the peer and the peer MAG (referred to as MAG-CN in the embodiment of the present invention), the tunnel source IP address points to the MAG. -CN, and the destination address of the IP packet is the HoA of the MN, and the sMAG determines that the MN is not attached to the link below it (it can be said that the MN is not in its service range), that is, the purpose of the IP packet. The address points to the MN that has been cut out. When the above conditions are met at the same time, the sMAG determines that the local cache of the MAG-CN needs to be updated. The sMAG sends an update address notification message to the MAG-CN, which carries the HoA or HNP or ID of the MN, and the address information of the tMAG and/or the new CoA of the MN. The sMAG learns the address of the MAG-CN according to the tunnel source IP address, that is, which MAG-CN sends the above message (the MN generally has multiple CNs).

After receiving the above message, the MAG-CN determines the local cache corresponding data to be updated according to the HoA or HNP or ID of the MN, and then updates the MAG address of the locally saved MN, or the MN's CoA (or simultaneously updated if Both of these information are saved locally). After the update, in the local cache of the MAG-CN, according to the HoA or HNP or ID of the MN, the current MAG address of the MN (that is, the address of the tMAG) can be queried, or the new CoA of the MN can be queried. The MAG-CN can establish a tunnel between it and the tMAG (for example, an IP-in-IP tunnel) according to the address or the new CoA. The ingress address of the tunnel is the MAG-CN's own address (such as an IP address) or the CN's CoA. The egress address is the address of tMAG or the new CoA of the MN.

After the subsequent CN sends an IP packet to the MN, the MAG-CN will directly send the IP packet to the tMAG of the MN according to the tMAG address or the new CoA in the local cache, and then send the IP4 message by the tMAG. To the MN.

Preferably, the MAG-CN also sends an update address notification acknowledgement message to the sMAG as a response. Step 504: The sMAG turns the IP packet sent by the CN to the MN received in step 502. The packet is sent to the MN, and the packet is sent to the MN to ensure that the IP packet is not lost.

The sMAG can forward the IP packet to the tMAG according to the address of the tMAG obtained in step 501 or the new CoA of the MN. For example, the tunnel to the tMAG (for example, an IP in IP tunnel) is established by using the address of the tMAG or the new CoA of the MN as the egress address, and the IP packet is placed in the tunnel and transmitted to the tMAG.

It should be noted that step 504 can be performed immediately after step 502c, and the execution of step 503 is in no order.

Embodiment 2

As mentioned above, in order to avoid path waste, MAG-MN needs to know the address of MAG-CN.

(or CN's CoA). When the MAG-MN does not have the relevant information, it needs to go to other network elements to query.

In order to avoid frequent queries (there is no need to query the IP packets sent by the MN to the CN once), the embodiment of the present invention also proposes that the MAG-MN needs to cache the address of the MAG-CN or the CoA of the CN to Local, at the same time, the CN's HoA or HNP or ID is used as an index to form a mapping relationship between the peer nodes, such as the HoA or HNP or ID of the CN, mapped to the MAG-CN address or the CN's CoA, which is referred to as the peer mapping relationship. (Correspondent Node Relationship, CNR). It is worth noting that when there are more than one CN of the MN, the MAG-MN needs to locally cache multiple corresponding correspondences, and thus forms a peer mapping relationship table (CNR Table, CNRT), as shown in FIG. A structure for the CNRT.

The table can be used as a global table saved on the MAG, or it can be divided into several local tables corresponding to one MN. The global table, which means that the mapping relationship of all the peer nodes of all MNs attached to the MAG is stored in the same table; the local table, which means that the MAG maintains a table for each MN under it, in the table Only the peer mapping relationship of the MN is recorded. Such a table can be saved in the PMIP binding relationship maintained by the MAG for the MN.

Figure 6 is a second embodiment of the present invention. In the process of MN handover, the sMAG of the MN needs to send the mapping relationship of the stored peer node to the tMAG of the MN, so as to prevent the tMAG from going to other network element query pairs. The mapping relationship includes the following steps: Step 601: During the MN mobility process, when the MN is triggered to switch from the sMAG to the tMAG, the sMAG needs to obtain the address of the MN's tMAG, such as the IP address of the tMAG.

Preferably, as in the method of step 501, the sMAG can obtain address information of the tMAG. Step 602: After obtaining the address information of the tMAG, the sMAG sends a mapping relationship notification message to the tMAG (the address is sent by using the address of the tMAG as the destination address), and carries the mapping relationship of the foregoing peer node, for example, the peer mapping relationship table ( The global table, or the local table, is sent to the tMAG to inform the tMAG of the current peer mapping relationship of the MN, and the tMAG saves the update to the local cache.

At this time, when the tMAG receives the IP packet sent by the MN to the current CN, it can find the required information in the local cache by using the HoA or HNP of the CN (see Figure 9), instead of Other network elements to find.

Step 603: The tMAG sends a mapping relationship notification confirmation message to the sMAG as a response. It is worth noting that the address of the above tMAG can also be replaced by the new CoA of the MN, and the effect is equivalent.

The tMAG can also request the information from the sMAG, as shown in Figure 7, except that the sMAG can actively send the mapping relationship of the MN's peer node to the tMAG. As shown in Figure 7, the following steps are included:

Step 701: During the MN mobility process, when the MN is triggered to switch from the sMAG to the tMAG, the tMAG needs to obtain the address information of the sMAG of the MN, such as the IP address of the sMAG.

Preferably, the tMAG can obtain the address information of the sMAG of the MN from the LMA. For example, when the tMAG performs a PMIP Binding Update (PBU) for the MN to the LMA, the LMA notifies the tMAG of the address of the sMAG by the PBA (PMIP Binding Acknowledgement) sent to the tMAG.

Step 702: The tMAG sends a mapping relationship request message to the sMAG (using the address of the sMAG as the destination address to send the message), carrying the HoA of the MN or the ID of the MN (identity, identity) or the HNP of the MN.

Step 703: Based on the request, the sMAG returns a mapping relationship response message to the tMAG. As described in step 602, the mapping relationship of the peer node of the MN is carried, for example, the peer mapping relationship is sent. Send it to tMAG. After receiving the mapping, tMAG saves the update to the local cache.

Embodiment 3

FIG. 8 is a third embodiment of the present invention, specifically including the following steps:

Step 801: There is an established session between the MN and the CN, and the MN and the CN are received.

A two-way tunnel between the MAG-MN and the MAG-CN is used to forward the above IP packets. The path of the data transmission is expressed as MN<->sMAG<->MAG-CN<->CN.

Step 802: When the MN needs to switch the currently connected MAG, the MN needs to trigger the process of changing the currently connected MAG, and switch from sMAG to tMAG.

Step 803: When the MN moves to the range managed by the tMAG, the MN sends a Router Solicitation message to the tMAG.

Step 804a: The tMAG finds the LM's anchor LMA (ie, LMA-MN) according to the MN's identity (ie, MN-ID), allocates a new CoA to the MN, and sends a proxy binding update (Proxy Binding Update, PBU) to the LMA. The message, the above new CoA is sent to the LMA-MN.

Step 804b: The LMA-MN replaces the old CoA with the new CoA of the MN (the new CoA is the CoA assigned by the tMAG to the MN, the old CoA is the CoA assigned by the sMAG to the MN), and is stored locally by using the HoA or HNP of the MN as an index. At this time, the CoA of the MN can be queried according to the HoA or HNP of the MN, and the CoA is a new CoA allocated by the tMAG to the MN. The LMA returns a Proxy Binding Acknowledgement (PUA) message to the tMAG to inform the tMAG of the HoA or HNP of the MN. The tMAG saves the MN's HoA or HNP and the new CoA locally.

Step 805: The tMAG sends a Router Advertisement message to the MN. Based on this message, you can still use the HoA before the mobile switching MAG as its own IP address, which means that the IP address of the MN does not change before and after the MAG is switched.

Steps 806a-806b: After step 804a, the LMA-MN sends an address notification message to the sMAG, by which the address of the tMAG (eg, the IP address of the tMAG), and/or the new CoA of the MN is sent to the sMAG. It is worth noting that the message also needs to carry the identity of the MN's HoA or HNP or MN (eg, MN-ID) in order for the sMAG to know the MN for which the message is directed. sMAG The above information is cached locally, and an address notification response message is returned to the LMA-MN. Preferably, the message may further carry a handover indication indicating that the current MN is in the state of switching the MAG.

At this time, the sMAG establishes a tunnel from sMAG to tMAG (for example, IP in IP tunnel) by using the address of the above tMAG or the new CoA of the MN. The ingress address of the tunnel is the address of the sMAG or the old CoA of the MN, and the egress address is the address of the tMAG or the new CoA of the MN.

Steps 807a-807b: After acquiring the address of the tMAG or the new CoA of the MN, as described in steps 602-603, the sMAG sends the mapping relationship of the peer node of the MN (for example, in the form of a peer mapping table) to the tMAG. .

Step 808: The CN can continue to send an IP packet to the MN at any time during the entire handover process, and the packet is sent by the MAG-CN to the MN of the MN.

Steps 809a-809c: Based on the received IP packet sent by the CN to the MN, as described in steps 503a-503c, the sMAG sends a message to the MAG-CN, and notifies the MAG of the MN's tMAG address and/or the MN's new CoA. CN. Subsequent IP packets will be sent directly to the MN's tMAG by the MAG-CN.

Preferably, the message also carries the HoA of the MN or the HNP or the ID of the MN to let the MAG-CN know which MN the message is for.

It is worth mentioning that there are two situations discussed here. One is that after the execution of step 806a is completed (or when it is completed), the sMAG receives the above IP packet and processes it according to the above description; the other is Before the execution of the step 806a, the sMAG is the IP packet. Since the sMAG does not know the address of the tMAG (or the new CoA), the sMAG needs to cache the IP packet locally. When the execution of step 806a is completed, it is processed as described above.

It is also worth noting that the sMAG needs to forward the received IP packet sent by the CN to the MN to the tMAG. For example, the sMAG sends it to the tMAG in the tunnel described in step 806, and then further sends it to the MN by the tMAG. To ensure that the IP ^ 艮 text is not lost. Forwarded by MN's tMAG) and MAG-CN, the data forwarding path is MN<->tMAG<->MAG-CN<->CN„ here the address of the tMAG is made to the tunnel between MAG-CN and tMAG (or MN's new CoA. From the perspective of tMAG, in step 807, It obtains the address to the MAG-CN, the CoA of the CN; from the perspective of the MAG-CN, in step 809, it obtains the address to the tMAG, the new CoA of the MN.

In this embodiment, the sMAG learns the address of the tMAG and/or the new CoA of the MN through the active notification of the LMA-MN. In fact, as described in step 601, the sMAG can also actively request relevant information from the LMA-MN. For example, when the MN leaves the sMAG to switch to the tMAG, the sMAG starts a timer locally. When the timer expires, the sMAG sends a request to the LMA-MN to request the address of the tMAG and/or the new CoA of the MN. If the LMA-MN has already obtained the information (for example, the step 804 has been executed), the information is carried in the response message and fed back to the sMAG. Otherwise, the sMAG can restart the timer, and the request message is sent again after the timer expires. Until the LMA-MN notifies the sMAG to abandon the request (for example, when the LMA-MN determines that the MN has retired).

Another way for sMAG to obtain the above information of tMAG is to actively inform sMAG related information by tMAG. In this scenario, tMAG first needs to obtain the address of sMAG. In the method of step 701, in combination with FIG. 8, when the LMA-MN returns a PBU message to the tMAG in step 804b, the message carries the address of the sMAG or the old CoA of the MN. Then (may be executed concurrently with step 805), according to the address of the sMAG or the old CoA information, the tMAG can find the sMAG and send a message to the sMAG to notify the sMAG of its own address (ie, the address of the tMAG) and/or the new CoA of the MN. .

In this embodiment, the mapping relationship between the peer nodes is sent to the tMAG through the method of sMAG active notification. In fact, as described in step 702, the tMAG may also actively request acquisition from the sMAG. Referring to FIG. 8, in step 804b, after the address of the sMAG or the old CoA is obtained by the method tMAG, a message is generated to the sMAG to request the mapping relationship of the peer node of the MN. This step may be performed concurrently with the step 805.

Embodiment 4

In the above embodiment of the present invention, the sMAG sends a message to the MAG-CN based on the received IP packet sent by the CN to the MN to notify the MAG of the address of the MN new MAG (tMAG) and/or the new CoA. -CN. In fact, tMAG can also do this. From the above, in the process of the MN switching the MAG, the sMAG can acquire the address of the tMAG and/or the new CoA of the MN. Based on this information, the sMAG can establish a tunnel from sMAG to tMAG (step 806). Said). Using this tunnel, the sMAG can forward the received IP packets sent by the CN to the MN to tMAG.

As described above, the tMAG can also obtain the mapping relationship between the peer node from the sMAG, and store the correspondence between the HoA or HNP of the CN or the ID and the MAG-CN address or the CoA of the CN (see Figure 9). At this time, the tMAG finds that the tunnel source address of the IP packet (that is, the packet sent by the CN to the MN) is the address of the sMAG or the old CoA of the MN, instead of the IP mapping of the peer mapping relationship table of the MAG-CN. The source address of the text, that is, the HoA query of the CN), so that the tMAG sends a message to the MAG-CN, and notifies the MAG-CN of its own address and/or new CoA, and can also implement the equivalent function. Here, the method in which the sMAG obtains the address of the tMAG and/or the new CoA of the MN and the mapping relationship between the tMAG and the peer node of the MN is the same as that described above, and the details are not described herein.

In fact, when determining whether to notify the MAG-CN's own address and/or new CoA, the tMAG may not rely on obtaining the above-mentioned peer mapping table from the sMAG. In this case, the sMAG needs to perform a special tunnel encapsulation on the IP address that the CN sends to the MN to prompt the tMAG. A special tunnel encapsulation is to encapsulate the packet in two layers: the source address of the IP packet is the HoA of the CN, the destination address is the HoA of the MN, and the source address of the inner tunnel encapsulation is the address of the MAG-CN or the CN. CoA, the destination address is the address of the sMAG or the old CoA of the MN; the source address of the outer tunnel encapsulation is the address of the sMAG or the old CoA of the MN, and the destination address is the address of the tMAG or the new CoA of the MN. After receiving the packet, the tMAG can know that the MAG-CN encapsulates the IP packet and sends it to the sMAG. Then, the MAG-CN can send a message to the MAG-CN according to the address of the MAG-CN or the CoA of the CN to notify the MAG-CN. tMAG's own address or MN's new CoA.

Embodiment 5

As described above, when the sMAG or tMAG receives the IP packet sent by the CN, it determines whether it needs to update the MAG address or CoA stored in the MAG-CN for the MN, and when it is judged that the update is required, to the MAG-CN. Send a notification message. In fact, when the mapping relationship of the peer node of the MN is saved in the form of the above partial table (see the second embodiment), the sMAG or tMAG may also actively send the above update message to the MAG-CN because the local table is It is saved in the binding information of the MN (tMAG or sMAG can find the binding information according to the HoA or HNP or MN-ID of the MN). Referring to FIG. 9, the tMAG or sMAG can accurately learn the current communication peer of the MN according to the local table, and send a message to all involved MAG-CNs according to the MAG address or CoA of the communication peer to update the MAG-CN. Related Information. According to such a principle, the following steps can be appropriately modified by the example flow shown in FIG. 8, specifically including the following steps:

Steps 1001-1005: Steps 801-805.

Steps 1006a-1006b: Referring to steps 806a-806b, the LMA-MN sends a notification message to the sMAG to inform the MN that a handover has occurred. The message preferably carries the MN's ID or HoA or HNP, and the MN's tMAG address or new CoA. Preferably, the sMAG returns a reply message to the LMA-MN in 1006b.

Step 1007: Based on the foregoing notification message, the sMAG starts to query the mapping relationship of all the peer nodes (CNs) of the MN, for example, from the peer mapping relationship table saved for the MN (for example, finding the binding of the MN through the MN-ID) The information is obtained from the binding information. The query is sent to all MAG-CNs to send an update address notification, and the MN's tMAG address or the MN's new CoA is notified to the MAG-CN. Preferably, the MAG-CN returns a response message to the sMAG. The notification process is the same as step 809.

Step 1008: Same as step 807. Of course, step 1007 and step 1008 can be performed concurrently. Step 1009: Same as step 810.

As can be seen from the above process, after receiving the signaling of the LMA-MN (step 1006), the sMAG starts the process of notifying the MAG-CN related information without relying on the CN to send an IP message to the MN. Of course, the tMAG can also notify the sMAG to perform the process. For example, after receiving the message of 1004b (804b), the tMAG sends a trigger message to the sMAG, which carries the parameter described in step 1006, and can also trigger the sMAG to start performing the notification MAG. - The process of CN related information. In addition, it should be noted that the tMAG may also perform a process of notifying the MAG-CN related information according to the mapping relationship of the peer node of the MN. After the tMAG obtains the mapping relationship between the foregoing peer nodes from the sMAG, the process of notifying the MAG-CN related information may be performed as described above. The tMAG obtains the peer mapping relationship table from the sMAG as described above (the second embodiment), and details are not described herein again.

Embodiment 6

When the MAG uses the global table to save the peer mapping table of the MN, in order to enable the tMAG or sMAG to send an update message to the MAG-CN to update the MAG-CN, as described in Embodiment 5, in the handover scenario. The saved MAG address or CoA for the MN, preferably the MAG also holds a Correspondence Node Table (CNT) for the MN, and FIG. 10 shows two examples of the communication peer table.

If the communication peer table in the form of Figure 10a is used, the MAG needs to maintain one such table for each MN attached to it, and save it in the binding information of the MN, through the HoA or HNP of the MN or The ID can find the table and can know the HoA or ID of the communication peer CN of the MN in the table.

If the communication peer table in the form of Figure 10b is used, the MAG can maintain only one table for all MNs attached to it, and fill all the MN's peer information into this table, and use MN's HoA or HNP or ID as an index. In this table, the HoA or ID of the communication peer CN of the designated MN can also be known.

Depending on the communication peer table, the sMAG can perform the process of notifying the MAG-CN related information when receiving the signaling of the LMA-MN or the trigger of the tMAG, and notifying the MN's tMAG address or the new CoA to the relevant The MAG of the CN (ie MAG-CN) is as follows: First, all the CNs of the MN are obtained in the communication peer table, and then the corresponding MAG-CN address or the CN of the CN is queried according to the CN in the peer mapping table. Finally, the MAG-CN related information is notified according to the MAG-CN address or the CN's CoA.

sMAG can also first send the communication peer table to tMAG first (when using the form of Figure 10b, The sMAG may send the part of the communication peer table associated with the specified MN to tMAG), and then trigger the tMAG to perform the process of notifying the MAG-CN related information. The sMAG can also forward the communication peer table to the tMAG by using the method in which the sMAG passes the peer mapping table to the tMAG in the step 602-603 (702-703) of the second embodiment. After the sMAG obtains the table, the same process as the above method may also be used to notify the MAG-CN related information, and notify the MAG of the relevant CN (ie, MAG-CN) of the MN's tMAG address or new CoA.

In fact, as a variant, the table shown in FIG. 9 and the table shown in FIG. 10 can be combined into one table, for example, with the HoA or HNP or ID of the MN as an index, and the HoA, ID of the CN of the MN, The address of the MAA to which the CoA and CN are connected is a value. Then, in this combined table, all CNs of the MN can be queried according to the MN, and the address of the MAG to which the CN is currently connected and/or the CoA of the CN. In summary, with proper table structure design, sMAG and tMAG can always find the mapping relationship of the peer nodes of the specified MN.

Corresponding to the foregoing method embodiment, the embodiment of the present invention further provides a mobile access gateway (MAG), and the embodiment 1 of the MAG is as shown in FIG.

a first message sending module, when the mobile node (MN) switches from the source mobile access gateway (sMAG) to the target mobile access gateway (tMAG), when the sMAG or tMAG is used as the opposite node of the MN (CN) the mobile access gateway sends a first message, where the address information that points to the tMAG is carried;

The first message receiving module, when the MAG is the peer node of the MN, is configured to receive the first message sent by the sMAG or the tMAG;

The local cache update module, when acting as the MAG of the peer node of the MN, updates the local cache according to the first message.

The embodiment 2 of the MAG is as shown in FIG. 12, which is different from the embodiment 1 shown in FIG. 11. The MAG further includes a message receiving module, where the message receiving module is configured to receive when it is used as an sMAG. a first packet, where the tunnel source IP address of the first packet is the address information of the MAG that points to the peer node of the MN, and the destination address of the text is the node information of the MN that is cut out; The first message sending module sends the first message to the MAG of the peer node of the MN according to the tunnel source IP address of the first packet. The embodiment 3 of the MAG is as shown in FIG. 13. Different from the embodiment 1 shown in FIG. 11, the MAG further includes a second message receiving module and a local cache query module, as the sMAG:

The second message receiving module is configured to receive a local mobility anchor (LMA) or a second message sent by the tMAG, where the node information that points to the cut out MN is carried;

The local cache query module is configured to query a local cache according to the node information of the MN in the second message, and obtain a mapping relationship between the peer node (CN) of the MN, where the mapping relationship includes Address information of the MAG of the peer node of the MN;

When the second message is sent by the tMAG, the MAG further includes a second message sending module, and when the tMAG is used, the second message is set to be sent;

The first message sending module is configured to send the first message to the MAG of the peer node of the MN according to the mapping relationship of the peer node acquired by the query.

The embodiment of the MAG is as shown in FIG. 14. In contrast to the embodiment 1 shown in FIG. 11, the MAG further includes a peer mapping relationship delivery module and a local cache query module, where:

The peer mapping relationship delivery module, as the tMAG, is configured to actively request or receive the mapping relationship of the inbound node of the MN that is sent by the sMAG, and when the request is actively requested, the request message carries the pointer to the MN. Node information; as the sMAG, the mapping relationship of the peer node of the MN that is sent to the tMAG is sent to the tMAG, and the mapping relationship includes the MAG that points to the peer node of the MN. Address information;

The local cache query module is configured to query a local cache to obtain a mapping relationship between the peer node (CN) of the MN when the sMAG is used as the sMAG.

The first message sending module sends the first message to the MAG of the peer node of the MN according to the obtained mapping relationship of the peer node of the MN.

The embodiment 5 of the MAG is as shown in FIG. 15 , and is different from the embodiment 4 shown in FIG. 14 , the MAG further includes a message receiving module, and when the tMAG is used, the second message is received, The tunnel source IP address of the second >3⁄4 text is address information pointing to the sMAG, the destination address of the second >3⁄4 text is node information pointing to the MN that is cut in; and when tMAG is used, the first message is sent The module sends the first message according to the trigger of the received second packet.

Embodiment 6 of the MAG is different from Embodiment 2 shown in FIG. 12 in that the four-dimensional receiving mode The block, as the tMAG, is configured to receive the third packet, where the outer tunnel source IP address of the third packet is the address information of the sMAG of the MN that is cut in, and the inner tunnel source IP address is The address information of the MAG of the peer node of the MN; the destination address of the third packet is the node information of the MN that is directed to the MN; and the first message sending module, according to the received third packet, The inner tunnel source IP address sends the first message.

The embodiment of the MAG of the present invention is different from the third embodiment of the present invention. The MAG further includes a local cache module, configured to cache a peer mapping table corresponding to the MN and a communication peer table of the MN. The local cache query module first queries the corresponding communication peer table according to the node information of the MN, and then queries the peer mapping relationship table to obtain a mapping relationship between the peer node (CN) of the MN.

The embodiment of the MAG of the present invention is different from the embodiment 3 or 4. The MAG further includes a local cache module, configured to cache a plurality of peer mapping relationship tables respectively corresponding to one MN, the local cache. The query module obtains a mapping relationship between all the peer nodes (CN) of the MN by querying the corresponding peer mapping relationship table according to the node information of the MN.

Preferably, the first message further carries the node information that is directed to the MN, and the local cache update module is configured to determine local cache corresponding data to be updated according to the node information that points to the MN.

As described above, the node information of the MN includes an identifier (ID) of the MN, a home address (HoA), or a home network prefix (HNP); the pointing sMAG address information includes an address of the sMAG or an sMAG is the MN The assigned proxy care-of address (CoA); the address pointing to the tMAG, the address information of the MAG pointing to the opposite node of the MN, including the address of the MAG of the opposite node of the MN, or the peer node of the MN The proxy care-of address (CoA) assigned by the MAG to the CN. One of ordinary skill in the art will appreciate that all or a portion of the above steps may be performed by a program to instruct the associated hardware, such as a read only memory, a magnetic disk, or an optical disk. Optionally, all or part of the steps of the foregoing embodiments may also use one or Multiple integrated circuits are implemented. Correspondingly, each module in the foregoing embodiment may be implemented in the form of hardware, or may be implemented in the form of a software function module. The invention is not limited to any specific form of combination of hardware and software.

Industrial applicability

The mobility management method and the mobile access gateway of the embodiment of the present invention, when the mobile node (MN) switches from the source mobile access gateway (sMAG) to the target mobile access gateway (tMAG), the sMAG or tMAG to the MN The mobile access gateway (MAG) of the peer node (CN) sends the address information of the tMAG, so that the MAG of the peer node can obtain the address information of the tMAG and update the local cache in time, thereby smoothly forwarding the peer end. The packet sent by the node to the MN.

Claims

Claim

1. A mobility management method, the method comprising:

When the mobile node (MN) switches from the source mobile access gateway (sMAG) to the target mobile access gateway (tMAG), the sMAG or tMAG moves to the mobile access gateway (MAG) of the opposite node (CN) of the MN. Sending a first message, where the first message carries address information that points to the tMAG;

2. The method according to claim 1, wherein: before the sMAG sends the first message, the method further includes: the sMAG receiving the first packet, where the tunnel source IP address of the first packet is Address information of the MAG of the CN of the MN, the destination address of the first packet is the node information of the MN that is cut out; the sMAG is based on the tunnel source IP address of the first packet The MAG of the CN of the MN sends the first message.

3. The method according to claim 1, wherein: before the sMAG sends the first message, the method further includes:

The method of claim 1, wherein: before the sMAG sends the first message, the method further includes:

The sMAG requests the local mobility anchor of the MN to obtain address information that points to the tMAG; Or, the LMA of the MN actively notifies the sMAG to address the address information of the tMAG; or, the tMAG notifies the sMAG to address the address information of the tMAG.

The method of claim 1, wherein: before the tMAG sends the first message, the method further includes:

Obtaining, by the tMAG, the mapping relationship of the CN of the MN, where the mapping relationship includes the address information of the MAG that points to the opposite node;

The tMAG sends the first message to the MAG of the opposite node according to the obtained mapping relationship of the CN of the MN.

8. The method according to claim 5 or 6, wherein: the step of the tMAG acquiring the mapping relationship of the CN of the MN that is cut in comprises:

The sMAG acquires address node information that points to the tMAG; The sMAG queries the local cache, and obtains the mapping relationship of the cut CN of the MN. The sMAG sends the cut mapping relationship of the CN of the MN to the tMAG according to the address information of the tMAG. ;

Or, including:

The sMAG returns a response message to the tMAG, where the CN mapping of the CN of the MN is carried.

The method according to claim 3 or 8, wherein: the local cache of the sMAG includes a peer mapping relationship table corresponding to all MNs and a communication peer table corresponding to each MN, where the sMAG is directed to The node information of the MN queries the corresponding communication peer table to query the peer mapping relationship table to obtain the mapping relationship of the peer node of the MN.

The method according to claim 3 or 8, wherein: the local cache of the sMAG includes one or more peer mapping relationship tables respectively corresponding to one MN, and the sMAG queries according to node information directed to the MN. The peer mapping relationship table acquires the mapping relationship of the CN of the MN.

The method according to claim 1, wherein: the first message further carries the node information that is directed to the MN, and when the MAG of the opposite node updates the local cache, according to the pointing to the MN The node information determines the local cache corresponding data to be updated.

12. A mobile access gateway (MAG),

When the MAG is used as the MAG of the CN of the MN, the first message receiving module and the local cache update module are included. The first message receiving module is configured to receive the first message sent by the sMAG or tMAG;

The MAG of claim 12, wherein the MAG, as the sMAG, further includes a message receiving module, where

The packet receiving module is configured to receive the first packet, where the tunnel source IP address of the first packet is the address information of the MAG of the CN that is directed to the MN, and the destination address of the first packet is The node information of the MN is sent out; the first message sending module is configured to send the first message to the MAG of the opposite node of the MN according to the tunnel source IP address of the first source.

The MAG of claim 12, wherein the MAG, as the sMAG, further includes a second message receiving module and a local cache query module, where:

The second message receiving module is configured to receive a local mobility anchor (LMA) or a second message sent by the tMAG, where the second message carries node information that points to the MN that is cut out; the local cache The querying module is configured to query the local cache according to the node information of the MN in the second message, and obtain the mapping relationship of the CN of the MN, where the mapping relationship includes the address information of the MAG of the CN that points to the MN. ;

The MAG according to claim 12, wherein the MAG, as the tMAG or the SMG, further includes a peer mapping relationship delivery module and a local cache query module, where:

When the MAG is used as the tMAG, the peer mapping relationship delivery module is configured to actively request or receive the mapping relationship of the CN of the MN that is sent by the sMAG, and when the request is actively requested, the request message carries the pointing location. a node information of the MN, where the MAG is used as the sMAG, the peer mapping relationship delivery module is configured to send the cut mapping relationship of the cut CN of the MN to the tMAG according to the request, where the mapping relationship is Included in the address information of the MAG that points to the CN of the MN; When the MAG is used as the sMAG, the local cache query module is configured to: query a local cache, and obtain a mapping relationship of the CN of the MN;

The MAG according to claim 15, wherein the MAG, as the tMAG, further includes a message receiving module, configured to receive a second packet, where a tunnel source IP address of the second packet is a pointing address The address information of the sMAG, the destination address of the second message is the node information of the MN that is directed to the MN; and when the MAG is the tMAG, the first message sending module is configured to receive the The triggering of the second message sends the first message.

The MAG according to claim 12, wherein the MAG, as the tMAG, further includes a message receiving module, configured to receive a third packet, where an outer tunnel source IP address of the third packet is directed Address information of the sMAG of the MN, the inner tunnel source IP address is the address information of the MAG of the CN that points to the MN; the third packet destination address is the node information that points to the MN that is handed in; The first message sending module is configured to send the first message according to the received inner tunnel source IP address of the received third message.

The MAG according to claim 14 or 15, wherein the MAG further includes a local cache module, which is configured to cache a peer mapping relationship table corresponding to the MN and a communication peer table of the MN, where the MAG is configured as an sMAG, The local cache query module is configured to first query the corresponding communication peer table according to the node information that points to the MN, and then query the peer mapping relationship table to obtain the mapping relationship of the CN of the MN.

The MAG according to claim 14 or 15, wherein the MAG, as the sMAG, further includes a local cache module, configured to cache one or more peer mapping relationship tables respectively corresponding to one MN, and the local cache query module The mapping relationship is set to acquire all the CNs of the MN according to the peer mapping relationship table corresponding to the node information querying the MN.

The MAG according to claim 12, wherein: the first message further carries the node information that points to the MN, and the local cache update module is configured to: according to the node information that points to the MN Determine the local cache corresponding data to be updated.