WO2012059010A1

WO2012059010A1 - Hap handoff method and system

Info

Publication number: WO2012059010A1
Application number: PCT/CN2011/081275
Authority: WO
Inventors: 沈炯; 汪军; 高扬
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-11-02
Filing date: 2011-10-25
Publication date: 2012-05-10
Also published as: CN102457510A; CN102457510B

Abstract

Disclosed in the present invention are a Host Identity Protocol Access Point (HAP) handoff method and system. The method includes: after the IP address of a Host Identity Protocol (HIP) device changes, the HIP device decides whether to perform a HAP handoff according to obtained HAP information wherein the packet Round Trip Time (RTT) is shorter, or the original HAP of the HIP device decides whether the HIP device should perform the HAP handoff according to obtained HAP information wherein the RTT between the HIP device and the HAP is shorter; when deciding to perform the HAP handoff, the HIP device establishes an association with a new HAP and closes the association with the original HAP; and the original HAP forwards the data sent to the HIP to the new HAP. The present invention solves the problem of long interaction delays between a UE and a HIP device, which are caused by the change from short to long of the RTT between the UE and the HAP after the UE moves.

Description

Method and system for HAP handover

The present invention relates to the field of telecommunications, and in particular to a method and system for handover of a Host Identity Protocol (HIP) device access point (HAP). Background technique

At present, there are two main types of Internet (Internet) namespaces: Internet Protocol (IP) addresses and domain name systems. The IP address serves both as an addressing function and as a host for identifying the communication device. This dual function determines that when the IP address changes, not only the route changes, but also the identity of the host of the communication device changes. Changes to the route are acceptable, but changes to the device identity can cause application and connection disruptions. The introduction of HIP solves the binding of device identification and address. HIP requires that any device has a unique host identifier (HI, Host Identifier) on a global scale, and defines a host identity tag (HIT, Host Identity Tag), 128-bit. ORCHID is a hash of HI. The advantage of using HIT in the protocol is that the program can use a fixed length interface and facilitate the unification with the 128-bit IPV6 address. The HIP protocol has different restrictions on the communication layer protocol of TCP/IP. In the TCP/IP protocol, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) are linked to the IP address, and once the HIP architecture is established, these connections are the same as the host. ID, not the IP address is linked. HIP is able to do this because it changes the binding between the network layer and the transport layer in the TCP/IP protocol, and introduces the HIP layer between TCP and IP. In the HIP architecture, the IP address still has the function of location identification, but HI replaces the function of the device identifier of the IP address. This makes it possible to have a unique identity regardless of how a host's IP address changes, thus solving the host's mobility problems and multi-hole problems. See Figure 1 for the HIP network hierarchy. The HIP protocol has its own header on the IP header. The meaning of each field is as follows:

The Next Header field is used to describe the location of the additional header. It is not currently used. A fixed decimal of 59 is used to indicate that there is no Next Header.

Header Length field Description The length of the HIP header, counted as an integer multiple of 8 bytes, excluding the first 8-byte header;

Packet Type field description Type of HIP packet;

VER. field description The version number of the HIP protocol;

The RES. field is reserved for future applications and is not currently used;

The Checksum field is the checksum of the HIP header;

The Controls field is a field describing the structure of the package and the capabilities of the host. Currently, only the way in which the host sends it by anonymous name is defined.

The Sender's Host Identity Tag (HIT) field describes the sender's HIT, 128-bit ORCHID;

The Receiver's Host Identity Tag (HIT) field describes the recipient's HIT, 128-bit ORCHID;

The HIP Parameters field describes the HIP parameters carried by the HIP packet.

The HIP basic interaction process is shown in Figure 2. The HIP basic interaction is an interaction process between basic information between two hosts, and is used to exchange basic information of communication between two hosts. The HIP basic interaction process has four packet interactions, and the parameters required to interact with the DH key algorithm in the second and third packets are used to negotiate a shared key between the two hosts; through the second and third The public key, signature and HIT carried in the package respectively authenticate the identity of the other party. After the interaction of the four packages is completed, an end-to-end secure connection is established. The host that initiates the HIP interaction package in the network is the initiator, and the host that the initiator wants to interact with is the responder. When the basic interaction process of the four packages ends, the difference does not exist, and any party that interacts in the subsequent communication. It may become the initiator to inform the other party of the change in status. In the first package II initiated by the initiator, only the initiator's host identification tag (HIT-I) and Responder's host identification tag (HIT-R). The actual information interaction process begins in the second packet R1 sent by the responder. In the second package R1 contains the secret challenge to the initiator (used to reduce the threat of denial of service attacks), the initiator must respond to this challenge before the interaction can continue. In the third packet 12 sent by the initiator, the initiator's response to the secret challenge in the R1 packet is included. The fourth packet R2 sent by the responder contains the signature of the responder, and ends the HIP basic interaction process of the four packets.

After the IP address of the device using the HIP is changed, it is necessary to notify the peer to which it is connected, and use the three-way handshake mode of the HIP Update message, as shown in Figure 3. The parameter LOCATOR contains the host's new IP address (IPv6 address or IPv4-in-IPv6 format IPv4 address), ESP INFO contains the security association (SA) information, and SEQ and ACK are used to confirm that the Update packet is received at both ends.

ORCHID (Overlay Routable Cryptographic Hash Identifiers) is a special IPV6 address that cannot be used as a normal routable IPV6 address. Distinguish from normal IPV6 addresses by using a special 28-bit tag on the head. Its composition is as follows: 28-bit first 2001: 10::/28, plus a 100-bit binary string. The HIT in the HIP uses the ORCHID.

Since the HIP is based on an end-to-end connection, each HIP device requires four handshakes to associate with a new HIP device, increasing device overhead, and when the packet is back and forth between one HIP device and another HIP device (RTT) , Round Trip Time ), when the connection is established for a long time, the connection delay is long, which affects the user experience. At the same time, if a HIP device is connected to multiple HIP devices, the change of the IP address needs to notify all connected devices, and the delay is also long, which affects the user experience.

Therefore, the HIP infrastructure is introduced, as shown in Figure 4, where:

401: The User Equipment (UE, User Equipment) supports the HIP protocol and is a HIP device.

402: The HIP Access Point (HAP) is a HIP access node of the infrastructure, and provides HIP access and data forwarding of the UE. The UE establishes a HIP association with the HTP with a smaller RTT, and the data packets sent and received by the UE are forwarded by the HAP. The UE only needs to establish a HIP association with the HAP without establishing a HIP association with the new HIP device each time.

However, when the UE moves, the earlier HAP (that is, the smaller the RTT between the UE and the HAP) may become farther (the RTT changes from small to large), resulting in a longer delay between the UE and the HIP device. , the user's physical risk is getting worse. Summary of the invention

In view of this, the main purpose of the present invention is to provide a method and system for HAP handover, which can solve the delay of interaction between the UE and the HIP device caused by the RTT between the UE and the HAP after the UE moves. Long question.

In order to achieve the above object, the technical solution of the present invention is achieved as follows:

The present invention provides a method for Host Identity Protocol Device Access Point (HAP) handover, the method comprising:

After the IP address of the HIP device is changed, the HIP device determines whether to switch the HAP according to the obtained HAP information with a smaller packet round-trip time (RTT), or the original HAP of the HIP device is obtained according to the obtained The HTP information of the RTT between the HIP devices determines whether the HIP device performs HAP switching.

When the HAP handover is determined, the HIP device establishes a HIP association with the new HAP and closes the association with the original HAP; and the original HAP forwards the data sent to the HIP device to the new HAP.

The method further includes:

When the HIP device establishes a HIP association with the new HAP, the new HAP checks whether the binding relationship between the HIP device and the original HAP is cached, and if yes, deletes the binding relationship; and the new HAP storage Binding relationship between the HIP device and its new IP address.

The method further includes: After the HIP device establishes a HIP association with the new HAP, the HIP device sends a handover notification to the original HAP, including new HAP information;

The original HAP changes the binding relationship between the HIT and the IP address of the HIP device stored in the original HAP to the binding relationship between the HIT of the HIP device and the new HAP.

The original HAP forwards the data sent to the HIP device to the new HAP, specifically: after the original HAP receives the data sent by the opposite end of the HIP device to the HIP device, according to the stored HIP device Binding relationship between the HIT and the new HAP, forwarding data to the new HAP, and carrying the peer HAP information in the forwarded data;

The new HAP forwards data to the HIP device according to the binding relationship between the HIT of the HIP device and the new IP address.

The method further includes:

The new HAP notifies the peer HAP that the HIP device has switched to the new HAP according to the peer HAP information;

The peer HAP replaces the binding relationship between the HIP device and the original HAP that is stored by the peer HAP with the binding relationship between the HIP device and the new HAP, and returns a response to the new HAP.

The new HAP records the update success status of the peer HAP, where the HIP device and the peer HAP information are included.

The method further includes: the handover notification sent by the HIP device to the original HAP, further comprising: an HIT list of the peer HIP device that is communicating with the HIP device;

Correspondingly, the original HAP obtains the peer HAP information corresponding to the HIT in the HIT list, and notifies the peer HAP that the HIP device has switched to the new HAP;

The new HAP records the update success status of the peer HAP, where the HIP device and the peer HAP information are included. The present invention also provides a system for HAP switching, the system comprising: a HIP device, and an original HAP and a new HAP of the HIP device;

After the IP address of the HIP device is changed, the HIP device is configured to determine whether to switch the HAP according to the obtained HAP information with a smaller RTT, or the original HAP is compared according to the obtained RTT between the HIP device and the HIP device. '', the HAP information determines whether the HIP device performs HAP handover;

The HIP device is further configured to: when performing a HAP handover, establish a HIP association with the new HAP, and close the association with the original HAP;

The original HAP is further configured to forward the data sent to the HIP device to the new HAP, where the new HAP is used to send the data forwarded by the original HAP to the HIP device. The new HAP is further configured to: when establishing a HIP association with the HIP device, check whether the binding relationship between the HIP device and the original HAP is cached, and if yes, delete the binding relationship; The new HAP stores the binding relationship between the HIP device and its new IP address.

The HIP device is further configured to: after establishing a HIP association with the new HAP, send a handover notification to the original HAP, where the new HAP information is included;

Correspondingly, the original HAP is further configured to change the binding relationship between the HIT and the IP address of the HIP device that is stored by the original HAP to the binding relationship between the HIT of the HIP device and the new HAP.

The original HAP is further configured to: after receiving the data sent by the peer end of the HIP device to the HIP device, according to the stored binding relationship between the HIT of the HIP device and the new HAP, to the new HAP Forwarding data, and carrying the peer HAP information in the forwarded data;

Correspondingly, the new HAP is further configured to forward data to the HIP device according to the binding relationship between the HIT of the HIP device and the new IP address saved by the HIP device.

The new HAP is further configured to notify the peer HAP that the HIP device is switched to the new HAP according to the peer HAP information;

Receiving the binding relationship between the HIP device stored by the peer HAP and the original HAP And a response that is returned after the binding relationship between the HIP device and the new HAP is replaced. The update success status of the peer HAP is recorded, where the HIP device and the peer HAP information are included.

The handover notification sent by the HIP device to the original HAP further includes: an HIT list of the peer HIP device that is communicating with the HIP device;

Correspondingly, the original HAP is further configured to: obtain the peer HAP information corresponding to the HIT in the HIT list, and notify the peer HAP that the HIP device is switched to the new HAP;

Receiving, by the peer HAP, the binding relationship between the HIP device and the original HAP that is stored by the peer HAP is replaced by the response returned by the HIP device and the new HAP; and the update success status of the peer HAP is recorded. The HIP device and the peer HAP information are included.

The method and system for HAP handover provided by the present invention, when the HIP device moves to cause the connection with the HAP to be not optimal (that is, the RTT between the HIP device and the HAP is large), and the HIP device is enabled by HAP switching. A better HAP (which means that the RTT between the HAP and the HIP device is smaller) establishes a HIP association, and the better HAP forwards and receives data, thereby reducing data transmission and reception delay and improving the user experience. DRAWINGS

1 is a schematic diagram of a hierarchical structure of a HIP network in the prior art;

FIG. 1 is a flow chart of a basic HIP interaction in the prior art;

3 is a flowchart of a three-way handshake mode with a peer end after the IP address of the device of the HIP is changed in the prior art;

4 is a schematic diagram of a HIP infrastructure in the prior art;

FIG. 5 is a schematic diagram of HAP handover in an embodiment of the present invention;

6 is a schematic structural diagram of a DHT overlay network according to an embodiment of the present invention;

7 is a flowchart of a HAP switching method according to Embodiment 1 of the present invention;

FIG. 8 is a flowchart of a method for switching a HAP according to Embodiment 2 of the present invention;

FIG. 9 is a flowchart of a method for switching a HAP according to Embodiment 3 of the present invention; FIG. 10 is a flowchart of a method for switching a HAP according to Embodiment 4 of the present invention. detailed description

The technical solutions of the present invention are further elaborated below in conjunction with the accompanying drawings and specific embodiments. The technical solution of the present invention is to make the UE and the better when the UE moves so that the connection with the HAP is not optimal (that is, the RTT between the UE and the HAP is large;) The HAP (refers to the smaller RTT between the HAP and the UE) establishes a HIP association, and forwards and receives data through the better HAP, thereby reducing data transmission and reception delay and improving user experience. Both the UE and the HAP described in the present invention belong to the HIP device.

The core of the technical solution of the present invention is:

The HIP device (including the HIP device that accesses the HAP, such as the UE) is first registered on the infrastructure, and the HAP that is closer (that is, the RTT is smaller) is selected for HIP association.

The HAP stores the association between the HIT and the IP address of the UE, and forwards the data sent by the HIP device and sent to the HIP device. After the IP address of the HIP device is changed, the server is contacted to obtain information to determine whether to switch the HAP, or whether the original HAP informs the HIP device whether the HIP device is Switch

The HIP device establishes a HIP association with the new HAP and closes the HIP association with the original HAP. The original HAP forwards the data addressed to the HIP device to the new HAP.

Taking the HIP device as the UE as an example, as shown in FIG. 6, an overlay network composed of a super node (SN, Super Node) is used to store a binding relationship between the HIT and the HAP of the UE. SN is a number of homogenized nodes, which form a distributed hash table (DHT, Distributed Hash Table) overlay network, and store the binding relationship between the HIT and HAP of the UE. The HAP stores and acquires the storage and acquisition interfaces specified by the overlay network. Binding relationship between the HIT and HAP of the HIP device. among them:

The SN ( 601 ), the HAP connected by the UE, is connected to the SN node to store and acquire the binding relationship between the HIT of the UE and the HAP.

The UE is responsible for the SN ( 602 ), and is determined according to the overlay network rule and the HIT of the UE, and is responsible for storing the binding relationship between the UE and the UI connected to the UE. Other SN nodes can be superimposed The network rule and the HIT of the UE, the UE is responsible for acquiring the binding relationship between the HIT and the HAP of the UE in the SN.

The technical solution of the present invention will be described below by way of specific embodiments. The embodiments described below all use the overlay network composed of SN shown in FIG. 6 to store the binding relationship between the HIT and the HAP of the UE.

As shown in FIG. 7, the method for HAP handover according to the first embodiment of the present invention, in which the UE actively obtains a better HAP, includes the following steps:

Step 701: The UE obtains the address of the HRT with a smaller RTT by querying the domain name system (DNS, Domain Name System), the statically configured server, or the IPv6 dynamic host configuration protocol (DHCPv6). The HAP (referred to as the original HAP) establishes a HIP association. The original HAP stores the binding relationship between the HIT of the UE and the original HAP, and stores the binding relationship between the HIT of the UE and the original HAP in the peer-to-peer overlay network formed by the SN node.

Step 702: The IP address of the UE changes.

Step 703: The UE notifies the original HAP by using a HIP Update (Update) message, and the original HAP responds to the HIP Update message, and records the change of the IP address of the UE.

Step 704: The UE obtains the HAP address with a smaller RTT after the IP address is changed by querying the DNS, the statically configured server, or the DHCPv6. The UE determines whether the HAP switchover needs to be performed, that is, whether the original HAP is switched to the new HAP.

Step 705: If the handover is needed, the UE establishes a HIP association with the new HAP. The UE will use this connection to send data later. The new HAP checks whether the binding relationship between the HIT of the UE and the original HAP is cached. If yes, the binding relationship is deleted. At the same time, the new HAP stores the binding relationship between the HIT of the UE and the new IP address.

Step 706: The new HAP sends a request for storing the binding relationship between the HIT of the UE and the new HAP to the SN, that is, the new SN, and the new SN stores the binding relationship between the HIT of the UE and the new HAP. Step 707: The new SN sends a request for storing the binding relationship between the HIT of the UE and the new HAP to the data home SN (referred to as the home SN) of the UE according to the routing rule of the overlay network, and the home SN stores the binding relationship between the HIT of the UE and the new HAP. .

Step 708: The UE sends a handover notification to the original HAP, where the address and the identifier of the new HAP are included, and the HIP association with the original HAP is closed. The original HAP changes the binding relationship between the HIT and the IP address of the UE that is stored in the UE to the binding relationship between the HIT of the UE and the new HAP (address and identity), and the binding relationship between the HIT of the UE and the new HAP can be used as the identifier. To clarify the forwarding attributes of the original HAP.

While changing the binding relationship, the original HAP may set a forwarding timer, which is used to stop forwarding data to the UE after the forwarding timer expires. The duration of the forwarding timer should be slightly larger than the HIT of the original HAP cache UE and the new HAP. The timer duration of the binding relationship.

Step 709: The original HAP sends a request to delete the binding relationship between the HIT of the UE and the original HAP to the original SN, and the original SN deletes the binding relationship between the HIT of the UE and the original HAP.

Step 710: The original SN sends a request to delete the binding relationship between the HIT of the UE and the original HAP to the home SN according to the routing rule of the overlay network, and the home SN deletes the binding relationship between the HIT of the UE and the original HAP.

In step 711, the peer HAP (that is, the HAP that still sends data to the UE, these HAPs have not yet learned that the UE has switched to the new HAP) still sends data to the original HAP to the UE.

Step 712: After receiving the data, the original HAP forwards the data to the new HAP according to the binding relationship between the stored HIT and the new HAP, and adds the parameter SOURCE_HAP to the HIP header to fill in the identifier of the peer HAP.

Step 713: The new HAP forwards the data to the UE according to the binding relationship between the HIT of the UE and the new IP address, and the new HAP can remove the parameter SOURCE_HAP in the HIP header when forwarding the data to the UE.

If during this time (ie, the forwarding timer set by the original HAP in step 708 expires) The UE is switched to the HAP again (that is, the new HAP is switched to another HAP), and the new HAP searches for the binding relationship between the HIT of the UE and the HAP (that is, other HAPs that are switched from the new HAP). In this case, the new HAP forwards the data to the HAP bound HAP of the UE, and then step 714 is omitted subsequently.

The new HAP can cache the binding relationship between the peer HAP and the HIT of the peer UE, and set a cache timer. When the set cache timer expires, the new HAP deletes the binding of the cached peer HAP to the peer UE's HIT. relationship. The cache timer is set here to prevent the cache relationship from being invalid. For example, the new HAP caches the binding relationship between the peer HAP and the HIT of the peer UE, and does not send data to the UE for a period of time. The UE switches the HAP, and the original HAP also stops the data forwarding to the UE. In this case, the data is sent to the original HAP. Therefore, the new HAP should delete the cached peer HAP and the pair after the set buffer timer expires. Binding relationship of the HIT of the UE, and re-entering the binding relationship of the UE to the SN node.

Step 714: The new HAP notifies the peer HAP that the UE has switched to the new HAP according to the parameter SOURCE_HAP in the HIP header. The peer HAP updates the cache of the binding between the HIT and the HAP of the UE, that is, the peer HAP replaces the binding relationship between the UE and the original HAP that is cached by the peer HAP with the binding relationship between the UE and the new HAP; The cached timer returns a response to the new HAP. Then, the data sent by the peer HAP to the UE will be sent to the new HAP.

After receiving the response from the peer HAP, the new HAP records the update success status, including: the HIT of the UE and the identifier of the peer HAP, and is used to send the HAP switch notification to the peer HAP without repeating. This record should be deleted when the UE switches to another HAP, when the UE closes the HIP association, when the keep-alive fails, or when the timer expires.

Step 715: The forwarding timer set by the original HAP times out, stops forwarding the data of the UE, and deletes the related information of the stored UE (including the HAP information currently bound by the UE).

This embodiment can have multiple transformations, such as:

1. HAP and SN can be combined, that is, HAP forms a DHT overlay network, and stores HAP and settings. Prepare the binding relationship of HIT;

2. The DHT overlay network can be used to store the binding relationship between the HAP and the HIP device HIT, and a DNS-like server cluster is used to store the binding relationship between the HAP and the HIP device HIT.

3. The HAP can not cache the binding relationship between the HAP and the HIT of the HIP device. That is, each time the HAP needs to send data to the HIP device, the HAP binds the HIT and HAP from the host that is responsible for storing the HIT and HAP bindings. The relationship is determined such that steps 711, 712, 713, 714, 715 can be omitted.

4. HAP can also initiate HAP switching according to its own situation, without relying on the change of the IP address of the HIP device. For example: The original HAP load is too heavy, and the service needs to be stopped. At this time, steps 702 and 703 become HAP to notify the UE to switch the HAP.

In step 704, the UE may carry the current HAP address in the query HAP request, and may be used by the server to determine whether the UE needs to switch the HAP. The server may also return a list of HAPs to the UE, which may be sorted according to priority, and the UE selects the HAP to use. .

FIG. 8 is a schematic diagram of a method for switching an access point of a HIP device according to an embodiment of the present invention. In this embodiment, the HAP may notify the UE according to the change of the IP address of the UE, the storage information of the UE, or the HAP information of the UE obtained by the server. To do a HAP switch, the following steps are included:

Step 801: The UE obtains a small HAP address of the RTT by querying the DNS, the statically configured server, or the DHCPv6, and the UE establishes an HIP association with the HAP (referred to as the original HAP). The original HAP stores the binding relationship between the HIT of the UE and the original IP address, and stores the binding relationship between the HIT of the UE and the original HAP in the peer-to-peer overlay network formed by the SN node.

In step 802, the IP address of the UE changes.

Step 803: The UE notifies the original HAP by using the HIP Update message, and the original HAP responds to the HIP Update message, and records the change of the IP address of the UE.

Step 804: The original HAP determines whether the UE needs to switch the HAP according to the new IP address of the UE and the information stored by itself or the information obtained from the server. For example: The original HAP is based on the new IP address. Obtain the minimum HTP address of the RTT with the new IP address, and decide whether to switch to the new HAP according to the load.

Step 805: If the handover is required, the original HAP sends a HAP handover request to the selected new HAP, and the new HAP sends a HAP handover response (whether or not to accept the handover) to the original HAP according to its own situation.

Step 806: If the new HAP accepts the handover, the original HAP sends a HAP handover request to the UE, where the HIT and the IP address of the new HAP are included. For example: The HAP and IP address of the new HAP are described by the extended parameter HAP_UPDATE. The UE acknowledges the HAP handover request.

Step 807: The UE establishes a HIP association with the new HAP. The UE will use this connection to send data later. The new HAP can check whether the binding relationship between the HIT of the UE and the original HAP is cached. If yes, the binding relationship is deleted. At the same time, the new HAP stores the binding relationship between the HIT of the UE and the new IP address.

Step 808: The new HAP sends a request for storing the binding relationship between the HIT of the UE and the new HAP to the SN, that is, the new SN, and the new SN stores the binding relationship between the HIT of the UE and the new HAP.

Step 809: The new SN sends a request for storing the binding relationship between the HIT of the UE and the new HAP to the data home SN (referred to as the home SN) of the UE according to the routing rule of the overlay network, and the home SN stores the binding relationship between the HIT of the UE and the new HAP. .

Step 810: The UE sends a handover notification to the original HAP, where the address and the identifier of the new HAP are included, and the HIP association with the original HAP is closed. The original HAP changes the binding relationship between the HIT and the IP address of the UE that is stored in the UE to the binding relationship between the HIT of the UE and the new HAP (address and identity), and the binding relationship between the HIT of the UE and the new HAP can be used as the identifier. To clarify the forwarding attributes of the original HAP.

Step 811: The original HAP sends the binding of the HIT of the deleted UE to the original HAP to the connected original SN. The request of the relationship is that the original SN deletes the binding relationship between the HIT of the UE that is saved by itself and the original HAP. Step 812: The original SN sends a request to delete the binding relationship between the HIT of the UE and the original HAP to the home SN according to the routing rule of the overlay network, and the home SN deletes the binding relationship between the HIT of the UE and the original HAP.

Step 813: The peer HAP (that is, the HAP that still sends data to the UE, and the HAPs have not yet learned that the UE has switched to the new HAP) still sends the data to the original HAP to the UE.

Step 814: After receiving the data, the original HAP forwards the data to the new HAP according to the binding relationship between the stored HIT and the new HAP, and adds the parameter SOURCE_HAP to the HIP header to fill in the identifier of the peer HAP.

Step 815: The new HAP forwards data to the UE according to the binding relationship between the HIT of the UE and the new IP address, and the new HAP can remove the parameter SOURCE_HAP in the HIP header when forwarding the data to the UE.

If during this time (ie, before the forwarding timer set by the original HAP in step 810 expires), the UE switches the HAP again (ie, switches from the above new HAP to another HAP), then the new HAP finds the UE. The binding relationship between the HIT and the HAP (ie, other HAPs that are switched from the new HAP). In this case, the new HAP forwards the data to the HAP bound HAP of the UE, and then step 816 is omitted.

The new HAP can cache the binding relationship between the peer HAP and the HIT of the peer UE, and set a cache timer. When the set cache timer expires, the new HAP deletes the binding of the cached peer HAP to the peer UE's HIT. relationship. The cache timer is set here to prevent the cache relationship from being invalid. For example, the new HAP caches the binding relationship between the peer HAP and the HIT of the peer UE, and does not send data to the UE for a period of time. The UE switches the HAP, and the original HAP also stops the data forwarding to the UE. In this case, the data is sent to the original HAP. Therefore, the new HAP should delete the cached peer HAP and the pair after the set buffer timer expires. Binding relationship of the HIT of the UE, and re-entering the binding relationship of the UE to the SN node. Step 816: The new HAP notifies the peer HAP that the UE has switched to the new HAP according to the parameter SOURCE_HAP in the HIP header. The peer HAP updates the cache of the binding between the HIT and the HAP of the UE, that is, the peer HAP replaces the binding relationship between the UE and the original HAP that is cached by the peer HAP with the binding relationship between the UE and the new HAP; The cached timer returns a response to the new HAP. Then, the data sent by the peer HAP to the UE will be sent to the new HAP.

Step 817: The forwarding timer set by the original HAP expires, and the data of the UE is stopped, and the related information of the stored UE (including the HAP information currently bound by the UE) is deleted.

This embodiment can also have various transformations, such as:

1. The HAP and the SN can be combined, that is, the HAP forms a DHT overlay network, and the binding relationship between the HAP and the device HIT is stored;

3. The HAP can not cache the binding relationship between the HAP and the HIT of the HIP device. That is, each time the HAP needs to send data to the HIP device, the HAP binds the HIT and HAP from the host that is responsible for storing the HIT and HAP bindings. The relationship is determined such that steps 813, 814, 815, 816, 817 can be omitted;

4. HAP can also initiate HAP switching according to its own situation, without relying on the change of the IP address of the HIP device. For example: The original HAP load is too heavy, and the service needs to be stopped. At this time, steps 801, 802, and 803 can be omitted.

FIG. 9 shows another embodiment of the present invention. In this embodiment, the original HAP obtains the information of the peer UE that the current UE is communicating from the UE, and sends a HAP handover notification to the peer UE. HAP. The embodiment uses the overlay network formed by the SN node shown in FIG. 6 to store the binding relationship between the HIP device HIT and the current HAP, and includes the following steps:

Step 901: The UE needs to perform HAP handover. The way in which the new HAP is found is the same as the embodiment shown in Figs. 7 and 8.

Step 902: The UE establishes a HIP association with the new HAP. The UE will use this connection to send data later. The new HAP checks whether the binding relationship between the HIT of the UE and the original HAP is cached. If yes, the binding relationship is deleted. At the same time, the new HAP stores the binding relationship between the HIT of the UE and the new IP address.

Step 903: The new HAP sends a request for storing a binding relationship between the HIT of the UE and the new HAP to the SN, that is, the new SN, and the new SN stores the binding relationship between the HIT of the UE and the new HAP.

Step 904: The new SN sends a request for storing the binding relationship between the HIT of the UE and the new HAP to the data home SN (referred to as the home SN) of the UE according to the overlay network routing rule, and the home SN stores the binding relationship between the HIT of the UE and the new HAP. .

Step 905: The UE sends a handover notification to the original HAP, where the address and the identifier of the new HAP are included, and the HIT list of the UE that is communicating with the UE is notified, and the HIP association is closed. The HIP Close packet can be extended, the parameter HAP_UPDATE is added to describe the HIT and IP address of the new HAP, and the parameter TARGET_LIST is added to describe the HIT list of the peer UE that is communicating with the UE. The original HAP changes the binding relationship between the HIT and the IP address of the UE that is stored in the UE to the binding relationship between the HIT of the UE and the new HAP (address and identifier), and the binding relationship between the HIT of the UE and the new HAP can be used as the identifier. To clarify the forwarding attributes of the original HAP.

Step 906: The original HAP sends a request to delete the binding relationship between the HIT of the UE and the original HAP to the original SN, and the original SN deletes the binding relationship between the HIT of the UE and the original HAP. Step 907: The original SN sends a request to delete the binding relationship between the HIT of the UE and the original HAP to the home SN according to the routing rule of the overlay network, and the home SN deletes the binding relationship between the HIT of the UE and the original HAP.

Step 908: The original HAP queries the binding relationship between the HIT and the HAP of the UE that is cached by the HeNB according to the HIT list of the UE that is in communication with the UE, or obtains the binding relationship between the HIT and the HAP of the UE from the overlay network formed by the SN node. Sending a HAP handover message to the peer HAP, where the message includes the identifier of the HIT and the new HAP of the UE. The peer HAP updates the HIT and HAP binding of the UE to the UE. The HIT is bound to the new HAP, and the cached timer can be refreshed. The subsequent data sent to the UE is sent to the new HAP.

Step 909: The peer HAP (that is, the HAP that still sends data to the UE) still sends data to the original HAP to the UE.

Step 910: After receiving the data, the original HAP forwards the data to the new HAP according to the binding relationship between the stored HIT of the UE and the new HAP.

Step 911: The new HAP forwards data to the UE according to the binding relationship between the HIT of the UE and the new IP address.

Step 912: The forwarding timer set by the original HAP times out, stops forwarding the data of the UE, and deletes the related information of the stored UE (including the HAP information currently bound by the UE). This embodiment can also have various transformations, such as:

The HIT list of the peer UE that the UE is communicating with may be obtained by the new HAP, and the HAP handover notification is sent by the new HAP to the peer HAP. The relationship between the HIT of the peer UE and the peer HAP may be obtained from the original HAP, or may be obtained from the SN. The overlay network composed of nodes is obtained.

10 is another embodiment of the HAP handover of the HIP device of the present invention. After the HAP is switched, if the original HAP receives the data sent by the other HAP to the HIP device, the original HAP forwards the data, and notifies the peer HAP of the HIP. The device has switched HAP. Includes the following steps:

Step 1001: The UE needs to perform HAP handover. The way in which the new HAP is found is the same as in the embodiment shown in Figs.

Step 1002: The UE establishes a HIP association with the new HAP. The UE will subsequently use this connection to send data. The new HAP checks whether the binding relationship between the HIT of the UE and the original HAP is cached. If yes, the binding relationship is deleted. At the same time, the new HAP stores the binding relationship between the HIT of the UE and the new IP address.

Step 1003: The new HAP sends a request for storing the binding relationship between the HIT of the UE and the new HAP to the SN, that is, the new SN, and the new SN stores the binding relationship between the HIT of the UE and the new HAP.

Step 1004: The new SN sends a request for storing the binding relationship between the HIT of the UE and the new HAP to the data home SN (referred to as the home SN) of the UE according to the overlay network routing rule, and the home SN stores the binding relationship between the HIT of the UE and the new HAP. .

Step 1005: The UE sends a handover notification to the original HAP, where the address and the identifier of the new HAP are included, and the HIT list of the UE that is communicating with it is notified, and the HIP association is closed. The HIP Close package can be extended, and the parameter HAP_UPDATE is added to describe the HIT and IP address of the new HAP. The original HAP changes the binding relationship between the HIT and the IP address of the UE that is stored in the UE to the binding relationship between the HIT of the UE and the new HAP (address and identity), and the binding relationship between the HIT of the UE and the new HAP can be used as the identifier. To clarify the forwarding attributes of the original HAP.

While changing the binding relationship, the original HAP can set a forwarding timer for forwarding timing. After the timeout expires, the data is not forwarded to the UE. The duration of the forwarding timer should be slightly longer than the timer duration of the binding between the HIT of the original HAP cache UE and the new HAP.

Step 1006: The original HAP sends a request to delete the binding relationship between the HIT of the UE and the original HAP to the original SN, and the original SN deletes the binding relationship between the HIT of the UE and the original HAP.

Step 1007: The original SN sends a request to delete the binding relationship between the HIT of the UE and the original HAP to the home SN according to the routing rule of the overlay network, and the home SN deletes the binding relationship between the HIT of the UE and the original HAP.

Step 1008: The peer HAP (that is, the HAP that still sends data to the UE) still sends data to the original HAP to the UE.

Step 1009: After receiving the data, the original HAP notifies the peer HAP and the HAP handover information of the UE according to the binding relationship between the HIT of the UE and the new HAP, including the HIT and the new HAP identifier of the UE. After receiving the HAP handover information of the UE, the peer HAP updates the binding between the HIT of the cached UE and the original HAP to be the binding between the HIT of the UE and the new HAP, and does not update the cache timer, and the subsequent data sent to the UE is sent. Go to the new HAP.

Step 1010: The original HAP forwards data to the new HAP according to the binding relationship between the HIT of the UE and the new HAP.

Step 1011: The new HAP forwards data to the UE according to the binding relationship between the HIT of the UE and the new IP address.

The new HAP can cache the binding relationship between the peer HAP and the HIT of the peer UE, and set a cache timer. When the set cache timer expires, the new HAP deletes the binding of the cached peer HAP to the peer UE's HIT. relationship. The cache timer is set here to prevent the cache relationship from being invalid. For example, the new HAP caches the binding relationship between the peer HAP and the HIT of the peer UE, and does not send data to the UE for a period of time. The UE switches the HAP, and the original HAP also stops the data forwarding to the UE, and then sending data to the original HAP fails. Therefore, the new HAP should delete the binding relationship between the cached peer HAP and the HIT of the peer UE after the set buffer timer expires, and re-enter the binding relationship of the UE to the SN node.

Step 1012: The forwarding timer set by the original HAP times out, stops forwarding the data of the UE, and deletes the related information of the stored UE (including the HAP information currently bound by the UE).

This embodiment can have multiple transformations, such as:

Step 1009: After receiving the data, the original HAP notifies the peer HAP and the HAP handover of the UE according to the binding relationship between the HIT of the UE and the new HAP, and does not include the HIT and the new HAP identifier of the UE. After receiving the HAP handover notification from the UE, the peer HAP deletes the binding relationship between the HIT of the cached UE and the original HAP, and obtains the HAP currently associated with the UE from the overlay network formed by the SN node when the data is sent to the UE next time.

As can be seen from the above embodiments, the technical solutions of the present invention are based on the following HAP switching methods:

After the IP address of the HIP device is changed, the HIP device determines whether to switch the HAP according to the obtained HAP information of the smaller RTT, or the original HAP of the HIP device is based on the obtained HAP information with less RTT between the HIP device and the HIP device. Determining whether the HIP device performs HAP switching;

When the HAP switch is determined, the HIP device establishes a HIP association with the new HAP and closes the association with the original HAP. The original HAP forwards the data sent to the HIP device to the new HAP.

Further, when the HIP device establishes a HIP association with the new HAP, the new HAP checks whether the binding relationship between the HIP device and the original HAP is cached, and if yes, deletes the binding relationship; The new HAP stores the binding relationship between the HIP device and its new IP address.

Further, after the HIP device establishes a HIP association with the new HAP, the HIP device sends a handover notification to the original HAP, including the new HAP information. The original HAP stores the HIT and IP address of the HIP device. The binding relationship is changed to the binding relationship between the HIT of the HIP device and the new HAP. The original HAP forwards the number sent to the HIP device to the new HAP According to, specifically:

After receiving the data sent by the peer end of the HIP device to the HIP device, the original HAP forwards data to the new HAP according to the stored binding relationship between the HIT of the HIP device and the new HAP, and The forwarded data carries the peer HAP information.

Further, the new HAP notifies the peer HAP that the HIP device has switched to the new HAP according to the peer HAP information; the peer HAP replaces the binding relationship between the HIP device and the original HAP that is stored by the peer HAP. A binding relationship between the HIP device and the new HAP, and returning a response to the new HAP; the new HAP records an update success status of the peer HAP, where the HIP device and the peer HAP information are included.

Further, the handover notification sent by the HIP device to the original HAP may further include: an HIT list of the peer HIP device that is communicating with the HIP device; information, and notifying the peer HAP that the HIP device is switched to the new HAP The peer HAP replaces the binding relationship between the HIP device and the original HAP that is stored in the peer end with the binding relationship between the HIP device and the new HAP, and returns a response to the new HAP; the new HAP record office The update success status of the peer HAP includes the HIP device and the peer HAP information.

Corresponding to the foregoing method for HAP handover, the present invention further provides a system for HAP handover, including: a HIP device, and an original HAP and a new HAP of the HIP device. among them,

The HIP device is further configured to establish a HIP association with the new HAP when performing the HAP handover. And closing the association with the original HAP;

The original HAP is further configured to forward the data sent to the HIP device to the new HAP, where the new HAP is used to send the data forwarded by the original HAP to the HIP device. Further, the new HAP is further configured to: when establishing a HIP association with the HIP device, check whether the binding relationship between the HIP device and the original HAP is cached, and if yes, delete the binding relationship; The new HAP stores the binding relationship between the HIP device and its new IP address.

Further, the HIP device may be further configured to: after establishing a HIP association with the new HAP, send a handover notification to the original HAP, where the new HAP information is included; and correspondingly, the original HAP may be used to: store the HIP by itself. The binding relationship between the HIT and the IP address of the device is changed to the binding relationship between the HIT of the HIP device and the new HAP.

Further, the original HAP may be further configured to: after receiving the data sent by the peer end of the HIP device to the HIP device, according to the stored binding relationship between the HIT of the HIP device and the new HAP, The new HAP forwards the data, and carries the peer HAP information in the forwarded data. Correspondingly, the new HAP is further configured to: according to the binding relationship between the HIT of the HIP device saved by the HIP device and the new IP address, to the HIP The device forwards the data.

Further, the new HAP may be further configured to notify the peer HAP that the HIP device is handed over to the new HAP according to the peer HAP information, and receive the HIP device and the original HAP that the peer HAP stores by itself. The binding relationship is replaced by the response returned by the binding relationship between the HIP device and the new HAP. The update success status of the peer HAP is recorded, where the HIP device and the peer HAP information are included.

Further, the handover notification sent by the HIP device to the original HAP may further include: an HIT list of the peer HIP device that is communicating with the HIP device;

Correspondingly, the original HAP may be used to obtain the peer HAP information corresponding to the HIT in the HIT list, and notify the peer HAP that the HIP device has switched to the new HAP; receiving the peer HAP will itself The stored binding relationship between the HIP device and the original HAP is replaced by The response returned by the binding relationship between the HIP device and the new HAP; the update success status of the peer HAP is recorded, where the HIP device and the peer HAP information are included.

The above is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention.

Claims

Claim

A method for switching a host identity protocol device access point (HAP), the method comprising:

2. The method of HAP handover according to claim 1, wherein the method further comprises:

The method of HAP handover according to claim 1 or 2, wherein the method further comprises:

After the HIP device establishes a HIP association with the new HAP, the HIP device sends a handover notification to the original HAP, including new HAP information.

The method for the HAP handover according to claim 3, wherein the original HAP forwards the data sent to the HIP device to the new HAP, specifically:

After the original HAP receives the data sent by the peer end of the HIP device to the HIP device, according to the stored binding relationship between the HIT of the HIP device and the new HAP, the new HAP is sent to the new HAP. Forwarding data, and carrying the peer information in the forwarded data;

The new device forwards data to the HIP device according to the binding relationship between the HIT of the HIP device and the new IP address.

5. The method of HAP handover according to claim 4, wherein the method further comprises:

6. The method of HAP handover according to claim 3, wherein the method further comprises:

A system for HAP switching, the system comprising: a HIP device, and an original HAP and a new HAP of the HIP device;

After the IP address of the HIP device is changed, the HIP device is configured to determine whether to switch the HAP according to the obtained HAP information with a smaller RTT, or the original HAP is obtained according to the acquired The HTP information of the RTT between the HIP devices determines whether the HIP device performs HAP switching.

The original HAP is further configured to forward the data sent to the HIP device to the new HAP, where the new HAP is used to send the data forwarded by the original HAP to the HIP device.

The HAP switching system according to claim 7, wherein the new HAP is further configured to: when establishing a HIP association with the HIP device, check whether the HIP device is cached with the original HAP. Determining the relationship, if yes, deleting the binding relationship; and the new HAP stores a binding relationship between the HIP device and its new IP address.

The HAP switching system according to claim 7 or 8, wherein the HIP device is further configured to: after establishing a HIP association with the new HAP, send a handover notification to the original HAP, including new HAP information;

10. The HAP switching system according to claim 9, wherein:

11. The HAP switching system according to claim 10, wherein:

12. The HAP switching system according to claim 9, wherein: