WO2009153943A1 - バインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノード - Google Patents

バインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノード Download PDF

Info

Publication number
WO2009153943A1
WO2009153943A1 PCT/JP2009/002637 JP2009002637W WO2009153943A1 WO 2009153943 A1 WO2009153943 A1 WO 2009153943A1 JP 2009002637 W JP2009002637 W JP 2009002637W WO 2009153943 A1 WO2009153943 A1 WO 2009153943A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface
home
binding cache
domain
mobile node
Prior art date
Application number
PCT/JP2009/002637
Other languages
English (en)
French (fr)
Inventor
ジャヤタランモハナダマヤンティ
阿相啓吾
ンーチャンワー
リムチュンキョンベンジャミン
Original Assignee
パナソニック株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック株式会社 filed Critical パナソニック株式会社
Priority to US12/997,951 priority Critical patent/US20110103260A1/en
Priority to JP2010517703A priority patent/JPWO2009153943A1/ja
Publication of WO2009153943A1 publication Critical patent/WO2009153943A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/005—Multiple registrations, e.g. multihoming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5084—Providing for device mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Definitions

  • the present invention relates to a binding cache generation method and a binding cache generation system when a mobile node having a plurality of interfaces roams in a home domain.
  • the present invention also relates to a home agent and a mobile node in the binding cache generation system.
  • Non-Patent Document 1 MIPv6 (Mobility Support in IPv6) as shown in Non-Patent Document 1 below.
  • the mobility support in Non-Patent Document 1 is realized by introducing an entity called a home agent (HA) into the home network of the mobile node (MN).
  • the MN registers the care-of address (CoA) acquired by the external link with the HA using a message called a binding update (BU) message.
  • the HA can generate a binding (location information) between the home address (HoA), which is the address acquired from the home link, and the CoA of the MN by the BU message.
  • HoA home address
  • HoA home address
  • the HA intercepts the message addressed to the HoA of the MN by binding, encapsulates it in a packet addressed to the CoA of the MN, and transfers it.
  • This packet encapsulation is a process for setting a received packet in the payload of a new packet, and is known as packet tunneling.
  • MIPv6 One of the problems in MIPv6 is that the MN updates one or more HAs and communication partners (Correspondent Node: CN) each time the network attachment changes or when the binding validity period expires. There is a need. This update increases the signaling load emitted by the fast moving MN to the wireless network. Further, the handoff establishment time (assuming that route optimization is used) with the CN every time the network connection (attachment) is changed is an RR (Return Routability) message every time the network connection (attachment) is changed. Since it is necessary to send and receive BU messages, a lot of time is required. For this reason, since a considerable time is required for establishing a handoff during a session related to a flow or a connection, jitter and packet loss occur.
  • RR Return Routability
  • Such jitter is undesirable for real-time applications such as VoIP (Voice over IP) and multimedia and video streaming.
  • packet loss is undesirable for flows that transmit important text and data information. Packet loss further reduces TCP throughput when TCP (Transmission Control Protocol) is used to transfer important data and applications.
  • TCP Transmission Control Protocol
  • Network-based local mobility management refers to managing the mobility of a MN located in a geographically local network segment by a network entity rather than the MN itself.
  • the MN needs to refer to the same prefix everywhere in the local domain.
  • the above prefix must be obtained from a router located at a higher level in the routing hierarchy.
  • the router is preferably located in the default routing path of all MNs in the local domain so that the benefits of local mobility management can be obtained.
  • the above-mentioned router must have the above-mentioned prefix route and reachability information for the above-mentioned prefix, that is, routing information (prefix-based route). As a result, this prefix-based route must be generated by the network entity.
  • PMIPv6 Proxy Mobile Internet Protocol 6
  • the PMIPv6 protocol is primarily designed to provide mobility management services in the local part of the network for regular IPv6 hosts that do not have a CMIPv6 (Client Mobile IPv6) stack. Nevertheless, PMIPv6 is also useful for nodes with a CMIPv6 stack. To explain why, the MN with CMIPv6 stack is located in the external PMIPv6 domain and is routed at the same prefix (external local mobility anchor (LMA) / HA via an interface in that local domain).
  • LMA local mobility anchor
  • MN does not need to perform any global registration when referencing external PMIPv6 local prefixes.
  • MN having the above CMIPv6 stack roams into the home domain, it continues to refer to its home network prefix and participates in location registration even though the geographical location has changed. There is no need to do.
  • Non-Patent Document 2 The outline of PMIPv6 disclosed in Non-Patent Document 2 will be described below.
  • the MN provides its network access identifier (NAI) while associating with a mobile access gateway (MAG).
  • NAI network access identifier
  • the MAG is a router to which the MN is directly attached, and a router (proxy) that performs local registration as a proxy of the MN with respect to a local mobility anchor (LMA) under the control of the MN. Node).
  • the NAI is transferred to an AAA (Authentication, “Authorization” and “Accounting”) server for the purpose of connection authentication.
  • AAA Authentication, “Authorization” and “Accounting”
  • the AAA server qualifies (Authorize) the network connection (Authorization) of the MN
  • the AAA server sends back a response to notify the MAG that the connection authentication (Authentication) has succeeded.
  • the AAA server further provides the LMA address and some MN profiles such as address configuration mode or special policies that the MN needs to have in roaming in the local domain.
  • the MAG When the MAG acquires the above MN parameters, the MAG transmits a proxy BU (PBU) message to the LMA.
  • PBU proxy binding confirmation
  • the MAG emulates the home link and the local home link after obtaining a prefix related to the interface to which the MN is attached from a proxy binding confirmation (PBA) message that is a response to the PBU message.
  • PBA proxy binding confirmation
  • the PBU message executed by the MAG as described above, that is, local registration, is the same as the MIPv6 BU message except for only a flag indicating that this message is a PBU message.
  • the reachability state of the MN is generated in the LMA.
  • the LMA has a reachability state for the MN prefix acquired in the PMIPv6 domain, and the address reachable to this MN prefix is the address of the MAG.
  • the MN configures an address using the prefix received in the PMIPv6 domain using a stateful or stateless address configuration mode. Since each MN gets a unique prefix, a prefix-based cache in the LMA will reach the MN well. Each data packet that arrives at the LMA is tunneled to the MAG connected to the MN, and each data packet that arrives from the MN to the MAG is tunneled to the LMA.
  • the MAG's neighbor cache table binds the PMIPv6 local address of the MN and the link layer address used to transmit the packet to the MN.
  • the PMIPv6 protocol disclosed in Non-Patent Document 2 is designed to support a MN that has a plurality of interfaces and all the interfaces attach simultaneously. Basically, each interface is assigned a unique prefix, and the PMIPv6 protocol ensures that each interface references the same prefix while roaming in the PMIPv6 domain. Thus, for MNs with multiple interfaces, multiple bindings of PMIPv6 are maintained in the LMA, and each binding is maintained as an individual mobility session identified by a unique prefix.
  • Non-Patent Document 4 describes how to provide a multihoming support function in HA when a MN having an MIPv6 function roams in an external domain.
  • the multihoming support function in Non-Patent Document 4 is a mechanism that allows packets to arrive via individual care-of addresses (CoA) associated with one or more interfaces of the MN so that the benefits of multihoming can be obtained.
  • CoA individual care-of addresses
  • the HA serving as the geographical anchor point for the MN's home prefix needs to have binding information for the MN's CoA. This binding information is a mapping between the home address (HoA) and individual CoAs associated with one or more interfaces of the MN.
  • Non-Patent Document 4 describes the use of a binding identifier (BID) to maintain a plurality of bindings individually and simultaneously.
  • This BID uniquely identifies each interface, that is, the CoA of each interface.
  • the BID is generated by the roaming MN and transferred to the HA at the time of binding registration.
  • the HA can use the BID to maintain a registration that allows packets destined for one HoA to reach individual CoAs.
  • 3GPP (Third Generation Partnership Project) is a wireless local area network (WLAN), cellular network or third generation (3G) cellular network, 3.9 generation, 4th generation, etc. He is working on a global heterogeneous network connectivity structure with various types of radio access networks such as wide area networks (WAN).
  • Global heterogeneous network connectivity structure enables seamless mobility and supports heterogeneous application services such as real-time video, VoIP (Voice over IP), information, critical data, etc. with high quality of service Useful for.
  • Non-Patent Document 3 below discloses that PMIPv6 will be adopted as a local mobility management (LMM) protocol in the 3GPP local domain.
  • LMM local mobility management
  • the 3GPP local domain may be composed of a 3G cellular network and a trusted or untrusted WLAN access network or WiMAX access network.
  • a MN having multiple disparate interfaces will need to roam the 3GPP local domain and simultaneously attach via various types of interfaces to achieve multihoming.
  • Other conventional techniques include those disclosed in Non-Patent Documents 5, 6, and 7 and Patent Documents 1 to 10 below.
  • communication between the plurality of interfaces of the MN 200 and the CN 214 is performed by first using an LMA / HA / home PDN (Packet Data Network) gateway 203 and a MAG / 3G serving gateway of the home PMIPv6 network 204 that is a 3GPP network. (S-GW) 201 (and the Internet 205).
  • LMA / HA / home PDN Packet Data Network
  • S-GW Serving Mobility Management Entity
  • the access router (AR) 207 of the network 206 communication between the interfaces of the MN 200 and the CN 214 is performed by the LMA / HA / home of the home PMIPv6 network 204. This is performed via the PDN gateway 203 and the MAG / ePDG (evolved Packet Data Gateway) 202 (and the Internet 205).
  • the network that the MN 200 newly connects is an unreliable access network (Untrusted Access Network), for example, the WLAN 206.
  • the LMA / HA / home PDN gateway 203 in the LMA / HA / home PDN gateway 203, PMIPv6 registration and CMIPv6 registration of the MN 200 occur. Focusing on the basic operation assumed in the LMA / HA / home PDN gateway 203, first, by assigning different prefixes to a plurality of interfaces of the MN 200, the LMA / HA / home PDN gateway 203 allows each interface of the MN 200 to And maintain individual PMIPv6 caches (first entry E1 and second entry E2 of the binding cache 213) with different prefixes associated with each.
  • CMIPv6 cache when different HoAs are assigned to the interfaces of the MN 200, the LMA / HA / home PDN gateway 203 manages them separately as CMIPv6 caches related to the respective HoAs, or Non-Patent Document 4
  • the BID is used to distinguish each interface associated with one CMIPv6 cache.
  • the third entry E3 of the binding cache 213 shown in FIG. 14 configures the CMIPv6 cache with the address generated from P1 as HoA and the address generated from P2 as CoA.
  • a certain PMIPv6 cache (first entry E1) has a HoA generated from the same prefix and does not have a BID or an interface identifier. It can only be replaced with a binding. Basically, when updating a PMIPv6 cache with a CMIPv6 cache, or vice versa, the BID / interface identifier is not a key parameter.
  • the PMIPv6 cache has the same BID / interface identifier as the CMIPv6 registration request, but the prefixes of PMIPv6 registration and CMIPv6 registration are different, the PMIPv6 registration and CMIPv6 registration are not overwritten with each other and exist in parallel.
  • the 3G cellular interface If1 of the MN 200 is connected to the MAG / 3G ⁇ S-GW (serving gateway) 201, and the WLAN interface If2 of the MN 200 is connected to the MAG / ePDG 202. .
  • the WLAN interface If2 of the MN 200 is directly connected to the AR 207, and is attached (attached) to the MAG / ePDG 202 via the IPsec tunnel interface.
  • the MAG / ePDG 202 is a reliable gateway for a home PMIPv6 network 204 (hereinafter referred to as a home PMIPv6 domain) which is a 3GPP network.
  • the WLAN 206 is connected to the Internet 205, and the home PMIP domain 204 is also connected to the Internet 205.
  • the MN 200 acquires a prefix from the LMA / HA / home PDN gateway 203 and generates an address. However, the MN 200 configures another address for the WLAN interface If2.
  • the address is a non-invariant address whose prefix is directly related to the AR 207 prefix. This non-persistent address is only used to tunnel the packet to the MAG / ePDG 202.
  • the MAG (MAG / 3G ⁇ S-GW) 201 is connected to the LMA / HA / home PDN gateway 203.
  • PBU / PBA operation (signaling 208 in the figure) is performed between the two, and the LMA / HA / home PDN gateway 203 assigns the home prefix P1 in the PBA message (208).
  • the PMIPv6 registration in the LMA / HA / home PDN gateway 203 related to the MN 200 at this time is the first entry E1 of the binding cache (BC) 213.
  • This first entry E1 corresponds to the home prefix P1, the address MAG1 of the MAG / 3G serving gateway 201 as the MAG address, the NAI that is the MN-ID, and If1-ID as the If-ID. Since this content is described in Non-Patent Document 2, detailed description thereof is omitted here.
  • the MN 200 first obtains an unchanging address, that is, constructs an unchanging address from the prefix of the AR 207, and then makes a domain name server (DNS) query. To obtain an ePDG address.
  • DNS domain name server
  • the MN 200 obtains the ePDG address, it starts an Internet key exchange (IKEv2) procedure with the MAG / ePDG 202 to establish a secure tunnel.
  • IKEv2 Internet key exchange
  • the MAG / ePDG 202 exchanges a PBU / PBA message (signaling 209 in the figure) with the LMA / HA / home PDN gateway 203, and A prefix P2 used as a local prefix (external prefix) is acquired for the prefix P1 and transferred to the MN 202 (signaling 211 in the figure).
  • Signaling 211 indicates an IPsec tunnel establishment confirmation message.
  • the registration generated in the BC 213 by the PBU / PBA message (signaling 209 in the figure) is the second entry E2.
  • the second entry E2 corresponds to the external prefix P2, the address MAG2 of the MAG / ePDG 202 as the MAG address, the NAI that is the MN-ID, and the If2-ID as the If-ID.
  • the prefix P1 is referred to as a home prefix, and the prefix P2 is referred to as an external prefix. This is based on the relationship between HoA and CoA in the entry E3. Therefore, when communicating with CN using prefix P2, prefix P2 is regarded as a home prefix and prefix P1 is regarded as an external prefix.
  • CMIPv6 is described in Non-Patent Document 4 and transmitted when simultaneously connecting from the home network and the external network, in order to achieve reachability.
  • this CMIPv6 registration message includes information (HoA (P1) and CoA (P2)) for generating the entry E3.
  • Information indicating that E3 is generated independently of E1 is included.
  • the bandwidth can be widened to increase the QoS of some flows of the MN 202.
  • the MN 200 may desire that these flows reach only via the WLAN interface If2.
  • the CMIPv6 registration 212 with the flag H may be sent, and the filter rule may be made appropriate so that a certain flow from the CN 214 arrives only via the WLAN interface If2. Since the flag H is described in Non-Patent Document 4, detailed description thereof is omitted.
  • the registration generated in the binding cache 213 when the MN 200 executes the CMIPv6 registration 212 with the flag H is the third entry E3.
  • the HoA generated from the home prefix P1 the CoA (P2) generated from the external prefix P2 as CoA, the NAI that is the MN-ID, and the flag H as the If-ID correspond to each other.
  • the important point here is how the third entry E3 is maintained.
  • the flag H is used to generate an entry indicating that the home agent is connected to both home and away.
  • the LMA / HA / home PDN gateway 203 accepts the CMIPv6 registration 212 in which the flag H exists and generates a CMIPv6 entry as the third entry E3.
  • the third entry E3 does not overwrite the first entry E1.
  • the MN 200 can send a CMIPv6 registration 212 with BID or flag H, and this BID should be different from the interface identifier If1-ID so that the first PMIPv6 entry E1 is not overwritten by the CMIPv6 registration 212 It is.
  • the PMIPv6 protocol uses a unique prefix for each interface, so the PMIPv6 cache is replaced by the CMIPv6 cache because the PMIPv6 cache prefix matches the home address prefix of the new CMIPv6 BU message. Because it is only when you do.
  • CMIPv6 registration is directly related to the second entry E2.
  • those skilled in the art can use the LMA / HA / home PDN gateway 203 to register the PMIPv6 prefix P2 in the BC 213.
  • the LMA / HA / home PDN gateway 203 can correctly route the packet to the CoA (P2) only when it discovers the address MAG2 of the MAG 202.
  • the LMA / HA / home PDN gateway 203 basically routes packets addressed to HoA using the first entry E1 (PMIPv6 entry) or the third entry E3 (CMIPv6 entry). From the above description, it can be seen that the CMIPv6 binding cache (third entry E3) is very static, assuming that the contents of the CMIPv6 binding cache do not change. Therefore, the present invention is to provide a mechanism for optimizing signaling for generating the CMIPv6 entry E3.
  • Patent Document 1 pursues a problem in generating a dynamic roaming service contract.
  • a multi-mode terminal (MMT) attached to an external network is discovered by the home network using parameters provided by the MMT. This parameter is acquired through the interface of the MMT connected to the outside.
  • the home network creates a dynamic roaming contract using the external network identifier provided by the MMT. This signaling by the MMT does not have to be continuous.
  • the MMT may provide cell location data such as network type, operator code, WLAN SSID (Service Set IDdentifier) or base station SSID information.
  • the home network basically identifies parameters of the external network from these data and generates a fly contract.
  • Patent Document 1 does not deal with the signaling optimization described in FIG. 14, but provides information about an external network that uses an interface connected to the external network to the home network. To do. This information is provided only once, but has nothing to do with creating a binding entry in the home network.
  • Patent Document 2 discloses a method for solving a problem in synchronizing signaling between a plurality of HAs in a home network. For load balancing, it is useful to use a plurality of HAs in the home network. In preparation for an error and for the system to adapt to dynamic load balancing, one HA's binding cache entry (BCE) is also stored on the other HA. However, when the MN is in the idle state, it is not necessary to store the BCE in all the HAs. In the method disclosed in Patent Document 2, when the MN transmits a BU message to the HA, information indicating whether the MN is in an active state or an idle state is transmitted together. This information is used to synchronize signaling between multiple HAs.
  • BCE binding cache entry
  • Patent Document 2 provides information indicating whether the MN is in an active state or an idle state, but does not provide information on interface binding for generating a BCE in the HA.
  • Patent Document 3 discloses a system that performs a binding update to HA and CN when an MN has a plurality of interfaces and all the interfaces are connected to an external network. If the MN has multiple interfaces, sending location registration to all peer entities increases the signaling load. In Patent Document 3, in order to reduce the signaling load, a CoA with a MN is updated with respect to the HA, and another CoA is updated with respect to the CN. According to this method, signaling efficiency can be realized. However, although the MN makes a clever decision to reduce the signaling load due to the MN, the MN needs to continue sending BU messages. The problem in FIG. 14 is to completely eliminate the MN signaling when roaming home PMIPv6.
  • Patent Document 4 discloses a method similar to PMIPv6 of Non-Patent Document 2.
  • the network in Patent Document 4 includes a local mobility domain access router and a wireless access point connected to the access router, and the wireless access point is a proxy for the MN.
  • the access router in the local mobility domain holds the proxy CoA of the MN, and when a packet addressed to the MN arrives, replaces the proxy CoA with the local address of the wireless access point.
  • the local address of the wireless access point is not visible to the MN. This method can reduce the signaling load associated with the MN, but cannot reduce the signaling when a MN with multiple interfaces roams in the PMIPv6 domain.
  • the next problem to be noticed is when a MN having a plurality of interfaces registers a plurality of bindings in the core network in order to realize simultaneous connectivity via the plurality of interfaces.
  • the problem of multiple binding registrations for realizing this simultaneous connection needs to be solved.
  • unnecessary signaling wastes MN's battery power and increases the signaling load on the wireless access network.
  • Wireless access network and battery resources are limited and need to be protected by avoiding unnecessary signaling.
  • the problem is that the MN with multiple interfaces is attached to the core network, one interface is attached to the home link, and the other interface is attached to the external link This is remarkable in the case of the assumption.
  • the home link is a link in which the MN refers to a home prefix described in Non-Patent Document 1, and the home prefix is also defined in Non-Patent Document 1.
  • the home prefix is a prefix managed by the home agent and is used to configure the MIPv6 home address of the MN.
  • a home path setup delay occurs when home prefix mobility is managed by a PMIPv6 mechanism such as 3GPP.
  • the operation of the PMIPv6 mechanism in the local domain is described in Non-Patent Document 5.
  • the home link is not a 3GPP link, that is, if the home link is not managed by the 3GPP architecture, or if the home prefix mobility is not managed by PMIPv6, the MN may be able to detect the home link quickly,
  • the path setup delay issue depends on the actual home link detection behavior.
  • the problem here can be applied to all networks where home prefix mobility is managed by the PMIPv6 mechanism and home link setup is delayed. This problem will be described with reference to FIG. It is also apparent to those skilled in the art that the problem here can be applied when the home prefix mobility is managed by a GTP (Generic Tunnelling Protocol) mechanism.
  • GTP Generic Tunnelling Protocol
  • Non-Patent Document 7 describes a mechanism in which a MN having a plurality of interfaces can be simultaneously located on a home link and an external link via the plurality of interfaces, and all the interfaces are connected to the core network. Is described.
  • a MN detects a home link via one interface and an external link via another interface, the MN indicates that it is simultaneously connected to the home link and the external link.
  • a MIPv6 BU message including a BID option having a flag is transmitted via an external link. This H flag provides the HA with information indicating that the packet destined for the MN can reach both the home side interface and the external side interface.
  • Non-Patent Document 7 is an assumption that a MN having a plurality of interfaces connects to a network via a plurality of interfaces in an external domain, and one of the interfaces returns to the home domain. is there.
  • Non-Patent Document 7 three cases that are not covered by Non-Patent Document 7 are considered as cases where the home link and the external link are simultaneously connected.
  • one interface may be connected to the home link when the MN boots up both interfaces simultaneously.
  • the MN may have one interface that is connected to an external link and being handed off, and the MN boots up another interface that can be connected to the home link.
  • the third case is when handoff occurs on both interfaces at the same time, referring to the home prefix on one interface and referring to the external prefix on another interface. This is shown in FIG.
  • the MN 903 has a plurality of different types of interfaces, for example, Non-3GPP interfaces such as WLAN and WiMAX, UTRAN (Universal Terrestrial Radio Access Network), GPRS (General Packet Radio Service), CDMA (Code Division Multiple Multiple). Access) 2000 and 3GPP interfaces such as E-UTRAN (evolved-UTRAN) are conceivable.
  • Non-3GPP interfaces such as WLAN and WiMAX
  • UTRAN Universal Terrestrial Radio Access Network
  • GPRS General Packet Radio Service
  • CDMA Code Division Multiple Multiple Multiple). Access
  • 2000 and 3GPP interfaces such as E-UTRAN (evolved-UTRAN) are conceivable.
  • E-UTRAN evolved-UTRAN
  • the MN 903 has two of a 3G interface and a Non3GPP interface.
  • the MN 903 attaches to the WiMAX access network 901
  • the MAG function of the network coexists with an access gateway located in the wireless access network.
  • the MN 903 has a WLAN interface as a Non3GPP interface and is attached to an unreliable WLAN access network
  • the MAG function of the network coexists with the ePDG (evolved packet packet data network gateway). It is possible.
  • the MN 903 is attached to a 3G access network such as E-UTRAN, UTRAN, and GERAN
  • the MAG function of that network may coexist with the S-GW (Serving Gateway).
  • the MN 903 has an LMA / HA function coexisting with a P-GW (Packet data network Gateway) in the 3GPP architecture.
  • P-GW Packet data network Gateway
  • the MN 903 uses only two interfaces If1 and If2.
  • a WiMAX interface (referred to here as a Non3G interface) If2
  • an LTE (Long-Term Evolution) type interface (referred to as a 3G interface here) If1 is used.
  • other types of interfaces can be used for the MN 903 to attach at the same time, and can also be applied to interfaces assumed to be used in the 3GPP standard.
  • the present invention can also be applied to networks using similar architectures and mobility protocols.
  • the MN 903 first turns on only the WiMAX interface If2, and after some time, turns on the 3G interface If1 for the benefit of load balancing and load sharing. Shall.
  • the MN 903 turns on only the power supply of the WiMAX interface If2 in an external network (for example, VPLMN: Visited Public Land Mobile Network).
  • the MN 903 uses the MIPv6 mechanism to manage the mobility of the WiMAX interface If2. After that, the MN 903 returns to the EPC 900 that is the home domain with the WiMAX interface If2 turned on.
  • the MN 903 moves to, for example, HPLMN (Home Public Land Mobile Mobile Network) as the EPC 900, it is conceivable to turn on the LTE interface If1.
  • LTE interface If1 There are many reasons to power on the LTE interface If1, eg, the LTE cell is identified in the HPLMN 900 and it is decided to realize the benefits of load balancing and load sharing to improve the performance of the flow. Conceivable.
  • MN 903 moves to HPLMN 900, that is, EPC (evolved packet core) 900, and connects to EPC 900 by connecting WiMAX interface If2 to MAG 911. It is assumed that the mobility of the WiMAX interface If2 is managed by the MIPv6 mechanism in the home domain 900. Furthermore, it is assumed that the WiMAX interface If2 is in the process of handoff from the VPLMN to the HPLMN 900. Further, when the MN 903 connects to the MAG 911 via the WiMAX access network 901, the MN 903 starts an attachment process to the LTE (or E-UTRAN) access network 902 via the LTE interface If1. Furthermore, it is considered that the mobility of the LTE interface If1 is managed by the PMIPv6 mechanism, and the use of the MIPv6-BU message is extremely limited as shown in Non-Patent Document 6.
  • the MN 903 refers to the prefix P2 notified by the MAG 911.
  • This prefix P2 is used to configure the CoA of the WiMAX interface If2.
  • the prefix P2 notified by the MAG 911 is advertised by the MAG 911 using a router advertisement (RA) mechanism or a WiMAX specific signaling mechanism (prefix advertisement signaling message 905 in the figure).
  • RA router advertisement
  • prefix advertisement signaling message 905 in the figure.
  • the MN 903 configures the CoA of the WiMAX interface If2, and transmits the MIPv6-BU message 906 to the LMA / HA 904 (BU1).
  • the LMA / HA 904 becomes a home agent of the MN 903.
  • the MIPv6-BU message 906 is a normal message without the BID option and the H flag. This operation is a normal operation for a MN operating in MIPv6.
  • the reason why the MIPv6-BU message 906 does not have a parameter indicating multihoming such as the H flag is that the MN 903 starts an attachment process to the LTE access network 902, but has not yet referred to the home prefix P1. It is. In this case, in LTE access, a delay occurs until setup of the PMIPv6 bearer or GTP (Generic Tunnelling Protocol) bearer is completed.
  • GTP Generic Tunnelling Protocol
  • One possible reason for this delay is excessive congestion, another reason is the path transfer delay through the home link due to geographical location, and another reason is E-UTRAN. Delay caused by a packet passing through many of the entities (eg, base station, evolved node B, S-GW, etc.).
  • the MN 903 does not know the type of the prefix P1 to be referred to via the LTE access (that is, whether it is a MIPv6 home prefix or another home network prefix). As a result, the MN 903 attaches via WiMAX and transmits a BU message 906 that does not have a parameter indicating multihoming in order to transmit and receive a flow related to the MIPv6 home prefix.
  • the MN 903 does not know the type of the prefix P1 advertised via the LTE interface If1. As described in Non-Patent Document 6, the MN 903 knows only the service type acquired via the LTE interface If1. Prefix management is performed by the LMA / HA 904, and since the LMA / HA 904 has already notified the MIPv6 prefix via the WiMAX interface If2, any prefix can be assigned to the PMIPv6 bearer.
  • the MAG 910 is triggered to set up a PMIPv6 bearer.
  • This PMIPv6 bearer for data traffic is set up by the PMIPv6-PBU message 907.
  • the MN 903 refers to the prefix P1 managed by the LMA / HA 904 in the message 908 from the MAG 910.
  • the prefix P1 referred to in the message 908 is managed by the PMIPv6 mechanism.
  • the prefix P1 referenced in the message 908 may be the MIPv6 home prefix of the MN 903 or may be some home network prefix managed by the LMA / HA 904.
  • the LMA / HA 904 manages both the MIPv6 cache and the PMIPv6 cache, the binding cache generated by the PMIPv6-PBU message 907 is suspended (inactive). The reason is that the MIPv6 cache generated by LMA / HA 904 is already active. Here, it is assumed that the priority of the MIPv6 cache is higher than that of the PMIPv6 cache.
  • the LMA / HA 904 attaches the MIPv6 home prefix P1 when the MN 903 attaches via the LTE interface If1.
  • the MN 903 refers to the MIPv6 home prefix P1 in the message 908, the MN 903 understands that it is connected to the home link.
  • the MN 903 refers to the prefix P2 in the message 905 and then refers to the home prefix P1 later in the message 908, the MN 903 understands that the home link and the external link are simultaneously connected.
  • the MN 903 when referring to the home prefix P1, the MN 903 sends another BU message 909 to the LMA / HA 904 (BU2), and changes the simultaneous binding of the home link and the external link (hereinafter referred to as home and away binding) to the LMA / HA.
  • home and away binding the simultaneous binding of the home link and the external link (hereinafter referred to as home and away binding) to the LMA / HA.
  • home and away binding LMA / HA 904
  • the important problem here is that the setup of PMIPv6 is delayed, so that the MN 903 performs double transmission of the MIPv6 BU message in order to realize simultaneous connection to the home prefix P1 of MIPv6 ( BU1, BU2 in the figure).
  • Patent Document 5 describes a method in which a MN located in an external domain configures a second HA and acquires a new home address. In addition, the MN uses this home address to bind the previous HA in the home domain to reduce BU signaling through the foreign domain.
  • the purpose of the method described in Patent Document 5 is to reduce location management signaling passing through the foreign domain.
  • this method does not relate to the signaling problem described in FIG.
  • the MN 903 in FIG. 15 performs double signaling in order to realize the setup of the simultaneous connection (connection) and to manage the mobility of the simultaneous connection (connection) when both the interfaces If1 and If2 move simultaneously.
  • BU1 and BU2 the MN 903 in FIG. 15 performs double signaling in order to realize the setup of the simultaneous connection (connection) and to manage the mobility of the simultaneous connection (connection) when both the interfaces If1 and If2 move simultaneously.
  • Patent Document 6 discloses a method of establishing a plurality of simultaneous connections and establishing flow-based routing using MN operating system software. However, Patent Document 6 does not disclose a method for solving the problem described in FIG.
  • Patent Document 7 discloses a method for establishing high-speed handoff by acquiring MN context information from an adjacent base station before handoff instead of transferring context information during handoff. Can be obtained quickly before handoff, thereby realizing high-speed handoff. However, this method increases the signaling load released to the network segment. The reason is that the target network entity interrogates multiple base stations to obtain the MN context information and achieve fast handoff.
  • the problem noted in FIG. 15 is to realize unnecessary high-speed connection (connection) between the WiMAX interface If2 and the 3G interface If1 by preventing unnecessary signaling.
  • the method described in Patent Document 7 uses one interface. Only the high-speed connection (connection) is established, and the problem noted in FIG. 15 is not solved.
  • Patent Document 8 discloses a method of reducing packet loss during handoff using a buffering technique. However, Patent Document 8 does not focus on the establishment of a high-speed connection (connection) or reducing the handoff delay of a terminal having a plurality of interfaces with less signaling.
  • Patent Document 9 discloses a method in which the MN simultaneously realizes home and away registration using the CoA of the interface connected to the home. However, Patent Document 9 does not directly handle the H flag indicating home and away, and provides no mechanism for realizing a high-speed connection setup in response to a delay in PMIPv6 setup. Not done.
  • Patent Document 10 discloses a method for resolving contention between PMIPv6-BU and CMIPv6-BU for one interface.
  • the problem described in FIG. 15 does not occur due to contention of location registration signals of the same interface, but rather because the PMIPv6 BU establishment is delayed from the MIPv6 BU establishment. Double registration (BU1, BU2 in the figure) is caused during If2 attachment. Therefore, the solution provided in Patent Document 10 does not solve the problem described in FIG.
  • the present invention can reduce signaling when a home node generates and manages a client-based binding cache when a mobile node having multiple interfaces roams in the home domain. It is a first object of the present invention to provide a binding cache generation method, a binding cache generation system, a home agent, and a mobile node.
  • the present invention also provides a binding cache generation method, a binding cache generation system, and a home that can reduce signaling of binding registration when a mobile node having a plurality of interfaces is simultaneously connected to a home link and an external link.
  • a second object is to provide an agent and a mobile node.
  • the present invention provides: A binding cache generation method when a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain roams within the home domain, Registering a first proxy binding cache for the first interface with a home agent of the home domain when the first interface of the mobile node connects to the home domain; Registering a second proxy binding cache for the second interface with the home agent when the second interface of the mobile node connects to the home domain via the local domain; The home agent generates a client-based binding cache for the second interface associated with the first and second proxy binding caches and refreshes the generated client-based binding cache by the mobile node The step of maintaining without being It was set as the structure which has.
  • the present invention provides A binding cache generation system when a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain roams in the home domain, Means for registering a first proxy binding cache for the first interface with a home agent of the home domain when the first interface of the mobile node connects to the home domain; Means for registering with the home agent a second proxy binding cache for the second interface when the second interface of the mobile node connects to the home domain via the local domain;
  • the home agent generates a client-based binding cache for the second interface associated with the first and second proxy binding caches and refreshes the generated client-based binding cache by the mobile node
  • the mobile node when a mobile node having a plurality of interfaces roams in the home domain, the mobile node does not frequently send a request message for refreshing the client-based binding cache in the home agent, thereby reducing signaling. it can.
  • the present invention provides The home agent in the binding cache generation system when a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain roams within the home domain, Means for registering a first proxy binding cache for the first interface when the first interface of the mobile node connects to the home domain; Means for registering a second proxy binding cache for the second interface when the second interface of the mobile node connects to the home domain via the local domain; Generating a client-based binding cache for the second interface associated with the first and second proxy binding caches and maintaining the generated client-based binding cache without being refreshed by the mobile node Means to It was set as the structure which has.
  • the present invention provides The mobile node in the binding cache generation system when a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain roams within the home domain,
  • the first proxy binding cache for the first interface is registered with the home agent of the home domain
  • the first and second interfaces for the first and second interfaces are registered with the home agent.
  • the present invention provides When a mobile node having a first interface communicable with a home domain and a second interface communicable with a local domain roams within the home domain, the mobile node uses a first for the first interface When a proxy binding cache is registered with the home agent, a client for the second interface associated with a second proxy binding cache for the second interface to a home agent in the home domain
  • the home agent in a binding cache generation system for sending a message requesting to generate and maintain a base binding cache
  • the second interface associated with the first and the registered second proxy binding cache when registering a second proxy binding cache for the second interface after receiving the request message Generating a client-based binding cache for the mobile node and notifying the mobile node not to send the request message again; It was set as the structure which has.
  • the present invention provides A binding cache generation method when a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain roams within the home domain, Registering a first proxy binding cache for the first interface with a home agent of the home domain when the first interface of the mobile node connects to the home domain; Registering a second proxy binding cache for the second interface with the home agent when the second interface of the mobile node connects to the home domain via the local domain; The mobile node generates a client-based binding cache for the second interface associated with the first and second proxy binding caches for the home agent, and the generated client base Requesting that the binding cache be maintained for a longer duration than normal without being refreshed by the mobile node; It was set as the structure which has.
  • the present invention provides A binding cache generation method when a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain roams within the home domain, Registering a first proxy binding cache for the first interface with a home agent of the home domain when the first interface of the mobile node connects to the home domain; Registering a second proxy binding cache for the second interface with the home agent when the second interface of the mobile node connects to the home domain via the local domain; The mobile node requesting the home agent to generate a client-based binding cache for the second interface associated with the first and second proxy binding caches registered by the home agent; , The home agent generates the requested client-based binding cache to set a longer duration than normal, and for the mobile node, the generated client-based binding cache for the duration Informing them not to refresh It was set as the structure which has.
  • the present invention provides A binding cache generation method when a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain roams within the home domain, Registering a first proxy binding cache for the first interface with a home agent of the home domain when the first interface of the mobile node connects to the home domain; Registering a second proxy binding cache for the second interface with the home agent when the second interface of the mobile node connects to the home domain via the local domain; The home agent sends a request to generate a client-based binding cache for the second interface to the mobile node when a second proxy binding cache for the second interface is registered And performing client-based routing associated with the first and second proxy binding caches; It was set as the structure which has.
  • the present invention provides a configuration in which a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain roams.
  • a binding cache generation method for generating a binding cache for first and second interfaces in a home agent of the mobile node When the second interface connects to the home domain via the local domain, the mobile node registers a client-based binding cache for the second interface with the home agent, and Requesting that a flag indicating simultaneous home and away connection be set in the client-based binding cache for the second interface when the proxy binding cache for the one interface is registered;
  • a proxy node of the mobile node registers a proxy binding cache for the first interface with the home agent when the first interface connects to the home domain;
  • the home agent setting the flag in the client-based binding cache for the second interface when the proxy binding cache for the first interface is registered; It was set as the structure which has.
  • the present invention provides a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain, when the mobile node roams.
  • a binding cache generation system for generating a binding cache for the first and second interfaces in a home agent of the mobile node, When the second interface connects to the home domain via the local domain, the mobile node registers a client-based binding cache for the second interface with the home agent, and Means for requesting that a flag indicating simultaneous home and away connection be set in the client-based binding cache for the second interface when the proxy binding cache for one interface is registered; Means for the proxy node of the mobile node to register a proxy binding cache for the first interface with the home agent when the first interface is connected to the home domain; When the home agent registers the proxy binding cache for the first interface, the home agent sets a flag indicating the simultaneous connection of the home and away in the client-based binding cache for the second interface. And It was set as the structure which has.
  • the present invention provides a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain, when the mobile node roams.
  • the mobile node in a binding cache generation system for generating a binding cache for the first and second interfaces in a home agent of the mobile node,
  • the client-based binding cache for the second interface is registered with the home agent, and the first interface Means for requesting the client-based binding cache for the second interface to set a flag indicating simultaneous home and away connection when the proxy binding cache is registered; It was set as the structure which has.
  • the present invention provides a mobile node having a first interface capable of communicating with a home domain and a second interface capable of communicating with a local domain, when the mobile node roams.
  • the home agent in a binding cache generation system that generates a binding cache for the first and second interfaces in a home agent of the mobile node,
  • the second interface connects to the home domain via the local domain, it registers a client-based binding cache for the second interface and a proxy binding cache for the first interface
  • the mobile node since the mobile node does not transmit the second registration message including the flag indicating the simultaneous connection of home and away to the home agent, the mobile node having a plurality of interfaces is simultaneously connected to the home link and the external link (connect). In this case, the signaling of the binding registration can be reduced.
  • the present invention when a mobile node having a plurality of interfaces roams in the home domain, it is possible to reduce signaling when the home agent generates and manages a client-based binding cache.
  • FIG. 3 is an explanatory diagram showing another form of the CMIPv6 cache generation / maintenance management request message in FIG. Explanatory drawing which shows the format of the CMIPv6 cache generation / maintenance management request message (in the case of L2 message) in FIG.
  • FIG. 3 is an explanatory diagram showing another form of the CMIPv6 cache generation / maintenance management request message in FIG.
  • Explanatory drawing which shows the format of the CMIPv6 cache generation / maintenance management request message (in the case of L2 message) in FIG.
  • FIG. 3 is an explanatory diagram showing a format of a CMIPv6 cache generation / maintenance management request message (in the case of a signaling packet having a new mobility extension header) in FIG.
  • Explanatory drawing which shows the format of the CMIPv6 cache generation / maintenance management request message (in the case of a BU message packet) in FIG.
  • movement of the mobile node of 1st Embodiment The flowchart for demonstrating operation
  • Explanatory drawing which shows the communication system and communication sequence of 5th Embodiment Explanatory drawing which shows the communication system and communication sequence of 8th Embodiment.
  • Explanatory drawing which shows the problem which this invention tends to solve
  • Explanatory drawing which shows the assumption system for demonstrating the subject of 9th Embodiment
  • Explanatory drawing which shows the assumption system for describing 9th Embodiment
  • Explanatory drawing which shows the binding cache entry in 9th Embodiment
  • generation request message in 9th Embodiment Explanatory drawing which shows the 3rd example of the packet structure of the H flag production
  • Block diagram functionally showing the configuration of the mobile node in the ninth embodiment The flowchart for demonstrating
  • an LMA that is the HA of the MN (hereinafter referred to as home LMA / HA) is located. It is determined that it is connected to the home PMIPv6 domain, and it is predicted that another interface will connect to the same home PMIPv6 domain. After the MN predicts in this way, if another interface connects to the same home PMIPv6 domain, the home LMA generates and maintains a CMIPv6 binding for the other interface that refers to the external prefix. Request to / HA.
  • the main object of the present invention is for the MN to simultaneously obtain the home and away advantages for all interfaces for which the MN referenced an external prefix in the home PMIPv6 domain, and the MN obtains the client-based BU
  • the registration is not performed continuously with the home LMA / HA.
  • FIG. 1 is a configuration diagram showing a communication system assumed in the first embodiment.
  • MNs 10A and 10B shown in FIG. 1 indicate that the same MN 10 has moved.
  • the MN 10 has a 3G cellular interface If1 and a WLAN interface If2 as a plurality of interfaces.
  • the MN 10A is located in the WLAN 30 and the WLAN interface If2 is connected to the MAG / ePDG 20, and the MN 10B is connected to the WLAN 31. It shows a state where the WLAN interface If2 is located and connected to the MAG / ePDG 21.
  • the plurality of interfaces of the MN 10 are limited to cellular interfaces (cellular interfaces defined by standardization organizations for 3GPP and other mobile phones such as 3G, 3.9G, 4G and later) and WLAN interfaces defined by IEEE802, WiFi, etc.
  • cellular interfaces cellular interfaces defined by standardization organizations for 3GPP and other mobile phones such as 3G, 3.9G, 4G and later
  • WLAN interfaces defined by IEEE802, WiFi, etc.
  • a WiMAX interface, a Bluetooth interface, or the like may be used.
  • the cellular interface is described as a 3G cellular interface
  • the serving gateway is described as a 3G serving gateway, but these are not limited to 3G.
  • the 3G cellular interface If1 is attached to one MAG / 3G serving gateway (S-GW) 22 of the home PMIPv6 network (domain) 100, and the range of the home PMIPv6 network 100 is such that the MN 10 is located in the WLAN 30. Even if it is located in the WLAN 31, the 3G cellular interface If1 is large enough to connect to one MAG22.
  • the home PMIPv6 network 100 is, for example, a 3GPP-HPLMN (Home Public Land Mobile Network) adopting the PMIPv6 protocol to provide a mobility management service in the network 100, and is a home network domain of the MN10.
  • the LMA / HA / home PDN gateway 40 is a home agent (hereinafter referred to as LMA / HA) of the MN 10.
  • the meaning of the home PMIPv6 network 100 is that the LMA / HA 40 is the MIPv6 HA of the MN 10 and further refers to the prefix P1 of the network 100 as the MIPv6 home prefix when the MN 10 roams the network 100.
  • the LMA / HA 40 accepts PMIPv6 binding and MIPv6 / CMIPv6 binding of the MN 10.
  • the home PMIPv6 network 100 In the home PMIPv6 network 100, only one network is shown in FIG. 1, but it is assumed that there are many cellular access networks. In the cellular access network, a router having a MAG function exists in the MAG / 3G S-GW 22, and this router is assumed to be the first hop router in the 3G access network. Furthermore, it is assumed that two WLANs 30 and 31 exist in the reception area of the 3G access network. Further, it is assumed that the WLANs 30 and 31 have MAG / ePDGs 20 and 21 that are gateway routers and trusted routers for accessing the 3GPP core network to forward traffic via the 3GPP architecture.
  • the WLANs 30 and 31 are continuous (that is, one is close to the other) and exist under a large-area 3G cell (that is, the network 100) having a router function in the MAG / 3G S-GW (hereinafter simply MAG) 22 It shall be.
  • the MN 10 when the MN 10 first attaches to the WLAN 30 and 3G network 100 as indicated by MN 10A and then attaches to the WLAN 31 and 3G network 100 as indicated by MN 10B, the MN 10 is always in motion. It is assumed that the MAG / 3G gateway 22 is connected. Since the network 100 is the home PMIPv6 domain of the MN 10, it is assumed that the MN 10 refers to the home MIPv6 prefix P1 of the network 100 when attached to the network 100. Further, since the LMA / HA 40 has the MIPv6 function, when the NAI of the MN 10 reaches the LMA / HA 40 with a PBU message, the home MIPv6 prefix P1 is given to the MN 10. The home MIPv6 prefix P1 may be statically configured in advance in the MN 10, or may be acquired by a dynamic mechanism such as a bootstrapping mechanism.
  • the MN 10 When the MN 10 first attaches to the MAG 22 that is the router of the network 100 via the 3G cellular interface If1, the MN 10 refers to the home MIPv6 prefix P1 that is the prefix of the network 100 in the router advertisement (RA) message 26 from the MAG 22. To do. Next, when the MN 10 connects to the MAG 20 that is the router of the WLAN 30 via the WLAN interface If2, the MN 10 refers to the external prefix P2 that is the prefix of the WLAN 30 by the RA message 25 from the MAG 20. It is important to understand why.
  • RA router advertisement
  • the prefix used for communication with the CN may be referred to as a home prefix, and the others may be referred to as external prefixes.
  • the MN 10 has only one home prefix P1 and home address (HoA) for the 3G cellular interface If1 and the WLAN interface If2.
  • HoA home address
  • the CMIPv6 registration 50 is executed for the LMA / HA 40.
  • the CMIPv6 registration 50 means that the care-of address (CoA) generated by the MN 10 from the external prefix P2 is bound to the HoA generated from the home MIPv6 prefix P1.
  • the MN 10 has the multihoming function described in Non-Patent Document 4, it is assumed that the home registration and the away registration are performed simultaneously by the CMIPv6 registration 50 in which the H flag is set. Further, the LMA / HA 40 has a multihoming function described in Non-Patent Document 4. In addition, it is assumed that the MN 10 communicates with a plurality of CNs 60 and 61 located in another packet data network (PDN), and selects a local address of the PMIPv6 domain and selects communication with the CNs 60 and 61.
  • PDN packet data network
  • the MN 10 roams to the WLAN 31 (MN 11B in the figure), and the MN 10 refers to the same external prefix P2 in the RA message 28 from the MAG 21 via the WLAN interface If2.
  • the MN 10 reaches the WLAN 31, the lifetime of CMIPv6 expires, and again to ensure reachability to the WLAN interface If2, or to obtain simultaneous use of both interfaces If1, If2, or WLAN
  • the MN 10 needs to transmit the CMIPv6BU message 51 with or without the flag H to the LMA / HA 40.
  • the CMIPv6 binding for the WLAN interface If2 is for the MN 10 to notify the LMA / HA 40 that the WLAN interface If2 can be reached using the CoA generated from the external prefix P2. It is. However, the actual reachability of the CoA generated from the external prefix P2 can be obtained by PMIPv6 binding (see FIG. 14) notified from the MAG 20 or 21. Therefore, it can be concluded that the content of the CMIPv6 binding for the WLAN interface If2 is static and related to the PMIPv6 binding for the WLAN interface If2. This is because the CoA generated from the external prefix P2 can obtain reachability by using information given by the PMIPv6 binding of the external prefix P2.
  • the signaling load related to the MN 10 is reduced. Increase. Therefore, this signaling (50, 51) can be optimized by enabling the LMA / HA 40 to generate and regenerate the CMIPv6 binding based on the PMIPv6 binding of the external prefix P2.
  • the CoA is composed of other prefixes that are not PMIPv6 local prefixes
  • the CoA is completely independent and is an independently routable address.
  • the CMIPv6 binding of the external prefix P2 is not an independently routable address, the CMIPv6 binding of the external prefix P2 clearly requires the PMIPv6 binding to ensure reachability.
  • the PMIPv6 binding and the CMIPv6 binding of the WLAN interface If2 can be optimized, the signaling load related to the MN 10 can be reduced, and the power consumption can be reduced. Furthermore, HoA information in CMIPv6 binding is not necessary. The reason is that the PMIPv6 binding of the home prefix P1 exists in the cache 213 (first entry E1 in FIG. 14) of the LMA / HA 40, and HoA information can be acquired. Even if the home prefix P1 does not exist in the cache 213 of the LMA / HA 40A, the LMA / HA 40 can obtain the prefix P1 by inquiring an AAA server (not shown).
  • the only content that the MN 10 needs to notify in this system is that it wishes to use the interface If2 referring to the external prefix P2 in the home MIPv6 network 100.
  • the contents of the PMIPv6 binding existing in the LMA / HA 40 are contents that can accurately generate the contents of the CMIPv6 binding.
  • FIG. 2 shows a case where the WLANs 30 and 31 are not continuously arranged as another system assumed in the first embodiment. This means that the cells of the WLANs 30 and 31 are not adjacent to each other.
  • the WLAN interface If2 is switched between the active mode and the idle mode. That's what it means. Since other assumptions are the same as those in FIG. 1, detailed description thereof is omitted.
  • MN10A, 10B, 10C, and 10D are the same MN10, and indicate that MN10 moves to the following position in the order of 10A ⁇ 10B ⁇ 10C ⁇ 10D.
  • MN10A When entering the WLAN 30 (first position)
  • MN10B When leaving the WLAN 30 (second position)
  • MN10C When entering WLAN 31 (third position)
  • MN10D When leaving the WLAN 31 (fourth position)
  • the MN 10 when the MN 10 attaches to the MAG 22 and the MAG 20 via the 3G cellular interface If1 and the WLAN interface If2 respectively in the first location (MN 10A), the prefixes in the RA messages 26 and 25 from the MAG 22 and MAG 20, respectively. Reference is made to P1 and P2. With reference to the external prefix P2, the MN 10 conventionally executes CMIPv6 registration 50 for the LMA / HA 40. Also, when the MN 10 moves and comes to the second location (MN 10B) that does not have connectivity with the WLAN 30, the MN 10 may conventionally transmit a CMIPv6 registration deletion 51.
  • the MN 10 when the MN 10 moves to a third position (MN 10C in the figure) that has connectivity with another WLAN 31, conventionally, the MN 10 transmits a CMIPv6 registration 52 for acquiring reachability to the WLAN interface If2. .
  • the MN 10 when the MN 10 moves to a fourth position (MN 10D in the figure) that has no connectivity with the WLAN 31, the MN 10 may transmit a CMIPv6 registration deletion 53 in the past.
  • the BU messages of the conventional CMIPv6 registrations 50 to 52 and CMIPv6 registration deletion 53 are all related to BU (PBU: Proxy Binding Update) registration and PBU registration deletion for PMIPv6 connection of the WLAN interface If2. Therefore, the CMIPv6 signaling (50 to 53) can be reduced and optimized by using the technique described in the first embodiment of the present invention. This is realized by using a method in which the WLAN interface If2 is attached to the network 100 which is the home PMIPv6 domain, and the contents of the CMIPv6 cache of the WLAN interface If2 can be generated by the LMA / HA 40. .
  • the MN 10 roams the home PMIPv6 domain 100 and all interfaces If1 and If2 are attached to the home PMIPv6 domain 100. Or provide a mechanism to estimate and optimize CMIPv6 signaling of interface If2 with reference to external prefix P2.
  • the MN 10 when the MN 10 predicts that all the interfaces If1 and If2 may be connected to the home PMIPv6 domain 100, the MN 10 communicates with the LMA / HA 40 from the CNs 60 and 61 to the MN10. In order to be able to use all the interfaces If1 and If2 simultaneously for one flow arriving at one HoA, a CMIPv6 binding cache of the interface If2 referring to the external prefix P2 is generated, and the MN 10 refreshes Request maintenance without having to. Note that the MN 10 may make the above request to the LMA / HA 40 after determining whether or not each interface is connected to the same home domain when the assigned prefixes are different.
  • an identifier such as a domain ID or domain number, an operator (PLMN: PublicPLMobile: Network) ID or an operator number indicating the connected domain is set.
  • PLMN PublicPLMobile: Network
  • an operator number indicating the connected domain.
  • FIG. 3 shows message sequences (1) to (11) according to the first embodiment
  • FIG. 4 shows a binding cache (BC) 213a in the LMA / HA 40.
  • the MN 10 has two interfaces, a 3G cellular interface If1 and a WLAN interface If2.
  • the MN 10 connects to the home MIPv6 domain (network 100) having one LMA / HA 40 via the 3G cellular interface If1.
  • LMA / HA 40 is also referred to as the home PDN gateway.
  • the MN 10 is in communication with a CN 60 that is connected to another data packet network.
  • the MN 10 has one home prefix P1 and one HoA for both the interfaces If1 and If2, and the CN 60 transmits a data packet to the HoA of the MN 10.
  • the MN 10 wants to receive the data packet using both the interfaces If1 and If2.
  • the MN 10 When the MN 10 detects an advertising beacon (not shown) from the MAG (MAG / 3G) 22 via the 3G cellular interface If1, the MN 10 transmits an L2 associate signal (L2 associate signal) 305 to the MAG22.
  • This beacon includes certain parameters such as a domain ID and a domain number that characterize the network type (whether or not PMIP is employed).
  • the MN 10 may store some static information regarding the domain ID of its home MIPv6 network 100 in its memory. Therefore, the MN 10 compares the domain ID obtained from the beacon with the above static information, and this domain is the home MIPv6 domain 100 of the MN 10 and the MAG 22 is the LMA / HA (LMA / HA / PDN40 of the home). Gateway) 40 may be inferred.
  • the MN 10 transmits an L2 security credential (credential) uniquely identifying the MN 10 using the L2 associate signal 305.
  • the MAG 22 transfers this certificate to an AAA server (not shown) and receives credential authorization from the AAA server.
  • the MAG 22 transmits a PBU message to the LMA / HA 40 and receives a PBAck (PBA) message as a response from the LMA / HA 40 as indicated by the PBU / PBA signaling 306.
  • PBA PBAck
  • the LMA / HA 40 creates the PMIPv6 cache of the interface If1 in the first entry E1 of the BC 213 shown in FIG. (3)
  • the MAG 22 transmits an RA message 307, and the MN 10 refers to the home MIPv6 prefix P1 of the MN 10 in the RA message 307.
  • CMIPv6 cache creation / maintenance management request message When the MN 10 refers to the home MIPv6 prefix P1 and learns that this domain is the home MIPv6 domain, the other interface (WLAN interface If2) of the MN 10 further becomes the same. It is predicted that there is a high possibility of connecting to the home MIPv6 domain 100 and the LMA / HA 40. Based on this prediction, the MN 10 transmits a CMIPv6 cache creation / maintenance management request message 308 according to the present invention to the LMA / HA 40 via the MAG 22 (and the interface If1).
  • the source address of the CMIPv6 cache creation / maintenance management request message 308 is the HoA of the MN 10 configured from the home MIPv6 prefix P1.
  • the purpose of the CMIPv6 cache generation / maintenance management request message 308 is to attach to the LMA / HA 40 the CMIPv6 binding cache of all interfaces of the MN 10 that are attached to the LMA / HA 40 and refer to the external prefix P2 (the third cache in FIG. 4). To generate and maintain it (see entry E3).
  • the CMIPv6 cache creation / maintenance management request message 308 has many contents, and includes identifiers (If2-ID) of all interfaces (If2) of the MN 10 except the 3G cellular interface If1 that refers to the home MIPv6 prefix P1.
  • This interface identifier (If2-ID) is used by the LMA / HA 40 to generate the CoA of the interface If2 of the MN 10 that refers to the external prefix P2 in the home MIPv6 domain. Note that the MN 10 may notify the CoA itself regarding all interfaces.
  • the interface If2 of the MN 10 in the CMIPv6 cache generation / maintenance management request message 308 is attached to the home MIPv6 domain 100 is determined by the LMA / HA 40 by the interface in the CMIPv6 cache generation / maintenance management request message 308. Trace is performed using the PMIPv6 connection (attachment) information of the MN 10 indicated by the identifier (If2-ID) and the interface identifier (If2-ID) in the PBU message (signaling 310) from another MAG 20.
  • the CoA is generated by the LMA / HA 40 connecting the PMIPv6 prefix P2 related to the interface If2 and the interface identifier If2-ID.
  • the CMIPv6 cache creation / maintenance management request message 308 further includes binding identifiers (BID) related to all interfaces (interface identifiers). However, when the MN 10 has only two interfaces If1 and If2, only the information of the flag H may be used. However, if two or more interfaces of the MN 10 are connected to the same home MIPv6 domain and distinguish between individual CMIPv6 caches and PMIPv6 caches, a BID is required for each cache.
  • BID binding identifiers
  • the CMIPv6 cache creation / maintenance management request message 308 may be preferably composed of a new mobility message having a new mobility extension header. This type of mobility message requires that the message identification number be assigned by IANA (Internet Assigned Numbers Authority). The interface identifier and BID are transmitted as options for the new mobility message. Alternatively, the mobility message may be a BU message including an interface identifier and a BID as a new option. Alternatively, the CMIPv6 cache generation / maintenance management request message 308 may be a message transmitted in the connection procedure (Attach Procedure) when connecting to the 3G network, or may be an L2 message with a security token addressed to MAG22. Good. However, the LMA / HA 40 can uniquely decrypt this security token.
  • connection procedure Attach Procedure
  • the MAG 22 can also transfer the contents of the cache generation / maintenance management request received by the L2 message to the LMA / HA 40 by the PBU message (306).
  • the LMA / HA 40 may verify the validity of the forwarded message using the security token and process the message.
  • CMIPv6 cache creation / maintenance management request message 308 There are many methods for transmitting the CMIPv6 cache creation / maintenance management request message 308 to the LMA / HA 40. If the cache can be identified using the interface identifier, it is not necessary to transmit the BID. Further, when the cache can be identified using the BID, it is not necessary to transmit the interface identifier. However, when the MN 10 generates a plurality of addresses from one prefix for one interface, it is appropriate to transmit the BID.
  • the CMIPv6 cache creation / maintenance management request message 308 is transferred from the interface If1 to the MAG 22 and tunneled to the LMA / HA 40.
  • the LMA / HA 40 receives the CMIPv6 cache creation / maintenance management request message 308, the LMA / HA 40 stores the information in the CMIPv6 cache creation / maintenance management request message 308 and connects to other interfaces of the MN 10 via other MAGs 20 in the network 100 ( monitor attachment).
  • the CMIPv6 cache generation / maintenance management request message 308 may be transmitted via the interface If2.
  • the CMIPv6 cache generation / maintenance management request message 308 may be transmitted from If2.
  • the message in the connection procedure (Attach Procedure) performed when If2 connects to the MAG 20 is used to request connection to the MAG 20, and at the same time, the generation / maintenance management of the CMIPv6 cache is requested.
  • the network to which If2 is connected is an Untrusted network of the Non3GPP network
  • generation and maintenance management of the CMIPv6 cache is performed in the SA (Security Association) establishment procedure (IKEv2) performed with the MAG 20 having the ePDG function. Request.
  • SA Security Association
  • the generation / maintenance management of the CMIPv6 cache is requested in the access authentication performed for the AGW (Access Gateway) or the L3 connection procedure. This eliminates the need for the MN 10 to transmit a BU message for generating / updating the CMIPv6 cache.
  • CMIPv6 cache As information requesting generation / maintenance management of CMIPv6 cache, when connecting to 3GPP / Non3GPP network and specifying the mobility protocol to be used (any one of PMIPv6, CMIPv6, MIPv4), simply specify PMIPv6 Instead of this, a value (for example, an indicator (PMIPv6 + CMIPv6) indicating that PMIPv6 is connected and a plurality of IFs are used at the same time) may be specified which also means that a CMIPv6 cache is generated.
  • PMIPv6 + CMIPv6 indicating that PMIPv6 is connected and a plurality of IFs are used at the same time
  • CMIPv6 cache generation / maintenance management request may be transmitted from If2 using a BU message or the like. Accordingly, if the BU message is transmitted only once at the beginning, it is not necessary to transmit a BU message for updating the CMIPv6 cache thereafter. Furthermore, CMIPv6 cache generation / maintenance management may be requested in the SA establishment procedure (IKEv2) performed with the LMA / HA 40 before transmitting the BU message.
  • IKEv2 message to be used is preferably an IKE_AUTH request message, an IKE_SA_INIT message, or the like.
  • the CMIPv6 cache generation / maintenance management request message 308 is received.
  • the LMA / HA 40 generates a CMIPv6 cache of If2 based on the PMIPv6 binding related to the existing interface If2, and further maintains the MN 10 without refreshing.
  • the CMIPv6 cache generated by the LMA / HA 40 includes the HoA obtained from the CMIPv6 cache creation / maintenance management request message 308, the CoA generated from the PMIPv6 prefix P2, and the interface identifier transmitted from the MN 10.
  • the interface identifier is 64 bits.
  • the LMA / HA 40 also associates the BID given by the MN 10 in the CMIPv6 cache creation / maintenance management request message 308 with this CMIPv6 binding.
  • the LMA / HA 40 further assigns a lifetime to this CMIPv6 binding. This lifetime is the same as the lifetime of the first PMIPv6 binding.
  • the second PMIPv6 binding is a binding related to the external PMIPv6 prefix P2 used to generate the CoA of the interface If2.
  • the MN 10 receives the WLAN beacon via the WLAN interface If2 after transmitting the message 308.
  • the MN 10 configures the address of the WLAN interface If2 from the prefix P2 advertised from the access router (AR) (not shown) of the WLAN 30, and then discovers the MAG (MAG / WLAN) 20 which is an ePDG
  • the IPSec tunnel setup with the MAG 20 Start the procedure.
  • the MN 10 transmits an IKEv2 message (IKEV2 authentication and setup) 309 with a connection authentication parameter to the MAG 20.
  • the IKEv2 message 309 may include information indicating that connection to the Non3GPP network connected via the MAG 20 is performed using PMIP.
  • the CMIPv6 cache generation / maintenance management request may be notified using the IKEv2 message 309 of (5) instead of the message 308.
  • the MN 10 is notified by the IKEv2 completion message of (9) whether or not the CMIPv6 cache generation / maintenance management request has been accepted.
  • the MAG 20 inquires an AAA server (not shown) and the MN 10 is authorized, it executes the PBU / PBAck signaling 310 with the LMA / HA 40 and sets the PMIPv6 routing state of the interface If2 and the external prefix P2. Generate.
  • the LMA / HA 40 generates the PMIPv6 binding cache which is the second entry E2, and then the MN 10 uniquely identified by the NAI has the interface If2 connected to the LMA / HA 40.
  • the CMIPv6 binding cache (third entry E3) of the interface If2 related to the PMIPv6 binding cache that is the second entry E2 is generated in accordance with the above-mentioned request for generation / maintenance management of the CMIPv6 cache. The detailed parameters of this cache have already been described in detail.
  • the LMA / HA 40 transmits a response message 311 to the request message 308 to the MN 10, and the interface If2 is connected to the same home MIPv6 domain 100 (LMA / HA 40), and the CMIPv6 for the interface IF2 Notifying that the cache has been automatically generated by the LMA / HA 40 and further that it is not necessary to send a CMIPv6 BU message (212 in FIG. 14) with a BID or flag H for the interface If2 Good.
  • the response message 311 is one of methods for notifying a response from the LMA / HA 40 to the first message 308, and a CMIPv6 registration deletion message (BA message) including a type indicating that it is a response to the message 308 can be used.
  • the LMA / HA 40 may send a new option in the tunnel setup complete message 312 to the MAG 20 to notify the MN 10 not to send the CMIPv6 BU message 212, and the LMA / HA40 notifies MAG20 or MAG22, and MAG20,22 notifies MN10 to MN10 by RA message or any other L3 message (including mobility header message) or L2 message. It may be. Many other methods are possible.
  • a tunnel setup completion message (IPSec tunnel Setup Completion) 312 is transmitted from the MAG 20 to the MN 10.
  • the IKEv2 procedure is completed, and an IKEv2 completion message (IKEv2 IP address / Prefix assignment) 313 is transmitted from the MAG 20 to the MN 10 to notify the MN 10 of the external prefix P2.
  • the MN 10 receives the IKEv2 completion message 313, it is not necessary to transmit the CMIPv6 BU message 212 for obtaining the packet addressed to the WLAN interface If2, the LMA / HA 40 generates a CMIPv6 binding for the WLAN interface If2, and the packet is Arrives at the WLAN interface If2.
  • the CN 60 transmits the data packet 314 addressed to the MN 10 to the HoA of the MN 10 configured from the prefix P1.
  • the LMA / HA 40 performs prefix-based routing using the first entry E1 (PMIPv6 entry) in the BC 213a, and the third entry in the BCE 213a. Perform HoA matching routing using the CMIPv6 cache of
  • the first encapsulation is tunneled to the CoA of the WLAN interface If2 of the MN 10. Then, one more encapsulation is required, and in the second encapsulation, the data packet 315 is tunneled to the address of the MAG 20.
  • the packet 315a encapsulated twice by the LMA / HA 40 is de-encapsulated by the MAG 20, and the original packet 315b encapsulated once is transferred to the MN 10 and completely de-encapsulated by the MN 10. It becomes.
  • the LMA / HA 40 appropriately encapsulates the data packet 314 using the BC 213a shown in FIG.
  • the packet destined for the WLAN interface If2 can be directly tunneled to the MN 10.
  • the destination address (the destination address of the tunneled packet) is the address of the MAG 20, and the CoA composed of the external prefix P2 and the HoA of the MN 10 are inserted into the routing header type 0 of the tunneled packet. According to this tunneling method, it is possible to prevent the overhead due to extra tunneling in the MAG 20 from increasing.
  • the third entry E3 (CMIPv6 cache duration 3) is maintained using the duration 1 of the first entry E1, regardless of the duration 2 of the second entry E2. Deleted when lifetime 1 expires.
  • the WLAN interface If2 of the MN 10 connects to a small non-contiguous cell of the WLANs 30 and 31, it often occurs that the WLAN interface If2 is handed off and is not under the control of the WLANs 30 and 31. In this case, it is beneficial that the CMIPv6 cache of the WLAN interface If2 is maintained based on the lifetime 1 of the PMIPv6 cache of the 3G cellular interface If1.
  • the LMA / HA 40 does not need to frequently generate the CMIPv6 cache of the WLAN interface If2.
  • the important point here is that the 3G cell (home PMIPv domain 100) is considerably larger than the WLAN 30, 31 and the 3G cellular interface If1 does not frequently handoff.
  • the CMIPv6 cache (lifetime 3) of the WLAN interface If2 of the MN 10 is maintained based on the lifetime 1 of the PMIPv6 cache of the 3G cellular interface If1, and the PMIPv6 cache (second entry E2) of the WLAN interface If2 is handed off. If valid before, the packet reaches the WLAN interface If2 via the MAG 302 using the second entry E2. On the other hand, when the PMIPv6 cache of the WLAN interface If2 becomes invalid due to the handoff, the packet addressed to the CoA related to the WLAN interface If2 is transmitted to the 3G cellular interface If1 using the first entry E1. In this case, it is assumed that the MAG 301 is provided with some validity information about the external prefix P2 by the LMA / HA 40 in the tunneled packet header.
  • the advantages of the first embodiment will be considered below.
  • the LMA / HA 40 since the LMA / HA 40 generates a CMIPv6 binding cache in response to the CMIPv6 cache generation / maintenance management request message 308 and maintains it without being refreshed by the MN 10, the MN 10 transmits the CMIPv6 registration message.
  • the LMA / HA 40 can know that it is necessary to search the PMIPv6 binding cache in order to route the data packet using the CMIPv6 binding.
  • the LMA / HA 40 When the LMA / HA 40 receives the CMIPv6 cache creation / maintenance management request message 308 and creates the CMIPv6 binding cache, the LMA / HA 40 may insert another parameter in the BC 213a indicating how to route the packet. it can. As a result, the LMA / HA 40 does not receive the CMIPv6 cache generation / maintenance management request message 308, and the LMA / HA 40 needs to identify how to route the packet using the CMIPv6 binding cache. The processing load of the HA 40 can be reduced.
  • the LMA / HA 40 does not generate the CMIPv6 binding cache as a response to the CMIPv6 cache generation / maintenance management request message 308, and does not generate the CMIPv6 binding cache.
  • the CMIPv6 binding cache is not marked as an entry that must perform recursive tracing. Therefore, the LMA / HA 40 knows that sending to the default router is sufficient for routing to the CoA acquired from the external domain.
  • MN 10 can use BU. There is no need to execute.
  • the present invention is useful when the MN 10 executes a flag H-based BU to request that all flows arrive only at the WLAN interface If2. MN 10 has a very confidential flow and may wish to have that flow tunneled directly from LMA / HA 40 to MN 10.
  • FIG. 5 shows another three forms of CMIPv6 cache generation / maintenance management request messages 306A, (307A1, 307A2), and (308A1, 308A2).
  • the MN 10 refers to the home prefix P1 by attaching to the home MIPv6 domain 100 via the 3G interface If1 and referring to the home prefix P1, as described above, the MN 10 refers to the WLAN interface If2 that refers to the external prefix P2 from the LMA / HA 40.
  • Various types of signaling can be performed to request the LMA / HA 40 to create and maintain a CMIPv6 binding cache.
  • the MN 10 transmits the CMIPv6 cache creation / maintenance management request message 306A directly to the LMA / HA 40.
  • the transmission source address of the message 306A is the HoA of the MN 10 configured using the home prefix P1, and the destination address is the address of the LMA / HA 40.
  • Message 306A may be constructed using a new header type of extension header. If this new header type of the extension header is used for the message 306A, the processing of the message 306A in the LMA / HA 40 is somewhat simplified. LMA / HA 40 knows what the new header type is from message 306A and knows how to process message 306A.
  • Information for identifying another interface such as the interface identifier and BID can be embedded as an option in the message 306A or in a data field.
  • Message 306A is tunneled from MAG 22 to LMA / HA 40. If the message 306A is a BU message described in MIPv6, the interface identifier and BID of the other interface are embedded as a mobility option in the BU message. This mobility option is a new type of option.
  • the CMIPv6 cache generation / maintenance management request can also be transmitted by the L2 message 307A1 transmitted to the MAG 22.
  • the L2 message 307A1 transmits the interface identifier and BID of the other interface.
  • the source address of the L2 message 307A1 is the L2 address of the interface If1 of the MN 10
  • the destination address is the L2 address of the ingress interface of the MAG22.
  • L3 messages a mobility header message is included
  • RS message a mobility header message
  • NS message a mobility header message
  • IKEv2 message authentication message
  • notification may be made in a connection procedure (Attach Request message) performed when connecting to the 3GPP network (MAG22).
  • Message 307A2 may be a PBU message or another signaling message with a new mobility extension header.
  • the LMA / HA 40 can process the PBU message to know the request for generation / maintenance management of the CMIPv6 cache.
  • the BID needs to be inserted as a new mobility option for that PBU message.
  • the interface identifier and BID of the other interface can be inserted into a normal field in the message.
  • the LMA / HA 40 configuration needs to be modified to understand this new message. The modified LMA / HA 40 knows how to process it when it receives this new message.
  • the MN 10 selects the home prefix P1 referred to via the 3G interface If1, the MN 10 first indicates that the DNS server 304A (DNS / SIP server / AAA in the figure) indicates the selection as indicated by the message 308A1. And the interface identifier and BID of the other interface can be provided in the message 308A1.
  • the DNS server 304A accepts this new prefix P1 and transfers the selected prefix P1 and the contents of the CMIPv6 cache creation / maintenance management request message 308 to the LMA / HA 40 with a message 308A2.
  • each method according to the CMIPv6 cache generation / maintenance management request message 306A, (307A1, 307A2), (308A1, 308A2) has a unique advantage.
  • the message (308A1, 308A2) two realizations can be achieved. The first is to request the LMA / HA 40 to generate and maintain the CMIPv6 cache when the home prefix P1 is selected. Second, when the MN 10 identifies the WLAN access point by sending the message 308A1, the MN 10 can acquire the ePDG address.
  • a frame 307B shown in FIG. 6A shows a frame structure when the message 308 is an L2 message 307A. From the top, a start flag (Flag) 300B, an address (Address) 301B, and a control (Control) 302B are sequentially shown. And a protocol ID (Protocol ID) 303B, information (Information) 304B, FCS (Frame Check Sequence) 305B, and an end flag (Flag) 306B.
  • the start flag 300B is a flag indicating the head of the frame 307B
  • the address 301B of the second field is a MAC (Media Access Control) address, and includes the source address and the destination address of the L2 packet.
  • the source address is the MAC address of the interface If1 of the MN 10
  • the destination address is the MAC address of the ingress interface (not shown) of the MAG 22.
  • the control 302B in the third field is information for identifying the type of the frame being used, and is important for the receiving side to correctly process the L2 frame 307B. Basically, the control 302B is used to identify the type of the frame 307B, that is, the type of the CMIPv6 cache creation / maintenance management request message 308 (307A).
  • the protocol ID 303B of the fourth field is a value for only the packet generated in the upper layer, and is all 0 when the message 308 (307A) is generated in L2. However, even if the message 308 can occur at L2, the decision to send the message 308 and the associated parameters embedded in the message 308 must come from L3.
  • the next field information 304B includes an interface identifier and a BID.
  • the FCS 305B field follows the information 304B, and the FCS 305B is calculated by the transmitting side and the receiving side so that the frame 307B is transmitted without error (error is identified and corrected).
  • the end flag 306B of the last field is basically used as a delimiter of the frame 307B to identify the end of the frame 307B.
  • the structure of the frame 307B is not necessarily the same as the structure shown in FIG. 6A without departing from the present invention.
  • the MN 10 can also transmit a packet for transmitting the CMIPv6 cache creation / maintenance management request message 308 using L3. If L3 signaling is used, the MN 10 can use a new mobility extension header or a BU message with new options.
  • FIG. 6B shows a signaling packet 315B having a new mobility extension header 310B.
  • the packet 315B will be described in detail below.
  • the first header of the packet 315B is a standard IPv6 header (IPv6 Header) 308B, and the IPv6 header 308B includes a source address where the HoA of the MN 10 is set and a destination address where the address of the LMA / HA 40 is set.
  • the next header of the packet 315B is a connection authentication header (Authentication Header) 309B, which has connection authentication data signed by a security key exchanged between the MN 10 and the LMA / HA 40.
  • the header 309B is a desirable field, but is not essential.
  • the third header is a new mobility extension header 310B, and the header 310B initially has a standard mobility extension header (Standard fields of mobility extension Header) 311B, and the standard mobility extension header 311B includes a protocol number, a mobility header. Includes type, checksum, etc.
  • the new mobility extension header 310B further has three standard fields 312B, 313B, 314B.
  • the first field (Number of interfaces) 312B indicates the number of interfaces If2 excluded by the MN 10 from the interfaces If1 referring to the home prefix P1.
  • the next field (interface identifier) 313B indicates the interface identifier If2-ID of the interface If2 of the first field 312B.
  • the third field (Binding identifier) 314B indicates one or more BIDs related to the interface identifier If2-ID of the second field 313B.
  • the packet 315B which is one desirable method, is shown.
  • FIG. 6C shows the structure of a BU message packet 323B as a third example for transmitting the CMIPv6 cache generation / maintenance management request message 308.
  • the first header of the packet 323B is an IPv6 header (IPv6 Header) 316B, and the next header is preferably a connection authentication header (Authentication Header) 317B.
  • the connection authentication header 317B is followed by a BU mobility extension header (Binding Update mobility extension Header) 318B.
  • the first field of the header 318B is a standard BU extension header 319B, which includes all the standard fields in the BU, such as lifetime and sequence number.
  • New option fields (Mobility3option 1,2,3) 320B, 321B, 322B are provided after the standard BU extension header 319B.
  • the first option field (Mobility new option 1) 320B is the number of interfaces (Number of interfaces).
  • the second option field (Mobility new option 2) 321B is an interface identifier (Interface Identifier) that the MN 10 wants to optimize, and the third option field (Mobility new option 3) is related to an interface.
  • One or more BIDs are included.
  • the MN 10 when the MN 10 having a plurality of interfaces If is attached to a network entity via a certain interface If, it checks whether or not it is attached to the PMIPv6 domain (step 400). If NO, a normal CMIPv6 operation is performed (step 402). In the case of YES at step 400, it is checked whether or not the prefix given to the interface If from the PMIPv6 domain is the home prefix P1, and further, it is checked whether or not the home prefix P1 is known ( Step 401). If YES, a CMIPv6 cache creation / maintenance management request message 308 with all interface identifiers is transmitted to the LMA / HA 40 (step 403).
  • step 401 determines whether the home prefix P1 is present. If NO in step 401, that is, if the home prefix P1 is not present, the PMIPv6 prefix is selected as the home prefix P1, and the HA address is requested and acquired from the DNS server (step 404).
  • the DNS server updates the home LMA / HA 40 with the home prefix P1 selected by the MN 10.
  • step 403 is executed.
  • NO in step 401 and not having the home prefix P1 implies that the MN 10 is attached to the external PMIPv6 domain, so the MN 10 performs a normal CMIPv6 operation. .
  • step 403 After the processing in step 403, whether an acknowledgment (Ack) for the CMIPv6 cache creation / maintenance management request message 308 has been received, or whether a response (flag) is described in the RA message or the IPsec tunnel establishment confirmation message. Is checked (step 405). If YES, the flag in the RA message is processed without transmitting the CMIPv6 BU message (step 406). This is because the CMIPv6 cache of the interface If2 that refers to the external prefix P2 given by the home LMA / HA 40 is generated and maintained by the home LMA / HA 40. If NO in step 405, it means that the interface If2 of the MN 10 is not connected to the same LMA / HA 40 using PMIPv6 binding. A BU message is transmitted (step 407).
  • a BU message is transmitted (step 407).
  • the LMA / HA 40 checks whether or not the received packet is a signaling packet from the MN 10 (step 500). If YES, it is checked whether the received packet is a CMIPv6 cache creation / maintenance management request message 308 (step 501). If NO, the received packet is processed by standard CMIPv6 operation (step 503).
  • step 501 an Ack message is transmitted in response to the CMIPv6 cache creation / maintenance management request message 308, and the interface identifier If-ID and BID in the CMIPv6 cache creation / maintenance management request message 308 are temporarily stored. (Step 502).
  • step 500 If it is determined in step 500 that the received packet is not a signaling packet from the MN 10, it is checked whether or not the received packet is a data packet addressed to the MN 10 that has transmitted the CMIPv6 cache generation / maintenance management request message 308 (step 504). If YES, the BC 213a is checked and the received packet is routed via all interfaces If of the MN 10 or via a specific interface If according to the preference set by the MN 10 (step 507). If NO in step 504, it is checked whether the received packet is a data packet from the MN 10 that has transmitted the CMIPv6 cache creation / maintenance management request message 308 (step 506). If YES, the received data packet is decapsulated and routed through the egress interface (step 505). At the time of decapsulation, the LMA / HA 40 checks whether the tunnel entry point is a source address that is effectively registered in the BC 213a.
  • the LMA / HA 40 checks whether the received packet is a signaling packet from the MAG indicating the PMIPv6 connection (attachment) of the MN 10 that has transmitted the CMIPv6 cache creation / maintenance management request message 308. (Step 508). If YES, the LMA / HA 40 transmits an Ack message, so that the other interface If2 of the MN 10 is attached to the same LMA / HA 40, and the Ack message has not been transmitted before. Notifies the MN 10 that it is not necessary to execute CMIPv6-BU. Alternatively, it is notified by the RA message that it is not necessary to execute CMIPv6-BU (step 509).
  • the Ack message does not need to be transmitted to the interface If2 that is first attached (attached) and refers to the external prefix P2. Also in step 509, the LMA / HA 40 generates a CMIPv6 cache of the interface If2 with reference to the external prefix P2.
  • the LMA / HA 40 checks whether the received packet is a signaling packet indicating the PMIPv6 deregistration of the MN 10 that has transmitted the CMIPv6 cache creation / maintenance management request message 308 from the MAG (step 508). 510). If YES, the LMA / HA 40 deletes the CMIPv6 binding (third entry E3) and the PMIPv6 binding (second entry E2) related to the CMIPv6 binding from the BC 213a (step 511). Here, the CMIPv6 binding refers to the binding generated in step 509 using the parameters of PMIPv6 binding. If NO in step 510, the LMA / HA 40 processes the received signaling packet with normal PMIPv6 operation (step 512).
  • FIG. 9 is a block diagram functionally showing the hardware, software, and firmware of the MN 10.
  • the functions of the MN 10 generally include a layer 3 protocol module 402A, an upper layer protocol module 401A that executes a layer (layer) protocol higher than layer 3, and a protocol that is a layer lower than layer 3 It is constituted by a lower layer protocol module 408A.
  • the lower layer protocol module 408A is composed of a plurality of layer protocol modules related to each interface If of the MN 10, and the functions of the lower layer protocol module 408A are mainly related to the control and transmission mechanism of the data link layer. is doing.
  • the layer 3 protocol module 402A includes five sub modules (units): an IPv6 routing unit 403A, a MIPv6 mobility management unit 404A, a home PMIP domain determination unit 405A, and a multihoming support unit 406A. It is constituted by a signaling optimization unit 407A.
  • the layer 3 protocol module 402A has an interface for transmitting a message between the units 403A to 407A.
  • Each unit 403A to 407A also has an associated binding.
  • IPv6 routing unit 403A is responsible for neighbor discovery, address configuration, and basic IPv6 routing mechanisms.
  • the MIPv6 mobility management unit 404A is responsible for MIPv6 mobility management mechanisms such as BU execution and deregistration.
  • the multihoming support unit 406A is responsible for the function of MONAMI6 (Non-Patent Document 4: Multiple CoA registration) such as generation of BID and attachment of flag H to a BU message.
  • the signaling optimization unit 407A is responsible for the function when the MN 10 configures the CMIPv6 cache creation / maintenance management request message 308 according to the present invention.
  • the home PMIP domain determination unit 405A is responsible for a function in determining whether the MN 10 is about to attach to the PMIPv6 domain.
  • each unit 403A-407A requires an appropriate software interface.
  • the upper layer protocol module 401A is in charge of upper layer protocols such as the transport layer and application layer provided in the MN 10.
  • upper layer protocols such as the transport layer and application layer provided in the MN 10.
  • the upper layer protocol module 401A is constituted by a plurality of blocks without departing from the present invention.
  • FIG. 10 is a block diagram functionally showing the LMA / HA 40.
  • the LMA / HA 40 is generally composed of two functional entities: a routing layer, that is, a layer 3 protocol module 501A, and a lower layer protocol module 511A that executes a lower layer protocol. Although not shown, an appropriate interface exists between the modules 501A and 502A.
  • the layer 3 protocol module 501A includes an IPv6 routing module 502A, a Monami6 routing module 503A, a PMIPv6 routing module 504A, and a signaling optimization support module 505A as four sub modules.
  • the IPv6 routing module 502A is responsible for basic routing mechanisms within one hop, LMA / HA 40 ingress and egress interface address configuration (not shown), and normal packet routing and neighbor discovery mechanisms. .
  • the Monami6 routing module 503A is a multihoming module having a HA function capable of processing multihoming signaling. Here, it is assumed that the module 503A can particularly process the flags H and BID, and can maintain a plurality of CMIPv6 binding entries for one HoA individually using the BID.
  • the IPv6 routing module 502A and the Monami6 routing module 503A have a signaling interface 510A, which is important for processing CMIPv6 type signaling and data packets and routing the data packets.
  • PMIPv6 routing module 504A is responsible for all purely LMA type functions. LMA type functions such as maintaining the PMIPv6 cache of MN10 with multiple interfaces If, tunneling packets to MN10 via MAG, processing received PBU messages, and generating PBA messages to be sent To do. Module 504A further has a signaling interface 509A with an IPv6 routing module 502A, which is used to process signaling and data packets using the PMIPv6 cache and route the data packets. .
  • each of the Monami6 routing module 503A and the PMIPv6 routing module 504A has its own BCE. Further, it is assumed that the PMIPv6 routing module 504A and the Monami6 routing module 503A are very strongly coupled.
  • the CMIPv6 cache is maintained separately from the PMIPv6 cache, the PMIPv6 routing module 504A and the Monami6 routing module 503A are shown separately, but the BID in the signaling message that separates the CMIPv6 cache and the PMIPv6 cache.
  • the CMIPv6 cache can overwrite the PMIPv6 cache when the flag H is not present, the PMIPv6 routing module 504A and the Monami6 routing module 503A, and the CMIPv6 cache and the PMIPv6 cache need to operate with each other.
  • the CMIPv6 cache and the PMIPv6 cache need to operate in close proximity to each other even though they are provided separately.
  • CMIPv6 cache and the PMIPv6 cache separately depending on the form actually used.
  • PMIPv6 routing module 504A and the Monami6 routing module 503A are provided separately as shown in FIG. 10, but the CMIPv6 cache and the PMIPv6 cache may be provided together.
  • the signaling optimization support module 505A is provided for processing the CMIPv6 cache generation / maintenance management request message 308 to generate a CMIPv6 cache in the Monami6 routing module 503A. It is assumed that the module 505A communicates with the module 503A via the signaling interface 507A.
  • the signaling interface 507A is used for transferring a message such as a CMIPv6 cache generation / maintenance / management request and parameters necessary for generating / maintaining the CMIPv6 cache.
  • the signaling optimization support module 505A also monitors whether another interface If2 of the MN 10 is attached to the PMIPv6 domain. For this monitor, the signaling optimization support module 505A requires a signaling interface 506 with the PMIPv6 routing module 504A. When the signaling optimization support module 505A learns from the PMIPv6 routing module 504A via the signaling interface 506 that the other interface If2 of the MN 10 is attached to the PMIPv6 domain, the MN 10 receives CMIPv6. To notify the MAG not to send the BU message. This notification information is configured by the signaling optimization support module 505A and transferred to the PMIPv6 routing module 504A.
  • the preferred configuration of the LMA / HA 40 has been described above, but the LMA / HA 40 can be configured without departing from the present invention.
  • CMIPv6 BU message transmission stop request signal 615 is added instead of the CMIPv6 cache generation / maintenance management request message 308.
  • the structural members and signals shown in FIG. 11 will be described briefly and repeatedly.
  • the MN 200 having a plurality of interfaces (3G cellular interface If1 and WLAN interface If2) is connected to the home PMIPv6 network (domain) 204 via both interfaces If1 and If2.
  • the 3G cellular interface If1 is connected to the LMA / HA 203 via the MAG 201 of the home PMIPv6 network 204, and the WLAN interface If2 is connected to the AR 207 of the WLAN 206 and the LMA via the MAG 202 of the home PMIPv6 network 204.
  • / HA 203 is connected.
  • the WLAN 206 is connected to the Internet 205, and the MN 200 is communicating with a CN 214 connected to the Internet 205.
  • the MN 200 when the MN 200 first attaches to the MAG 201 via the 3G cellular interface If1, the MAG 201 transmits a PBU message (signaling 208) to the LMA / HA 203, and the first entry in the BC 213 of the LMA / HA 203 E1 (PMIPv6 cache) is generated, and the MN 10 refers to the MIPv6 home prefix P1.
  • the MN 200 triggers the tunnel establishment for the MAG 202
  • the MAG 202 transmits a PBU message (signaling 209) to the LMA / HA 203, and a second entry E2 (PMIPv6 cache) is generated in the BC 213 of the LMA / HA 203.
  • the MN 20 refers to the external prefix P2 given by the LMA / HA 203 in the IPSec completion message 211.
  • the MN 200 wishes that the flow destined for the HoA configured from the home prefix P1 comes from the CN 214 via the WLAN interface If2. Also, as described above, the MN 10 has only one home prefix P1 and one HoA for the interfaces If1 and If2.
  • the MN 10 wishes that a flow destined for one HoA comes from the CN 214 via the WLAN interface If2, it sends a CMIPv6 BU message 212 with a flag H indicating attachment to the home to the LMA / HA 203.
  • the third entry E3 (CMIPv6 cache) is generated in the BCE 213 of the LMA / HA 203.
  • CMIPv6 BU message 212 with the flag H does not overwrite the PMIPv6 cache that is the first entry E1. Therefore, all three entries E1, E2, and E3 can coexist and the LMA / HA 203 can maintain heterogeneous bindings (PMIPv6 cache and CMIPv6 cache).
  • the LMA / HA 203 in the second embodiment needs the second entry E2 (PMIPv6 cache) to check the CMIPv6 BU message 212 and use the CMIPv6 registration (third entry E3). It has a function to detect. Furthermore, the LMA / HA 203 infers that the CMIPv6 BU message 212 does not need to continue and that the LMA / HA 203 can generate and maintain a CMIPv6 binding using the second entry E2 (PMIPv6 cache). Once determined in this way, the LMA / HA 203 notifies the MN 200 directly with a CMIPv6 BU message transmission stop request signal 615.
  • PMIPv6 cache second entry E2
  • the MN 200 When the MN 200 receives the signal 615, the MN 200 does not transmit the CMIPv6 BU message 212 any more. However, the case where the MN 200 refers to a new prefix that is not the external prefix P2 in the domain 204 and the case where the LMA / HA 203 notifies the MN 200 that the optimization service is canceled are excluded.
  • the home LMA / HA 203 searches for a CoA composed of an external prefix P2 that does not belong to the home LMA / HA 203 (searches whether the CoA binding has a PMIPv6 binding). Since the LMA / HA 203 does not receive the CMIPv6 cache creation / maintenance management request message 308 as in the first embodiment from the MN 200, the LMA / HA 203 knows where the WLAN interface If2 of the MN 200 is attached. Since it has not been obtained, the above CoA search is a wasteful effort.
  • LMA / HA 203 requires a BU message from WLAN interface If2 of MN 200 to identify possible optimizations.
  • the CMIPv6 BU message 212 from the WLAN interface If2 of the MN 200 is unnecessary, and the CMIPv6 cache generation / maintenance management request message 308 is sufficient.
  • the advantage of the second embodiment is that it is not necessary to predict whether the MN 200 is connected to the home PMIPv6 domain 204, but the MN 200 transmits the interface identifier and BID of the WLAN interface If2 to the LMA / HA 203. There is a need to do.
  • the LMA / HA 203 executes all processes necessary for reducing the signaling load. When there are many LMA / HAs, this can be realized even if these LMA / HAs 203 are subjected to a lot of processing load.
  • FIG. 11 it is assumed that the MN 200 knows that it is connected to the home PMIPv6 domain 204 via the WLAN interface If2.
  • the information can be obtained from the MAG 202 that the MN 200 refers to the beacon of the WLAN 206 and the MAG 202 has established a tunnel with the LMA / HA 203.
  • the MN 200 learns from the above information that it can execute the CMIPv6 BU signaling optimization, and transmits the CMIPv6 BU message 212 to the LMA / HA 203.
  • the BU message 212 includes the BID of each interface If1 and If2 attached to the LMA / HA 203, and describes a very long lifetime in them.
  • the point of the third embodiment is that the MN 200 does not need to refresh the BU when the MN 200 attaches for a very long lifetime.
  • the MN 200 when the MN 200 roams in the home PMIPv6 domain 204 longer than the lifetime described in the BU message 212, it is necessary to refresh the third entry E3. Also, if the LMA / HA 203 does not accept a very long duration (it cannot guarantee a long duration mobility service), the MN 200 knows the maximum duration that the LMA / HA 203 will accept, and the BU message Notification may be made at 212. In addition, the LMA / HA 203 may accept or reject the BU from the MN 200 depending on the state of its own load. Therefore, LMA / HA 203 may not be able to accept very long lifetime bindings or static or hard code bindings. In this case, the LMA / HA 203 notifies the MN 200 whether or not the long-lived binding can be accepted, and accordingly determines whether or not the MN 200 should send the BU message 212 including the long-lived period. Also good.
  • the WLAN 206 is not continuous like the WLANs 30 and 31 shown in FIG. 2, if the new external prefix P2 is given to the WLAN interface If2 when the WLAN interface If2 is turned on and off, the external prefix P2 Alternatively, it may be determined that the BU message 212 having a long lifetime is not transmitted. As a result, an external prefix that is used for a relatively short period of time can be treated as a normal binding cache. Further, since the MN 200 has a plurality of interfaces If1 and If2, a BU message 212 having a long lifetime is transmitted to each interface If1 and If2.
  • the main advantage of the third embodiment is that the change in the configuration of the MN 200 is minimal.
  • the MN 200 with the extended MIPv6 task can solve the problem of signaling storm without changing the software.
  • a fourth embodiment will be described with reference to the same FIG.
  • the LMA / HA 203 can perform the signaling optimization of the second embodiment when the CMIPv6 BU message 212 is received from the MN 200, as a response to the BU message 212
  • a binding confirmation (BA) message (not shown) describing a very long lifetime is sent back to the MN 200.
  • the MN 200 does not send a new BU message 212 to the LMA / HA 203 until the lifetime in this BA message expires.
  • the MN 200 needs to refresh the CMIPv6 cache when the lifetime in the BA message expires.
  • the main advantage of the fourth embodiment is that more processing load can be shifted to the network side instead of the MN side.
  • the operation of the LMA / HA 203 can be simplified as compared with the second embodiment.
  • MN 200, MAG 201, 202, LMA / HA 203, home PMIPv6 domain 204, Internet 205, WLAN 206, and CN 214 are the same as in FIG. 11, but the CMIPv6 BU message 212 and the third in BC 713 shown in FIG. There is no entry E3.
  • the MN 200 when the MN 200 first attaches to the MAG 201 via the 3G cellular interface If1, the MAG 201 transmits a PBU message (signaling 208) to the LMA / HA 203, and A first entry E1 (PMIPv6 cache) is generated in the BCE 713 of the HA 203, and the MN 10 refers to the MIPv6 home prefix P1.
  • the MN 200 triggers the tunnel establishment for the MAG 202
  • the MAG 202 transmits a PBU message 709 to the LMA / HA 203, and a second entry E2 (PMIPv6 cache) is generated in the BCE 713 of the LMA / HA 203.
  • the LMA / HA 203 when the LMA / HA 203 generates the second entry E1 (PMIPv6 cache) in the BCE 713, it can be inferred that both PMIPv6 caches belong to the same MN 200 using the NAI. Accordingly, the LMA / HA 203 instructs the MAG 202 with the PBA message 711 that is a response to the PBU message 209 so that the CMIPv6 BU message 212 shown in FIG. 11 is not transmitted when the MN 200 refers to the external prefix P2. The MAG 202 notifies the MN 200 with an RA / IKEv2 completion message 712. Further, the LMA / HA 203 instructs the MAG 202 with the PBA message 711 to notify the MAG 202 to load balance the flow for the home prefix P1 to the plurality of interfaces If1 and If2.
  • the configuration of the LMA / HA 203 is such that the LMA / HA 203 identifies the first and second entries E1 and E2 of the BCE 713 belonging to the same MN 200, and further sends packets addressed to the home prefix P1 to the PMIPv6 cache (second entry) of the external prefix P2. It has been changed to identify that it is routable via E2).
  • the LMA / HA 203 notifies the MAG 202 of the home prefix P1 with the PBA message 711 transmitted for the external prefix P2, and the MAG 202 transmits a special option with the RA message 712.
  • This special option is a flag for notifying the MN 200 not to transmit the CMIPv6 BU message 212 shown in FIG. 11 when the MN 200 refers to the external prefix P2.
  • the important point here is that since the MAG 202 is notified of the home prefix P1 by the PBA message 711, when the packet for the home prefix P1 is routed to the MAG 202, the MAG 202 configured the packet from the external prefix P2. The address can be transferred to the WLAN interface If2.
  • the problem of the fifth embodiment will be considered in comparison with the first embodiment.
  • the configuration of the MAGs 201 and 202 in the home PMIPv6 domain 204 has been changed.
  • the MN 200 may desire that packets for the home prefix P1 (eg, for VoIP with high QoS) come only to the stable 3G cellular interface If1. That is, you may not want to come to both interfaces If1 and If2. If the MN 200 has such a desire, it is useless for the LMA / HA 203 to notify the MAG 202 of the home prefix P1.
  • P1 eg, for VoIP with high QoS
  • the MN 200 may not desire this signaling optimization service.
  • SHIM6 Site Multi-homing by IPv6 Intermediation
  • the LMA / HA 203 should ideally perform this signaling optimization only after obtaining some trigger from the MN 200. The reason is that only the MN 200 knows the state (provided protocol) of the MN 200 and the desired content.
  • the advantage of the fifth embodiment is that the MN 200 does not need to perform any signaling in the home PMIPv6 domain 204 in order to realize multihoming.
  • the MN 200 can receive the packet addressed to the home prefix P1 by all the interfaces If1 and If2.
  • a sixth embodiment will be described with reference to the same FIG.
  • the MN 200 desires that the packet with the home prefix P1 reaches both the interfaces If1 and If2 (or If2).
  • the MN 200 has one home prefix P1 and one HoA for the interfaces If1 and If2.
  • the MN 200 notifies the LMA / HA 203 of the home prefix P1, and requests the LMA / HA 203 to notify the MAG 202 related to the external prefix P2 for the home prefix P1. Basically, notification signaling from the MN 200 is required only once.
  • the MN 200 notifies the LMA / HA 203 of the home prefix P1, and requests the LMA / HA 203 to notify the MAG 202 connected to another interface If2 of the MN about the home prefix P1.
  • This notification message is a new type of explicit mobility signaling message.
  • the LMA / HA 203 receives this notification message, the LMA / HA 203 notifies the MAG 202 that the home prefix P1 is a valid prefix.
  • the LMA / HA 203 can notify the MAG 202 of the prefixes P1 and P2 when the interface If2 of the MN 200 is attached to the MAG 202.
  • the MAG 202 can transfer this information to another MAG to which the interface If2 of the MN 200 is attached (CT). .
  • CT interface If2 of the MN 200 is attached
  • a packet arriving at the HoA of the home prefix P1 in the LMA / HA 203 is tunneled via the MAG 202. Also, whenever the interface If2 of the MN 200 moves, the LMA / HA 203 transmits a notification message about the home prefix P1. Furthermore, tunneling via MAG 202 is not desirable for highly confidential data flows, but tunneling via MN 200 is possible.
  • the main advantage of the sixth embodiment is that the MN 200 does not need to predict that the other interface If2 is attached to the home PMIPv domain 204, and the interface as in the first embodiment. There is no need to transmit the interface identifier of If2. Compared to the first embodiment, in the sixth embodiment, the signaling load coming from the MN 200 can be slightly reduced.
  • the seventh embodiment will be described with reference to the same FIG.
  • the MN 200 notifies the MAG 202 of the home prefix P1.
  • the MAG 202 obtains a verification of the home prefix P1 from the LMA / HA 203.
  • the MN 200 has already attached (attached) the interface If1 to the MAG 201, and is referencing the home prefix P1 by the RA message 210.
  • the MN 200 notifies the MAG 202 of the home prefix P1 in a tunnel setup message during the initial connection (initial ⁇ attachment) between the WLAN interface If2 and the MAG 202.
  • the MAG 202 acquires the information of the home prefix P1
  • the MAG 202 transmits the information to the LMA / HA 203 with a PBU message 709.
  • the LMA / HA 203 receives the PBU message 709 from the MAG 202, the LMA / HA 203 notifies the MAG 202 that the external prefix P2 and the home prefix P1 are valid prefixes.
  • the MN 200 attaches to each MAG in the home PMIPv domain 204 via the WLAN interface If2, the MN 200 transmits the above tunnel setup message to each MAG for verification of the home prefix P1.
  • the MAG 202 has obtained confirmation of the home prefix P1 from the LMA / HA 203, this information can be transferred to another MAG via CT.
  • each MAG can transfer a home prefix P1 and an external prefix P2 in CT, and all MAGs attached to the WLAN interface If2 of the MN 200 have a valid home prefix P1 and an external prefix P2. . For this reason, the data packet destined for the flow of the home prefix P1 can be tunneled to each MAG connected to the WLAN interface If2.
  • signaling is generated in the core network in order to acquire the packet of the home prefix P1 by both the interfaces If1 and If2. For example, signaling that inquires the LMA / HA 203 about the validity of the home prefix P1 and signaling that the MN 200 always forwards the home prefix P1 when the WLAN interface If2 is attached to the home PMIPv domain 204 are added signaling.
  • the main advantage of the seventh embodiment is that the MN 200 only needs to notify the MAG of the home prefix P1. This notification is possible with the L2 signal. Therefore, in order to realize the signaling optimization, the signaling load generated from the MN 200 can be reduced as compared with the first embodiment.
  • an eighth embodiment will be described with reference to FIG.
  • the LMA / HA 203 can transmit the flow of the home prefix P1 via the MAG to which the external prefix P2 is given.
  • the MAG connected to the interface If2 of the MN 200 has a certain function with respect to the home prefix P1 of the MN 200. This function may be provided directly to the MAG by the LMA / HA 203, or may be given to the first MAG and transferred to the other MAG via CT.
  • the MN 200 having a plurality of interfaces If1 and If2 first connects to the home PMIPv domain 202 via both the interfaces If1 and If2.
  • the MN 200 first connects to the MAG 201 via the interface If1, and then connects to the MAG 202 via the interface If2.
  • the WLAN 206 to which the MN 200 first connects is connected to the Internet 205.
  • the home PMIPv domain 202 is similarly connected to the Internet 205.
  • the MN 200 When the MN 200 first attaches to the MAG 201 via the interface If1, the MAG 201 transmits a PBU message (not shown) to the LMA / HA 203, and a first entry E1 (PMIPv6 cache) is generated in the BC 813 of the LMA / HA 203. Also, the MN 200 refers to the home prefix P1 from the RA message (not shown).
  • the MN 200 triggers the tunnel establishment to the MAG 202 via the interface If2
  • the MAG 202 transmits a PBU message (not shown) to the LMA / HA 203, and a second entry E2 (PMIPv6 cache) is generated in the BC 813 of the LMA / HA 203. .
  • the LMA / HA 203 can use the first and second entries E1 and E2 to tunnel a packet addressed to the HoA configured from the home prefix P1 to the MAG 202, and the MAG 202 notifies the home prefix P1. Shall be.
  • the MN 200 when the MN 200 is still attached to the MAG 201, the WLAN interface If2 is disconnected from the MAG 202 and attached to the MAG 803 of another external PMIPv6 domain 810.
  • the MN 200 basically refers to the external prefix, that is, the local breakout prefix, from the LMA / HA 808 of the external PMIPv6 domain 810 via the WLAN interface If2.
  • the MN 200 transmits a CMIPv6 BU message 812 to the home LMA / HA 203 via the external PMIPv6 domain 810, and a third entry E3 (CMIPv6 cache) is generated in the BC 813 of the LMA / HA 203.
  • CMIPv6 cache third entry E3
  • the MN 200 transmits a CMIPv6 BU message 812 with a flag H, and desires the LMA / HA 203 to transmit a packet addressed to the HoA via the WLAN interface If2.
  • the WLAN interface If2 is attached to the LMA / HA 808 of the external PMIPv6 domain 810 and the third entry E3 (CMIPv6 cache) is generated in the BC 813 of the LMA / HA 203
  • the MAG 202 In some cases, the registration of the second entry E2 is not canceled and remains. In this case, a packet loss occurs. The reason is that the LMA / HA 203 may route the packet using the second entry E2.
  • the MN 200 when the MN 200 sends a CMIPv6 BU message 812, it is desirable that the MN 200 attaches a new option to the BU message 812 to notify that the second entry E2 is no longer valid.
  • an external prefix P2 can be sent in an option in the BU message 812.
  • the MAG function coexists in an access gateway (AGW) located in the wireless access network. Furthermore, when the MN attaches to an unreliable WLAN access network, the MAG function coexists in the ePDG. Further, when the MN attaches via 3G access such as E-UTRAN, UTRAN, and GERAN, the MAG function coexists in the S-GW (Serving Gateway). Furthermore, in the 3GPP architecture, the LMA / HA function coexists in P-GW (Packet data network Gateway).
  • AGW access gateway
  • the home and away binding is set when the PMIPv6 bearer is set up by the MN to the LMA / HA. Request to generate.
  • the ninth embodiment will be described in detail with reference to FIGS.
  • the MN 1003 first attaches to a home domain EPC (evolved packet core) 1000 via the WiMAX interface If2 (and WiMAX access network 1001, MAG1006), and then LTE (long- The term evolution) interface If1, that is, the 3G interface If1 (and the access network 1002 such as UTRAN, LTE, E-UTRAN, MAG1005) is attached to the EPC 1000.
  • EPC evolved packet core
  • LTE long- The term evolution
  • the MN 1003 refers to the prefix P2 managed by the MAG 1006 via the signaling message 1007 after successful authentication by the MAG 1006. Similar to FIG. 15, the mobility of the WiMAX interface If2 is managed by the MIPv6 mechanism. Further, when the MN 1003 starts a process of attaching (attaching) via the WiMAX interface If2, the MN 1003 starts a process of attaching (attaching) using the LTE / 3G interface If1. When the MN 1003 first refers to the prefix P2 via the WiMAX interface If2, the MN 1003 internally predicts and determines the prefix type that will be referred to internally via the LTE / 3G interface If1. Note that the mobility of the prefix P1 referred to via the LTE / 3G interface If1 is managed by the PMIPv6 mechanism.
  • the MN 1003 can predict the MIPv6 home prefix P1 to be referred to via the LTE / 3G interface If1 connected to the E-UTRAN access network 1002 based on many factors. As the first factor, as shown in Non-Patent Document 6, MIPv6-BU cannot be executed via the LTE / 3G interface If1, that is, the network-based local mobility management protocol is used. Therefore, the MN 1003 uses the WiMAX interface If2. It may be predicted that the LMA / HA 1004 will always give the home prefix P1 continuously so that the session can continue even if the power is turned off.
  • the second factor that contributes to the above prediction is that if the MN 1003 subscribes to only one service type indicated by one APN (Access Point Name) and the WiMAX binding is set up in the LMA / HA 1004, The MN 1003 predicts that the LMA / HA 1004 grants the MIPv6 home prefix P1 via the 3G / LTE interface If1 in order to realize multihoming for the UE 1003.
  • APN characterizes certain service types in 3GPP. A detailed description of APN is described in Non-Patent Document 6. When the MN 1003 subscribes to only one PDN, it holds only one APN, so that the LMA / HA 1004 may assign the same MIPv6 prefix when connected via the LTE interface If1. It is reasonable to predict.
  • the LMA / HA 1004 may allocate another prefix via the LTE interface If1 in order to access another PDN because it holds a plurality of APNs.
  • the P-GW may assign prefixes from different PDNs to different interfaces. That is, in order to realize multihoming, the prefix from PDN1 is assigned via WiMAX interface If2, and the prefix from PDN2 is assigned via 3G interface If1.
  • the 3G interface If1 is more real time as a network policy. Since the flow is ideal, there is a case where it is desired to pass the flow from the WiMAX interface If2 to the 3G interface If1 side. When the network wants to pass this flow to the 3G interface If1 side, it is necessary to transmit the MIPv6 prefix as the PMIPv6 prefix via the 3G interface If1. If the MN 1003 knows the above network policy, it can easily be predicted that it will refer to the MIPv6 home prefix P1 via the 3G interface If1.
  • the fourth factor that contributes to the above prediction is a policy that is statically configured in the MN 1003.
  • the MN 1003 may preconfigure a policy of “I want to make the LTE link the MIPv6 home link” in the HSS (Home Subscription Server).
  • the MN 1003 configures this static policy for reasons such as “I want to use real-time flows at the same time”.
  • a PDN that provides a real-time service is an IMS (IP Multimedia Service) type. Another reason may be that the MN 1003 desires that LTE access provides better QoS for real-time services and real-time flows come to the 3G interface If1.
  • the MN 1003 can use a decision criterion for predicting that “the MIPv6 home prefix P1 will be referenced via the 3G interface If1”.
  • MN 1003 completes this decision process, it sends a BU message 1008 to LMA / HA 1004.
  • the BU message 1008 for example, new information requesting the LMA / HA 1004 to generate a home and away binding when the PMIPv6 bearer for the MIPV6 home prefix P1 is set up can be embedded.
  • information embedded in the BU message 1008 is referred to as a “home binding generation request” or an “H flag generation request”.
  • the BU to be transmitted to the LMA / HA 1004 to generate the home and away binding.
  • the BU message 1008 including a home binding generation request needs to be transmitted instead of the plurality of BU messages (BU1, BU2) shown in FIG.
  • the LMA / HA 1004 processes the “home binding generation request” in the BU message 1008 and transmits a response message or a BA message 1010 to the MN 1003.
  • the BA message 1010 notifies the MN 1003 “whether or not to support a request for generating an H flag when the PMIPv6 bearer for the MIPV6 home prefix P1 is set up”.
  • the BU message 1008 may also include some information identifying the PMIPv6 bearer in addition to a trigger that generates an H flag when this PMIPv6 bearer is set up. This identification information may be a parameter such as an interface identifier or APN (Access Point Name).
  • the signaling message 1008 can be transmitted in a variety of different types, and is disclosed in the embodiments described below.
  • the important information embedded in the signaling message 1008 is to inform the LMA / HA 1004 to generate an H flag in the H flag field of the CMIPv6 cache 1608 shown in FIG. 17 when the PMIPv6 bearer for the MIPV6 home prefix P1 is set up. This is a “home binding generation request” to be requested.
  • the message 1008 can include information requesting that the MIPv6 home prefix P1 be transmitted as the PMIPv6 prefix via the LTE interface If1 when the LMA / HA 1004 does not have the mechanism. Requesting the MIPv6 home prefix P1 as the PMIPv6 prefix is optional. This request depends on the policy of the MN 1003 regarding whether or not to realize simultaneous binding for the flow of the home prefix P1.
  • message 1008 can include other information for realizing home and away binding in the LMA / HA 1004.
  • message 1008 may include a trigger to request that LMA / HA 1004 generate a BID value for interface If1 connected to home.
  • this BID generation trigger is transmitted in message 1008, the LMA / HA 1004 generates a BID value for the cache of the PMIPv6 bearer connected to the home.
  • the LMA / HA 1004 ensures that this BID value is different from the BID value of the interface being handled by the CMIPv6 mechanism. Setting a filtering rule for interface If1 connected to home using the current mechanism by having a BID value generated for interface If1 connected to this home Becomes easier.
  • the MN 1003 can describe the BID option in the message 1008. This BID option is used to indicate the BID value of the home binding. Using the BID option, the MN 1003 can describe the BID value of the home binding by itself instead of causing the LMA / HA 1004 to generate the BID value.
  • the LMA / HA 1004 processes the message 1008 and waits for the PBU message 1009 for the interface If1 to arrive at the LMA / HA 1004.
  • the LMA / HA 1004 generates the CMIPv6 binding in the entry 1608 shown in FIG. 17, but does not yet insert the H flag in the generated CMIPv6 binding.
  • the PBU message 1009 for the interface If1 arrives from the MAG 1005
  • the LMA / HA 1004 generates a PMIPv6 binding in the entry 1607 shown in FIG. 17, and inserts an H flag in the CMIPv6 binding.
  • the MN 1003 can arrive via the interface If1 connected to the home (interface) and the interface If2 connected to the foreign domain (connect).
  • the MN 1003 can cause the flow addressed to the MIPv6 home prefix P1 to arrive via all the interfaces If1 and If2, and can realize multihoming.
  • the home prefix P1 is advertised with a message 1010 by the MAG 1005 on the LTE access network 1002 side.
  • the home prefix P1 is advertised by the MME (Mobility Management Entity) to the MN 1003 that has successfully attached.
  • MME Mobility Management Entity
  • the LTE / 3G interface If1 is booted up while the WiMAX interface If2 is performing a handoff, or both interfaces If1 and If2 are running simultaneously. It is clear that the present invention can also be applied to the case where the mobility is executed.
  • the message 1008 includes information regarding home binding (eg, BID option (including HoA in CoA field))
  • LMA / HA 1004 applies the information to the generated home binding.
  • FIG. 17 shows the structure of a binding cache entry (BCE) 1600 that is relevant only to a specific MN 1003. Since the LMA / HA 1004 has a home agent function and a local mobility anchor function, it is considered that the BCE 1600 generated for the MN 1003 has both a PMIPv6 cache and a CMIPv6 cache. It should be appreciated by those skilled in the art that the BCE 1600 has multiple MN binding cache entries served by the LMA / HA 1004. This binding cache structure is very specific.
  • the CMIPv6 entry has priority over the PMIPv6 entry.
  • the binding cache is generated using appropriate multihoming parameters such as the H flag and / or BID option as shown in FIG. 17, each CMIPv6 and PMIPv6 binding cache entry 1608, 1607 Have the same priority, the flow destined for the MN 1003 can be routed using either one of the entries 1608 and 1607.
  • a first field 1601 in the BCE 1600 shown in FIG. 17 indicates a home network prefix (home prefix) P1 or home address (HoA) related to the MN 1003.
  • the home network prefix P1 is generally associated with PMIPv6 binding (1607 in FIG. 17), and the home address (HoA) is generally associated with CMIPv6 binding (1608 in FIG. 17).
  • the CMIPv6 binding may also be related to the home network prefix P1.
  • the second field 1602 indicates the egress address (MAG CoA) of the MAG 1005 when the field 1602 is generated by the PMIPv6 entry 1607.
  • a field 1602 generated by the CMIPv6 entry 1608 indicates a CoA (MN CoA) related to the MN 1003 interface.
  • a third field 1603 indicates an interface identifier (IF-ID) of the MN 1003.
  • the field 1603 can indicate a MAC address or an interface identifier given to a specific interface.
  • the IF-ID field 1603 is essential in the case of PMIPv6 binding, but is not used in the case of CPMIPv6 binding.
  • the next field 1604 indicates a network access identifier (NAI) of the MN 1003, and this NAI may be a temporary identifier or a permanent identifier of the MN 1003.
  • NAI network access identifier
  • the NAI field 1604 is essential in the case of PMIPv6 binding, but is not essential in the case of CPMIPv6 binding.
  • the next field 1605 indicates a binding identifier (BID) for a particular binding and is used to identify a particular binding associated with a particular home address.
  • BID binding identifier
  • the last field 1606 indicates the H flag associated with the CMIPv6 entry 1608.
  • the LMA / HA 1004 does not insert the H flag into the H flag field 1606 of the CMIPv6 entry 1608.
  • the LMA / HA 1004 waits until the PMIPv6 cache is generated.
  • the LMA / HA 1004 inserts the H flag into the H flag field 1606 of the CMIPv6 entry 1608.
  • a CMIPv6 request for generating an H flag arrives when a PMIPv6 cache has already been generated, the LMA / HA 1004 generates a CMIPv6 entry 1608 with an H flag.
  • the MN 1003 generates the home and away simultaneous registration in the LMA / HA 1004.
  • the H flag can be associated with PMIPv6.
  • the BID option value in field 1605 may indicate home and away simultaneous registration.
  • the packet 1410 shown in FIG. 18A includes fields of an IPv6 header 1411, an authentication header 1412, and a new mobility extension header 1413.
  • the fields of the new mobility extension header 1413 indicate a standard field 1414 and an “H flag insertion request”.
  • New field 1415 is included.
  • a packet 1430 shown in FIG. 18B includes fields of an IPv6 header 1431, an authentication header 1432, and a new mobility extension header 1433.
  • the fields of the new mobility extension header 1433 include a standard field 1434, a BID option 1435 field, and “ A new field 1436 indicating “H flag insertion request” is included.
  • an IKEv2 message performed when the MN 1003 is connected to the network may be used.
  • 18C and 18D the “H flag insertion request” is transmitted in the normal BU header type.
  • 18C includes IPv6 header 1421, authentication header 1422, and BU header 1423 fields, and BU header 1423 fields include standard field 1424 and new mobility option 1425 fields.
  • the fields of the new mobility option 1425 include an “H flag insertion request” and an interface identifier for identifying the PMIPv6 bearer.
  • 18D includes an IPv6 header 1441, an authentication header 1442 and a BU header 1443.
  • the BU header 1443 includes a standard field 1444, a BID option 1445 field, and an “H flag insertion request”.
  • Each field of the new mobility option 1445 indicating “”.
  • the source address in the IPv6 headers 1411, 1421, 1431, 1441 is the CoA of the MN 1003, and the destination address is the address of the LMA / HA 1004 that is the home agent of the MN 1003.
  • the “H flag insertion request” may be notified from the MN 1003 to the MAG 1005, which is the proxy node of the MN 1003, using the signal of the L2 frame 307B shown in FIG. 6A in the first embodiment.
  • the MN 1003 can use PCO (Protocol Configuration Option).
  • the MAG 1005 notifies this “H flag insertion request” to the LMA / HA 1004 with the PCO in the PBU message 1009 or the new option or new flag.
  • LMA / HA 1004 refers to this PCO, or a new option or new flag, and inserts an H flag into the CMIPv6 cache when the PMIPv6 bearer for home prefix P1 is set up. Note that a message specific to the access network may be used as the signal.
  • the field of the protocol ID 303B in the L2 frame 307B shown in FIG. 6A has a value only when the packet is generated in a layer higher than L2.
  • the value of the protocol ID 303B is all 0 when the “H flag insertion request” occurs in L2. However, even if the “H flag insertion request” occurs in L2, the decision to transmit the “H flag insertion request” and the related parameters embedded in the L2 frame 307B must come from L3.
  • the “H flag insertion request” is transmitted in the field of information 304B.
  • the field of information 304B may carry a BID for CMIPv6 binding.
  • the “H flag insertion request” can also be transmitted in a frame structure other than the L2 frame 307B shown in FIG. 6A.
  • the MN 1003 may notify the MAG 1005, which is a proxy node of the MN 1003, of a request (BID insertion request) for inserting the BID into the CMIPv6 cache using the L2 frame 307B illustrated in FIG. 6A.
  • This BID can be given by the MN 1003 or generated by the MAG 1005.
  • the MAG 1005 may associate a special flag in the PBU message 1009 to request the LMA / HA 1004 to use the interface identifier as the BID of the CMIPv6 cache.
  • the important point here is that when using the L2 message, the CMIPv6-BU message 1008 sent for the WiMAX interface If2 does not include a trigger to insert the H flag when the PMIPv6 bearer is set up. That is.
  • FIG. 19 is a block diagram showing a functional architecture 1300 for explaining the configuration of the MN 1003 according to the ninth embodiment.
  • the functional architecture 1300 shows all the software, hardware and firmware necessary to prepare the MN 1003.
  • the functional architecture 1300 includes three sub modules, specifically, a lower layer protocol module 1301, a layer 3 protocol module 1302, and an upper layer protocol module 1303.
  • the lower layer protocol module 1301 includes a plurality of lower layer protocol modules related to the respective interfaces If1 and If2 of the MN 1003.
  • the plurality of lower layer protocol modules mainly serve as a link layer control and transmission mechanism.
  • Layer 3 (L3) protocol module 1302 has five sub-modules: multihoming support unit 1304, IPv6 routing unit 1305, MIPv6 mobility management unit 1306, H flag generation request unit 1307, and home prefix reference.
  • a prediction unit 1308 is included.
  • the L3 protocol module 1302 also has an interface (not shown) for exchanging messages between the units 1304 to 1308. Each unit 1304 to 1308 has an associated binding list when necessary.
  • the IPv6 routing unit 1305 performs neighbor discovery, address configuration and basic IPv6 routing mechanisms, and the MIPv6 mobility management unit 1306 performs MIPv6 mobility management functions such as binding update and deregistration mechanisms.
  • the multihoming support unit 1304 executes a multiple registration function for generating a BID in a BU message and attaching an H flag.
  • the H flag generation request unit 1307 has a function of configuring a “home binding generation request” that requests the LMA / HA 1004 to generate an H flag when the PMIPv6 bearer for the home prefix P1 is set up.
  • the home prefix reference prediction unit 1308 has a function of predicting the home prefix reference based on many different factors. The prediction of home prefix references has already been explained in detail. Those skilled in the art will appreciate that each unit 1304-1308 requires an appropriate software interface when implemented.
  • the upper layer protocol module 1303 has functions of upper layer protocols such as a transport layer and an application layer provided in the MN 1003.
  • upper layer protocols such as a transport layer and an application layer provided in the MN 1003.
  • step 1100 the operation of the MN 1003 (referred to as UE (User Equipment) in 3GPP) will be described with reference to the flowchart shown in FIG.
  • the MN 1003 first executes step 1100 to predict whether or not the home prefix P1 may be referred to via the 3G interface If1. Since this prediction process has already been described in detail, it will not be repeated here. If the determination in step 1100 is NO, that is, if the MN 1003 cannot predict with a high probability that the home prefix P1 will be referenced via the 3G interface If1, the process proceeds to step 1101, and normal operation, that is, BU without an H flag is performed. Send a message. In step 1101, a normal BU message for the WiMAX interface If2 is transmitted without attaching parameters related to multihoming and without embedding new options.
  • step 1100 determines whether the “home binding generation request” is added to the home agent (LMA / HA) 1004, and the home prefix P 1.
  • the MN 1003 transmits the new BU message 1008 (that is, including a new option) in step 1102, and then waits for an ACK signal (BA message 1010) as a response from the HA.
  • the MN 1003 When the MN 1003 receives the ACK signal, the MN 1003 checks the ACK signal to check whether there is a “response that the LMA / HA 1004 sets the H flag when the PMIPv6 bearer for the home prefix P1 is set up”. (Step 1103). When the HA sets the H flag (YES in step 1103), the MN 1003 refers to the home message P1 via the LTE interface If1 and sends the BU message with the H flag (909 shown in FIG. 15) to the LMA / It is determined not to transmit to the HA 1004 (step 1104).
  • step 1103 means that the LMA / HA 1004 does not accept the BU message 1008 sent by the MN 1003 in step 1102, or the LMA / HA 1004 does not want to assign the MIPv6 home prefix P1 via the LTE interface If1. Is the case. In this case, the MN 1003 returns to the normal operation and waits until the home prefix P1 is referred to. When the reference is made, the BU message (909 shown in FIG. 15) with the H flag set is transmitted to the HA. (Step 1105).
  • the LMA / HA 1004 is a first step 1500 where the received message requests a new type of message (BU message 1008, below) to request that the H flag be inserted when the PMIPv6 binding for the home prefix P1 is generated. ("H flag insertion request message"). If NO in step 1500, the LMA / HA 1004 performs processing of other standard signaling messages such as PBU or BU messages in step 1501 as normal operation.
  • BU message 1008 new type of message
  • step 1500 the LMA / HA 1004 checks in step 1502 whether the PMIPv6 binding (entry 1607) has been set up when the H flag insertion request message arrives. If NO in step 1502, the process proceeds to step 1503. In this case, the CMIPv6 binding (entry 1608) was generated first, but it is considered that the H flag is inserted when the PMIPv6 bearer of the LMA / HA 1004 is set up. Therefore, the LMA / HA 1004 routes the packet using the CMIPv6 binding in the entry 1608 in step 1503.
  • LMA / HA 1004 since the PMIPv6 bearer of LMA / HA 1004 has already been set up, LMA / HA 1004 generates a CMIPv6 cache with an H flag in entry 1608 in step 1504.
  • FIG. 22 assumes a system in which a chain (Chained Scenario) is formed between 3GGP networks.
  • an S-GW (Serving GateWay) 1206 in an EPC (VPLMN) 1201 that is an external domain operates as a mobility management anchor in the middle of a route with respect to the MN (UE 1200).
  • the ePDG 1207 which is a MAG that attaches to the UE 1200, transmits a binding parameter related to the address of the P-GW (Packet data network GateWay) 1205 to the S-GW 1206, which is a mobility management anchor in the middle of the route.
  • the S-GW 1206 transmits the received binding parameter to the P-GW 1205, and generates a PMIPv6 binding to the P-GW 1205.
  • 3GGP implements mobility management using the above-described chain architecture, particularly when UE 1200 is located in VPLMN 1202 and the node that manages the prefix is P-GW 1205 located in HPLMN 1201. If there is no mobility management anchor along the path, a new PMIPv6-BU message must be transferred from the VPLMN 1202 to the HPLMN 1201 each time the UE connects to the MAG, thus incurring a handoff delay.
  • the S-GW 1206 does not need to send a binding parameter to the P-GW 1205 and is located in the VPLMN 1201
  • the S-GW 1206 does not need to send a binding parameter to the P-GW 1205 and is located in the VPLMN 1201
  • the 3GGP chain system will be described in detail.
  • the main purpose in this scenario is to show that the home prefix P1 is delayed in a very realistic network architecture of 3GGP.
  • UE 1200 is connected to EPC (Evolved Packet Core) 1201 which is a 3GPP core network and HPLMN (Home Public Land Mobile Mobile Network) of UE 1200 via two WiMAX interfaces I and a WLAN interface. )is doing. Further, it is conceivable that the UE 1200 configures the P-GW 1205 of the EPC 1201 as a home agent.
  • EPC Evolved Packet Core
  • the UE 1200 is connected via a WiMAX access network 1204 with a WiMAX interface and attached via an EPC 1202 whose WLAN interface is a WLAN access network 1203 and a VPLMN (visited public public mobile mobile network).
  • the WLAN interface is connected to the 3GPP chain architecture.
  • the mobility of the WiMAX interface is managed by the MIPv6 mechanism, and the mobility of the WLAN interface is managed by the PMIPv6 mechanism.
  • UE 1200 wants to realize multihoming by simultaneous connection.
  • the UE 1200 attaches a prefix advertisement message 1209 to the prefix P2 routed to the access gateway (AGW) 1208 to configure CoA after the completion of access authentication. Get in. Furthermore, it is assumed that the UE 1200 starts a process for attaching via the WLAN interface. However, after successful WLAN access connection authentication and authorization authentication, the ePDG 1207 on the VPLMN 1202 side sends a binding parameter to the S-GW 1206 (signaling message 1211), and the S-GW 1206 further receives PMIPv6. The binding is transmitted to the P-GW 1205 on the HPLMN 1201 side (PBU message 1212).
  • PBU message 1212 PBU message 1212
  • the UE 1200 when the UE 1200 predicts that the home prefix P1 may be referred to via the WLAN interface, the UE 1200 transmits a BU message 1210 including a “home binding generation request” to the P-GW 1205.
  • the P-GW 1205 first generates a CMIPv6 cache without an H flag by referring to the BU message 1210, and inserts the H flag into the CMIPv6 cache when receiving the PBU message 1212 from the S-GW 1212.
  • the P-GW 1205 can generate the home and away binding of the UE 1200 when it first receives the BU message 1210 from the UE 1200 before the PBU message 1212 from the S-GW 1212. It is.
  • the LTE interface is first connected (connected) to the MAG 1705 via the LTE access network 1702, and then connected to another MAG 1707 by the movement of the MN 1703. Further, the MN 1703 is connected to the MAG 1705 and the MAG 1707 via the 3G LTE access network 1702.
  • the MN 1703 generates a CoA using the prefix P2 given in the router advertisement message 1708 from the MAG 1706 on the WiMAX side before referring to the home prefix P1 in the message 1711 from the MAG 1705 before handoff.
  • a “home binding generation request” is transmitted to the LMA / HA 1704 with a BU message 1709.
  • PMIPv6-PBU message 1710 (PBU1) from the MAG 1705 before handoff arrives at the LMA / HA 1704, an H flag is inserted into the CMIPv6 binding cache in the LMA / HA 1704.
  • the BU message 1709 including the “home binding generation request” does not delete the home and away registration even if the handoff PMIPv6-PBU message 1712 (PBU2) does not include multihoming parameters such as BID and H flag. New information to notify the LMA / HA 1704.
  • the PMIPv6-PBU message 1712 (PBU2) does not overwrite the home and away state in the LMA / HA 1704, and does not overwrite the home and away state. Do not delete registration.
  • the home and away state can be deleted only when the MN 1703 indicates to the LMA / HA 1704 to cancel the registration of the interface connected to the home or the outside.
  • the deregistration of the interface connected to the home is performed by the PMIPv6 mechanism, and the deregistration of the interface connected to the outside is performed by the CMIPv6 mechanism.
  • Information on simultaneous home and away connection can be transmitted to a new MAG 1707 after handoff as a new trigger.
  • an L2-specific message or an L3-specific message such as a message related to neighbor search can be used.
  • MAG 1707 sends this information to LMA / HA 1704 in a handoff PBU message 1712 (PBU2).
  • PBU2 handoff PBU message 1712
  • each functional block used in the description of the above embodiment is typically realized as an LSI which is an integrated circuit. These may be individually made into one chip, or may be made into one chip so as to include a part or all of them.
  • the name used here is LSI, but it may also be called IC, system LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • the home agent has a lifetime of the first proxy binding cache for the first interface.
  • the client-based binding cache for the second interface is deleted when it expires.
  • a first proxy binding cache for the first interface is provided to the home agent. After being registered, the mobile node sends a request message to the home agent to generate and maintain a client-based binding cache for the second interface; If the second proxy binding cache for the second interface is registered after the home agent receives the request message, the home agent is associated with the first and registered second proxy binding cache.
  • the present invention has an effect that when a mobile node having a plurality of interfaces roams in a home domain, signaling when generating and managing a client-based binding cache in a home agent can be reduced. It can be used when the home domain is a 3G PMIPv6 domain or the like. In addition, the present invention has an effect of reducing signaling of binding registration when a mobile node having a plurality of interfaces is simultaneously connected to a home link and an external link. It can be used in the case of a PMIPv6 domain.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

　複数のインタフェースを有するモバイルノードがホームドメイン内をローミングする場合に、ホームエージェントにおいてクライアントベースのバインディングキャッシュを生成して管理する場合のシグナリングを減少する技術が開示され、その技術によればＭＮ１０は、インタフェースＩｆ１を介してホームＭＩＰｖ６プリフィックスＰ１を参照してホームＭＩＰｖ６ドメインであることを知得すると、ＭＮ１０の他のＷＬＡＮインタフェースＩｆ２が更にこの同じホームＭＩＰｖ６ドメイン１００及びＬＭＡ／ＨＡ４０に接続する可能性が高いことを予測し、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８をＬＭＡ／ＨＡ４０に送信する。ＬＭＡ／ＨＡ４０は要求メッセージ３０８を受信して、ＷＬＡＮインタフェースＩｆ２のＰＭＩＰｖ６キャッシュに関連するＣＭＩＰｖ６キャッシュを生成してＭＮ１０によりリフレッシュされることなく維持管理する。

Description

バインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノード
　本発明は、複数のインタフェースを有するモバイルノードがホームドメイン内をローミングする場合のバインディングキャッシュ生成方法及びバインディングキャッシュ生成システムに関する。
　本発明はまた、前記バインディングキャッシュ生成システムにおけるホームエージェント及びモバイルノードに関する。
　現在、多くの通信装置がＩＰｖ６（Internet Protocol version 6）を用いて通信を行っている。また、モバイル装置に対してモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）は、下記の非特許文献１に示すようなＭＩＰｖ６（Mobility Support in IPv6）を開発している。非特許文献１におけるモビリティサポートは、ホームエージェント（ＨＡ）と呼ばれるエンティティをモバイルノード（ＭＮ）のホームネットワークに導入することにより実現している。ＭＮはＨＡに対し、外部リンクで取得した気付アドレス（ＣｏＡ）を、バインディング・アップデート（ＢＵ）メッセージと呼ばれるメッセージを用いて登録する。ＨＡはＢＵメッセージにより、ホームリンクから取得したアドレスであるホームアドレス（ＨｏＡ）とＭＮのＣｏＡの間にバインディング（位置情報）を生成することができる。ＨＡはバインディングにより、ＭＮのＨｏＡあてのメッセージをインタセプトし、ＭＮのＣｏＡあてのパケットにカプセル化して転送する。なお、このパケットカプセル化は、受信したパケットを新しいパケットのペイロードにセットする処理であり、パケットトンネル化として知られている。
　ＭＩＰｖ６における問題の１つは、ネットワーク接続（attachment）が変更するときごとや、バインディングの有効期間が満了するときに、ＭＮが１つ又は複数のＨＡと通信相手（Correspondent Node：ＣＮ）を更新する必要があることにある。この更新により、高速で移動するＭＮが無線ネットワークに放出するシグナリングの負荷が増大する。さらに、ネットワーク接続（attachment）の変更ごとにＣＮとの間で行うハンドオフ確立時間（経路最適化が使用されているとする）は、ネットワーク接続（attachment）の変更ごとにＲＲ（Return Routability）メッセージとＢＵメッセージの送受信が必要となるため、多くの時間を要する。このため、フロー又はコネクションに関連するセッションの間、ハンドオフ確立にかなりの時間を要するので、ジッタやパケットロスが発生する。このようなジッタは、ＶｏＩＰ（Voice over IP）や、マルチメディア及びビデオストリーミングのようにリアルタイムなアプリケーションにとっては好ましくない。さらに、パケットロスは、重要なテキストやデータの情報を伝送するフローにとっては好ましくない。パケットロスはさらに、ＴＣＰ（Transmission Control Protocol）が重要なデータ、アプリケーションの転送に使用される場合、ＴＣＰのスループットを減少させる。
　ＭＩＰｖ６の問題に注目すると、焦点は現在、ネットワークベースのローカル・モビリティ管理（Network-based Local Mobility-Management：ＮｅｔＬＭＭ）プロトコルにシフトされる。ＩＥＴＦのＮｅｔＬＭＭワーキンググループは、このプロトコルの作業を行っている。ネットワークベースのローカル・モビリティ管理は、地理的にローカルなネットワーク・セグメントに位置するＭＮのモビリティを、ＭＮそれ自体よりもネットワーク・エンティティにより管理することに言及している。
　ＭＮにとって透過的なネットワークベースのローカル・モビリティ管理の目的を達成するために、ＭＮはローカルドメイン内のどこでも同じプリフィックスを参照することを必要とする。上記のプリフィックスは、ルーティング階層の上位に位置するルータから取得されなければならない。そのルータは望ましくは、ローカル・モビリティ管理の利点が取得可能なようにローカルドメイン内のすべてのＭＮのデフォルト・ルーティングパスに位置する。上記のルータは、上記のプリフィックスのルートであって、上記のプリフィックスに対する到達性の情報すなわちルーティング情報（プリフィックスベースのルート）を有しなければならない。結果的に、このプリフィックスベースのルートは、ネットワーク・エンティティにより生成されなければならない。
　ＮｅｔＬＭＭワーキンググループにより検討されている特別なネットワークベースのローカル・モビリティ管理プロトコルは、下記の非特許文献２に開示されているＰＭＩＰｖ６（Proxy Mobile Internet Protocol version 6）である。ＰＭＩＰｖ６のプロトコルは主に、ＣＭＩＰｖ６（Client Mobile IPv6）スタックを有しない通常のＩＰｖ６ホストに対して、ネットワークのローカルな部分におけるモビリティ管理サービスを提供するために設計されている。にもかかわらず、ＰＭＩＰｖ６はＣＭＩＰｖ６スタックを有するノードにも有用である。その理由について説明すると、ＣＭＩＰｖ６スタックを有するＭＮが外部のＰＭＩＰｖ６ドメインに位置していて、そのローカルドメイン内のあるインタフェースを介して同じプリフィックス（外部のローカル・モビリティ・アンカー（ＬＭＡ）／ＨＡにおいてルーティングされる外部のＰＭＩＰｖ６ローカルプリフィックス）を参照する場合、そのＭＮは如何なるグローバルな登録も実行する必要がない。さらに、上記のＣＭＩＰｖ６スタックを有するＭＮは、ホームドメイン内にローミングしたとき、地理的な位置を変更しているにもかかわらず、自身のホームネットワーク・プリフィックスを継続して参照して位置登録に参加する必要がない。
　以下に、非特許文献２に開示されているＰＭＩＰｖ６の概略を説明する。あるＭＮがあるＰＭＩＰｖ６に接続（attach）したとき、そのＭＮは、モバイル・アクセス・ゲートウェイ（ＭＡＧ）とアソシエート中に、自身のネットワーク・アクセス識別子（ＮＡＩ）を提供する。ＭＡＧとは、ＭＮが直接に接続（attach）しているルータであり、ＭＮが制御下にあるローカル・モビリティ・アンカー（ＬＭＡ）に対して、ＭＮのプロキシとしてローカルな登録を実行するルータ（プロキシノード）である。ＮＡＩは接続認証（Authentication）の目的のために、ＡＡＡ（Authentication, Authorization and Accounting）サーバに転送される。ＡＡＡサーバは、ＭＮのネットワーク接続（attachment）を資格認証（Authorize）すると、接続認証（Authentication）が成功したことをＭＡＧに通知するためにレスポンスを送り返す。上記のレスポンスでは、ＡＡＡサーバはさらに、ＬＭＡアドレスと、ＭＮがローカルドメイン内をローミング中に備える必要があるアドレス構成モード又は特別なポリシーのような幾つかのＭＮプロファイルを提供する。
　ＭＡＧは上記のＭＮのパラメータを取得すると、プロキシＢＵ（ＰＢＵ）メッセージをＬＭＡに送信する。ＭＡＧはＰＢＵメッセージの応答であるプロキシ・バインディング確認（ＰＢＡ）メッセージから、ＭＮの接続（attach）しているインタフェースに関連するプリフィックスを取得した後、ホームリンク及びローカルホームリンクをエミュレートする。上記のようにＭＡＧが実行するＰＢＵメッセージすなわちローカルな登録は、このメッセージがＰＢＵメッセージであることを示すフラグのみを除いてＭＩＰｖ６のＢＵメッセージと同一である。ＰＢＵメッセージを実行することにより、ＭＮの到達性のステートがＬＭＡにおいて生成される。基本的には、ＬＭＡは、ＰＭＩＰｖ６ドメインで取得されたＭＮプリフィックスに対する到達性のステートを有し、このＭＮプリフィックスに対して到達可能なアドレスはＭＡＧのアドレスである。
　ＭＮはステート有り（stateful）又はステート無し（stateless）のアドレス構成モードを用いて、ＰＭＩＰｖ６ドメインで受信したプリフィックスを用いてアドレスを構成する。各ＭＮはユニークなプリフィックスを取得するので、ＬＭＡにおけるプリフィックスベースのキャッシュは、ＭＮに十分に到達する。ＬＭＡに到着した各データパケットは、ＭＮに接続（connect）しているＭＡＧにトンネル化され、また、ＭＮからＭＡＧに到着した各データパケットはＬＭＡにトンネル化される。ＭＡＧの近隣（neighbor）キャッシュテーブルは、ＭＮのＰＭＩＰｖ６ローカルアドレスと、ＭＮにパケットを伝送するのに使用されるリンク層アドレスをバインディングする。
　次に、ＭＮが複数の通信インタフェースを有していて各インタフェースが異なるアクセス技術に属する場合、又はＭＮが１つのインタフェースを有していてその１つのインタフェースが複数の異なるプリフィックスを処理可能であって同じインタフェースに対して複数の異なるアドレスを構成可能な場合の広い意味のマルチホーミングについて説明する。非特許文献２に開示されているＰＭＩＰｖ６のプロトコルは、複数のインタフェースを有していてすべてのインタフェースが同時に接続（attach）するＭＮをサポートできるように設計されている。基本的には、各インタフェースには１つのユニークなプリフィックスが割り当てられ、ＰＭＩＰｖ６のプロトコルは、ＰＭＩＰｖ６ドメイン内をローミング中、各インタフェースが同じプリフィックスを参照することを保証している。したがって、複数のインタフェースを有するＭＮにとって、ＰＭＩＰｖ６の複数のバインディングがＬＭＡにおいて維持され、また、各バインディングはユニークなプリフィックスにより識別される個々のモビリティ・セッションとして維持される。
　下記の非特許文献４には、ＭＩＰｖ６機能を備えたＭＮが外部ドメイン内をローミングしたときにマルチホーミング・サポート機能をいかにＨＡにおいて提供するかが記述されている。非特許文献４におけるマルチホーミング・サポート機能は、マルチホーミングの利点が取得可能なように、ＭＮの１以上のインタフェースに関連する個々の気付アドレス（ＣｏＡ）を介してパケットを到達させるメカニズムである。ＭＮが外部ドメイン内をローミングすると、マルチホーミング・サポートを行うためには、ＭＮのホームプリフィックス用の地理的なアンカーポイントとなるＨＡは、ＭＮのＣｏＡ用のバインディング情報を有する必要がある。このバインディング情報は、ホームアドレス（ＨｏＡ）とＭＮの１以上のインタフェースに関連する個々のＣｏＡのマッピングである。非特許文献４には、複数のバインディングを個々に同時に維持するために、バインディング識別子（ＢＩＤ）を使用することが記述されている。このＢＩＤは各インタフェース、すなわち各インタフェースのＣｏＡをユニークに識別する。ＢＩＤはローミングするＭＮにより生成されて、バインディング登録の際にＨＡに転送される。ＨＡはＢＩＤを使用して、１つのＨｏＡあてのパケットを個々のＣｏＡに到達可能にする登録を維持することができる。
　３ＧＰＰ（Third Generation Partnership Project）は、例えばワイヤレス・ローカルエリア・ネットワーク（ＷＬＡＮ）と、セルラネットワーク又は第３世代（３Ｇ）セルラネットワークや第３．９世代、第４世代などと、ＷｉＭＡＸ形式のワイヤレスのワイドエリア・ネットワーク（ＷＡＮ）のような種々の形式の無線アクセスネットワークを有するグローバルな異種ネットワーク結合構造について作業を行っている。グローバルな異種ネットワーク結合構造は、シームレスなモビリティを実現して、リアルタイムなビデオ、ＶｏＩＰ（Voice over IP）、情報、重要なデータなどの異種のアプリケーションサービスを高いサービス品質（Quality of Service）でサポートするのに有用である。下記の非特許文献３には、ＰＭＩＰｖ６が３ＧＰＰローカルドメインにおけるローカル・モビリティ管理（ＬＭＭ）プロトコルとして採用されるであろうことが開示されている。３ＧＰＰローカルドメインは、３Ｇセルラネットワークと、信頼性のある（Trusted）又は信頼性のない（Untrusted）ＷＬＡＮアクセスネットワークやＷｉＭＡＸアクセスネットワークにより構成されるかもしれない。さらに、複数の異種のインタフェースを有するＭＮが３ＧＰＰローカルドメインをローミングして、種々の形式のインタフェースを介して同時接続（attach）してマルチホーミングを実現する必要がありそうである。また、他の従来技術としては、下記の非特許文献５、６、７及び特許文献１～１０に開示されているものがある。
Aghvami, A.H., et. al., "Method of discovering multi-mode mobile terminals", US Patent No. US20060166699A1, July 27, 2006. Paik, Eun-kyoung, et. al., "Method for optimizing synchronization signal among multiple home agents in mobile internet service system", WIPO Patent No. WO06068439A1, June 29, 2006. Maeda, M., "Location registration using multiple care-of addresses", US Patent No. US20040142657A1, July 22, 2004. Vesterinen, S., "Local mobility management in mobile internet protocol network", US Patent No. US20060209759A1, September 21, 2006. Ikeda, S., et. al., "Mobility managing method and mobile Terminal", WIPO Patent No. WO04014027A2, February 12, 2004. White, P., et. al., "Multi access terminal with capability for simultaneous connectivity to multiple communication channels", WIPO Patent No. WO06055784A2, May 26, 2006. Wall, S.B., et. al., "System and method for handoff processing", US Patent No. US7272123, September 18, 2007. Karia, S., et. al., "Reducing data loss during handoffs in wireless", WIPO Patent No. WO2007041652A2, April 12, 2007. Bachmann, J., et. al., "Enabling simultaneous use of home network and foreign network by a multihomed mobile node", WIPO Patent No. WO2007039016A1, April 12, 2007. Weniger, K., et. al., "Race condition resolution in mixed network- and host-based mobility management scenarios", European Patent No. EP1953991A1, August 6, 2008.
Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. Gundavelli, S., et. al., "Proxy Mobile IPv6", Internet Engineering Task Force (IETF) Working Group Draft: draft-sgundave-mip6-proxymip6-02.txt, March 5, 2007. "3GPP System Architecture Evolution: Report on Technical Options and Conclusion", 3GPP TR 23.882, V1.12.0, October 2007. Wakikawa, R., et. al., "Multiple Care-of Addresses Registration", Internet Engineering Task Force Working Group Draft: draft-ietf-monami6-multiplecoa-03.txt, Jan 2008. Gundavelli, S., et. al., "Proxy Mobile IPv6", Internet Engineering Task Force (IETF) Internet Engineering Task Force Request For Comments 5213, August 2008. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402, V8.3.0, September 2008. Wakikawa, et. al., "Multiple care-of addresses Registration", Internet Engineering Task Force Draft: draft-ietf-monami6-multiplecoa-10.txt, November 2008.
　次に、ＭＮが同じホームＬＭＡ／ＨＡからホームプリフィックスと外部プリフィックスを参照して、外部プリフィックスを参照するインタフェースの到達性を実現したい場合の問題点について説明する。図１４に示す例では、ＭＮ２００の複数のインタフェースとＣＮ２１４の間の通信は、まず、３ＧＰＰネットワークであるホームＰＭＩＰｖ６ネットワーク２０４のＬＭＡ／ＨＡ／ホームＰＤＮ（Packet Data Network）ゲートウェイ２０３とＭＡＧ／３Ｇサービングゲートウェイ（Ｓ-GW）２０１（及びインタネット２０５）を介して行われている。次いでＭＮ２００の複数のインタフェースのうちの１つがネットワーク２０６のアクセスルータ（ＡＲ）２０７に接続（connect）すると、ＭＮ２００の複数のインタフェースとＣＮ２１４の間の通信は、ホームＰＭＩＰｖ６ネットワーク２０４のＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３とＭＡＧ／ｅＰＤＧ（evolved Packet Data Gateway）２０２（及びインタネット２０５）を介して行われる。ＭＮ２００が新たに接続（connect）するネットワークは、信頼性のないアクセスネットワーク（Untrusted Access Network）であり、例えばＷＬＡＮ２０６である。
　図１４に示すシステム例では、ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３では、ＭＮ２００のＰＭＩＰｖ６登録とＣＭＩＰｖ６登録が発生する。ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３において想定される基本的な動作に着目すると、まず、ＭＮ２００の複数のインタフェースにそれぞれ異なるプレフィックスを割り当てることで、ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３は、ＭＮ２００の各インタフェースにそれぞれ関連する異なるプリフィックスによる個々のＰＭＩＰｖ６キャッシュ（バインディングキャッシュ２１３の第１のエントリＥ１及び第２のエントリＥ２）を維持するものとする。
　次に、ＣＭＩＰｖ６キャッシュについては、ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３は、ＭＮ２００の各インタフェースに異なるＨｏＡが割り当てられたときは、それぞれのＨｏＡに関するＣＭＩＰｖ６キャッシュとして別々に管理するか、又は非特許文献４に開示されているようにすべてのインタフェースに対して同じＨｏＡが割り当てられたときには、ＢＩＤを用いることで、１つのＣＭＩＰｖ６キャッシュに対して関連付けられたそれぞれのインタフェースを区別する。図１４に示されているバインディングキャッシュ２１３の第３のエントリＥ３は、Ｐ１から生成されたアドレスをＨｏＡとし、Ｐ２から生成されたアドレスをＣｏＡとしてＣＭＩＰｖ６キャッシュを構成している。また、このとき、ＰＭＩＰｖ６のプロトコルが複数のプリフィックスを用いているので、あるＰＭＩＰｖ６キャッシュ（第１のエントリＥ１）は、同じプリフィックスから生成されたＨｏＡを有し、ＢＩＤ又はインタフェース識別子を有さないＣＭＩＰｖ６バインディングで置換できるのみであるものとする。基本的には、ＰＭＩＰｖ６キャッシュをＣＭＩＰｖ６キャッシュで更新する場合、又はその逆の場合、ＢＩＤ／インタフェース識別子は、主要なパラメータでないものとする。例えば、もしＰＭＩＰｖ６キャッシュがＣＭＩＰｖ６登録要求と同じＢＩＤ／インタフェース識別子を有するが、ＰＭＩＰｖ６登録とＣＭＩＰｖ６登録のプリフィックスが異なる場合には、ＰＭＩＰｖ６登録とＣＭＩＰｖ６登録はお互いに上書きされず、並列に存在する。
　この動作は以下の具体例により明らかである。図１４において、ＭＮ２００の３ＧセルラインタフェースＩｆ１がＭＡＧ／３Ｇ・Ｓ－ＧＷ（サービングゲートウェイ）２０１に接続（attach）し、また、ＭＮ２００のＷＬＡＮインタフェースＩｆ２がＭＡＧ／ｅＰＤＧ２０２に接続（attach）するものとする。さらに、ＭＮ２００のＷＬＡＮインタフェースＩｆ２は、ＡＲ２０７に直接接続しており、ＭＡＧ／ｅＰＤＧ２０２に対してIPsec トンネルインタフェースを介して接続（attach）するものとする。基本的には、ＭＡＧ／ｅＰＤＧ２０２は、３ＧＰＰネットワークであるホームＰＭＩＰｖ６ネットワーク２０４（以下、ホームＰＭＩＰｖ６ドメイン）に対しては信頼性のあるゲートウェイである。さらに、ＷＬＡＮ２０６はインタネット２０５に接続（connect)され、また、ホームＰＭＩＰドメイン２０４もインタネット２０５に接続（connect)される。
　ＭＮ２００はＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３からプリフィックスを取得しアドレスを生成する。しかし、ＭＮ２００はＷＬＡＮインタフェースＩｆ２用として、もう１つのアドレスを構成する。そのアドレスは、プリフィックスがＡＲ２０７のプリフィックスに直接に関連する不変でないアドレスである。この不変でないアドレスは、パケットをＭＡＧ／ｅＰＤＧ２０２にトンネル化するためだけに使用される。
　ＭＮ２００の３ＧセルラインタフェースＩｆ１が最初にホームＰＭＩＰドメイン２０４に接続(attach)してレイヤ２のアクセス認証が成功すると、ＭＡＧ（ＭＡＧ／３Ｇ・Ｓ－ＧＷ）２０１がＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３との間でＰＢＵ／ＰＢＡ動作（図のシグナリング２０８）を実行し、ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３がＰＢＡメッセージ（２０８）でホームプリフィックスＰ１を割り当てる。このときのＭＮ２００に関するＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３におけるＰＭＩＰｖ６登録は、バインディングキャッシュ（ＢＣ）２１３の最初のエントリＥ１である。この最初のエントリＥ１は、ホームプリフィックスＰ１と、ＭＡＧアドレスとしてＭＡＧ／３Ｇサービングゲートウェイ２０１のアドレスＭＡＧ１と、ＭＮ－ＩＤであるＮＡＩと、Ｉｆ－ＩＤとしてＩｆ１－ＩＤが対応している。この内容は非特許文献２で説明されているので、ここでは詳細な説明を省略する。
　次に、ＭＮ２００のＷＬＡＮインタフェースＩｆ２がＷＬＡＮドメイン２０６に接続(attach)すると、ＭＮ２００は、まず不変でないアドレスを取得、すなわちＡＲ２０７のプリフィックスから不変でないアドレスを構成し、次いでドメイン・ネームサーバ（ＤＮＳ）クエリを実行してｅＰＤＧアドレスを取得する。ＭＮ２００はｅＰＤＧアドレスを取得すると、インタネットキー交換（ＩＫＥｖ２）手続をＭＡＧ／ｅＰＤＧ２０２と開始してセキュアなトンネルを確立する。トンネルの確立手続中は、レイヤ３の認証パラメータが転送され、認証が成功すると、ＭＡＧ／ｅＰＤＧ２０２は、ＰＢＵ／ＰＢＡメッセージ（図のシグナリング２０９）をＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３とやり取りし、ホームプリフィックスＰ１に対してローカルプリフィックス（外部プリフィックス）として使用するプリフィックスＰ２が取得されてＭＮ２０２に転送される（図のシグナリング２１１）。シグナリング２１１は、ＩＰｓｅｃトンネル確立確認メッセージを示す。ＰＢＵ／ＰＢＡメッセージ（図のシグナリング２０９）によりＢＣ２１３に生成される登録が第２のエントリＥ２である。第２のエントリＥ２は、外部プリフィックスＰ２と、ＭＡＧアドレスとしてＭＡＧ／ｅＰＤＧ２０２のアドレスＭＡＧ２と、ＭＮ－ＩＤであるＮＡＩと、Ｉｆ－ＩＤとしてＩｆ２－ＩＤが対応している。なお、プリフィックスＰ１をホームプリフィックス、プリフィックスＰ２を外部プリフィックスと称しているが、これはエントリＥ３におけるＨｏＡとＣｏＡの関係を基にしている。よって、プリフィックスＰ２を用いてＣＮと通信を行う場合には、プリフィックスＰ２がホームプリフィックス、プリフィックスＰ１が外部プリフィックスとみなされる。
　ここで、ＭＮ２００は外部プリフィックスＰ２をＷＬＡＮインタフェースＩｆ２経由で参照した場合、到達性を実現するために、非特許文献４で説明されている、ホームネットワークと外部ネットワークから同時に接続する際に送信するＣＭＩＰｖ６登録をＷＬＡＮインタフェースＩｆ２経由で送信してマルチホーミング機能の取得を希望する場合を考える。なお、このＣＭＩＰｖ６登録メッセージには、エントリＥ３を生成するための情報（ＨｏＡ（Ｐ１）及びＣｏＡ（Ｐ２））が含まれているが、同じプリフィックスＰ１に関する既存のエントリＥ１を無効化しないために、Ｅ１と独立にＥ３を生成することを示す情報（フラグＨをセット、またはＥ１のＢＩＤと異なるＥ３用のＢＩＤ）が含まれている。このようにＭＮ２０２のすべてのインタフェースを使用すると、帯域が広くなってＭＮ２０２の幾つかのフローのＱｏＳを増大することができる。また、ＭＮ２００はこれらのフローがＷＬＡＮインタフェースＩｆ２のみの経由で到達することを希望するかもしれない。この場合、フラグＨ付きのＣＭＩＰｖ６登録２１２を送信して、ＣＮ２１４からのあるフローについてはＷＬＡＮインタフェースＩｆ２のみの経由で到達するようにフィルタ・ルールを適切化するかもしれない。なお、フラグＨについては非特許文献４で説明されているので、詳細な説明を省略する。
　ＭＮ２００がフラグＨ付きのＣＭＩＰｖ６登録２１２を実行した場合にバインディングキャッシュ２１３に生成される登録が第３のエントリＥ３である。第３のエントリＥ３は、ホームプリフィックスＰ１から生成したＨｏＡと、ＣｏＡとして外部プリフィックスＰ２から生成したＣｏＡ（Ｐ２）と、ＭＮ－ＩＤであるＮＡＩと、Ｉｆ－ＩＤとしてフラグＨが対応している。ここで重要な点は、第３のエントリＥ３がどのように維持されるかである。なお、フラグＨはホームエージェントにおいてホームとアウェイの両方に接続したことを示すエントリを生成するために用いられる。ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３は、フラグＨが存在するＣＭＩＰｖ６登録２１２をアクセプトして第３のエントリＥ３としてＣＭＩＰｖ６エントリを生成する。第３のエントリＥ３は第１のエントリＥ１を上書きしない。
　もし、ＭＮ２００がインタフェース識別子Ｉｆ１－ＩＤが付加されたＣＭＩＰｖ６ＢＵ（すなわちＢＩＤ＝Ｉｆ１－ＩＤ）を送信すると、このＣＭＩＰｖ６ＢＵは第１のＰＭＩＰｖ６エントリＥ１を上書きしてしまい、マルチホーミング機能が喪失する。したがって、ＭＮ２００がＢＩＤ付き又はフラグＨ付きのＣＭＩＰｖ６登録２１２を送信することができ、また、このＢＩＤは、第１のＰＭＩＰｖ６エントリＥ１がＣＭＩＰｖ６登録２１２により上書きされないようにインタフェース識別子Ｉｆ１－ＩＤと異なるべきである。ここで、もしＭＮ２００がインタフェース識別子Ｉｆ２－ＩＤと等しいＣＭＩＰｖ６登録を送信すると、第２のＰＭＩＰｖ６エントリＥ２は、このＣＭＩＰｖ６登録により上書きされない点が重要である。この理由は、ＰＭＩＰｖ６のプロトコルがインタフェースごとにユニークなプリフィックスを採用しており、このため、ＰＭＩＰｖ６キャッシュがＣＭＩＰｖ６キャッシュにより置換されるのは、ＰＭＩＰｖ６キャッシュのプリフィックスが新しいＣＭＩＰｖ６ＢＵメッセージのホームアドレスのプリフィックスと一致するときのみであるからである。
　ここで、ＢＣ２１３内のエントリＥ１、Ｅ２、Ｅ３を参照すると、ＣＭＩＰｖ６登録が直接に第２のエントリＥ２に関連することは明らかである。さらに、当業者であれば、エントリＥ３を使用した場合に生成されるＣｏＡ（Ｐ２）宛のパケットをルーティングするためには、ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３は、ＢＣ２１３内においてプリフィックスＰ２がＰＭＩＰｖ６登録を有するか否かをチェックしなければならないことは明らかである。ＷＬＡＮインタフェースＩｆ２にパケットを正確にルーティングするためには、このような回帰的なトレーシングが必要となる。ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３は、ＭＡＧ２０２のアドレスＭＡＧ２を発見したときのみ、ＣｏＡ（Ｐ２）にパケットを正確にルーティングすることができる。
　重要なことは、ＭＮ２００あてのすべてのパケットが、プリフィックスＰ１から生成した１つのＨｏＡに到着することである。ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ２０３は基本的に、第１のエントリＥ１（ＰＭＩＰｖ６エントリ）又は第３のエントリＥ３（ＣＭＩＰｖ６エントリ）を使用して、ＨｏＡあてのパケットをルーティングする。上記の説明から、ＣＭＩＰｖ６バインディングキャッシュの内容が変化しない想定では、ＣＭＩＰｖ６バインディング・キャッシュ（第３のエントリＥ３）は非常に静的であることが分かる。そこで、本発明では、ＣＭＩＰｖ６エントリＥ３を生成するためのシグナリングを最適化するメカニズムを提供することにある。
　ここで、特許文献１に開示されている方法は、動的なローミングサービス契約を生成する際の問題を追求している。この方法では、外部ネットワークに接続(attach)したマルチモード端末（ＭＭＴ）が、ＭＭＴが提供するパラメータを用いてホームネットワークにより発見される。このパラメータは、外部に接続(connect)したＭＭＴのインタフェースを介して取得される。ホームネットワークは、ＭＭＴにより与えられる外部ネットワーク識別子を使用して動的なローミング契約を生成する。このＭＭＴによるシグナリングは継続的である必要はない。ＭＭＴは、例えばネットワークタイプ、オペレータコード、ＷＬＡＮのＳＳＩＤ（Service Set IDdentifier）のようなセルロケーションデータ又は基地局のＳＳＩＤの情報を提供してもよい。ホームネットワークは、基本的にはこれらのデータから、外部ネットワークのパラメータを識別し、フライ契約を生成する。
　特許文献１に記載されている方法は、図１４で説明したシグナリング最適化を取り扱っていないが、ホームネットワークに対して、外部ネットワークに接続(connect)したインタフェースを使用する外部ネットワークについての情報を提供する。この情報は一回だけ提供されるが、ホームネットワークにおいてバインディング・エントリを生成することと関係がない。
　特許文献２には、ホームネットワーク内の複数のＨＡ間でシグナリングを同期させる際の問題を解決する方法が開示されている。ロードバランシングとしてはホームネットワーク内の複数のＨＡを用いることが有用である。エラー発生に備えて、また、システムが動的なロードバランシングに適合するために、１つのＨＡのバインディングキャッシュ・エントリ（ＢＣＥ）が他のＨＡにもストアされる。ただし、ＭＮがアイドルステートのときには、すべてのＨＡにＢＣＥをストアする必要はない。特許文献２に開示されている方法では、ＭＮはＨＡに対してＢＵメッセージを送信する際、ＭＮがアクティブステートか又はアイドルステートかを示す情報を共に送信する。この情報が複数のＨＡ間でシグナリングを同期させるために使用される。ＭＮがアクティブステートに移行すると、この情報を含むＢＵメッセージがすべてのＨＡに送信されるが、アクティブステートに移行しなければ、この情報はすべてのＨＡに送信されない。この方法は、図１４で説明したシグナリング・ストームの問題を解決しているが、本発明とは異なる。すなわち、特許文献２では、ＭＮがアクティブステートか又はアイドルステートかを示す情報を提供しているが、ＨＡにおけるＢＣＥを生成するためのインタフェース・バインディングに関する情報を提供していない。
　特許文献３には、ＭＮが複数のインタフェースを有し、すべてのインタフェースが外部ネットワークに接続(connect)したときに、ＨＡとＣＮにバインディング・アップデートを行うシステムが開示されている。ＭＮが複数のインタフェースを有する場合、すべてのピア・エンティティに位置登録を送信すると、シグナリング負荷が増大する。特許文献３ではシグナリング負荷を減少させるために、ＭＮがあるＣｏＡをＨＡに対してアップデートし、他のＣｏＡをＣＮに対してアップデートする。この方法によれば、シグナリング効率を実現することができる。しかしながら、ＭＮは、ＭＮに起因するシグナリング負荷を減少させる賢い決定をするが、ＭＮは、ＢＵメッセージを継続して送信する必要がある。図１４における課題は、ホームＰＭＩＰｖ６をローミングする際のＭＮのシグナリングを完全に除去することにある。
　特許文献４には、非特許文献２のＰＭＩＰｖ６と同様な方法が開示されている。特許文献４におけるネットワークは、ローカル・モビリティ・ドメインのアクセスルータと、このアクセスルータに接続(connect)しているワイヤレス・アクセスポイントを含み、ワイヤレス・アクセスポイントがＭＮのプロキシとなる。ローカル・モビリティ・ドメインのアクセスルータは、ＭＮのプロキシＣｏＡを保持し、ＭＮあてのパケットが到来すると、プロキシＣｏＡをワイヤレス・アクセスポイントのローカルアドレスに置換する。ワイヤレス・アクセスポイントのローカルアドレスは、ＭＮには見えない。この方法は、ＭＮに関連するシグナリング負荷を減少させることができるが、複数のインタフェースを有するＭＮがＰＭＩＰｖ６ドメイン内をローミングするときのシグナリングを減少させることはできない。
　以上説明したように、従来技術では、複数のインタフェースを有するＭＮが、１つのホームＬＭＡ／ＨＡを有するＰＭＩＰｖ６ドメイン内をローミングする際に、あるインタフェースに対するパケットの到達性を確保するためには、そのインタフェースに割り当てられているプリフィックスから生成されるアドレスをＣＮとの通信に使用しているアドレスに対して関連付けるためにＣＭＩＰｖ６登録のシグナリングを送信する必要がある。しかしながら、通常のＣＭＩＰｖ６登録によって生成されたキャッシュを維持するためには、ＭＮがＨＡに対して定期的にシグナリングを送信してキャッシュを更新する必要がある。また、移動して別のアドレスを得た場合には、登録済みのキャッシュを削除・更新する必要がある。これらによって、MNが送信するシグナリングによるトラフィックの増加が発生してしまう。
　次に着目する問題は、複数のインタフェースを有するＭＮが、この複数のインタフェースを経由した同時接続（connectivity）を実現するために複数のバインディングをコアネットワークに登録する場合である。この同時接続を実現するための複数のバインディング登録の問題は、解決する必要がある。その理由は、不必要なシグナリングは、ＭＮのバッテリ電源を無駄に消費し、ワイヤレス・アクセスネットワークに対するシグナリング負荷を増大するからである。ワイヤレス・アクセスネットワーク及びバッテリの資源は、限りがあり、不必要なシグナリングを避けることにより保護する必要がある。
　この問題は、複数のインタフェースを有するＭＮがコアネットワークに接続（attach）していて、１つのインタフェースがホームリンクに接続（attach）し、かつ他のインタフェースが外部リンクに接続（attach）しているという想定の場合に顕著である。ホームリンクとは、ＭＮが非特許文献１に記載されているホームプリフィックスを参照しているリンクであり、ホームプリフィックスも非特許文献１に定義されている。ホームプリフィックスとは、ホームエージェントによって管理されているプリフィックスであって、ＭＮのＭＩＰｖ６ホームアドレスを構成するのに使用されるプリフィックスである。
　複数のバインディング登録の問題の主要な理由は、ホームパスのセットアップの遅延に依る。ホームパスのセットアップの遅延が発生するときとは、ホームプリフィックスのモビリティが３ＧＰＰのようなＰＭＩＰｖ６メカニズムにより管理されるときである。ローカルドメインにおけるＰＭＩＰｖ６メカニズムの動作は、非特許文献５に説明されている。ホームリンクが３ＧＰＰリンクでない場合、すなわちホームリンクが３ＧＰＰアーキテクチャにより管理されていない場合や、ホームプリフィックスのモビリティがＰＭＩＰｖ６によって管理されていない場合、ＭＮはホームリンクを速やかに検知できるかもしれないが、ホームパスのセットアップの遅延の問題は、実際のホームリンク検出動作に依存する。したがって、ここでの問題は、ホームプリフィックスのモビリティがＰＭＩＰｖ６メカニズムにより管理され、かつホームリンクのセットアップが遅延する全てのネットワークに適用することができることは明らかである。この問題については、図１５を参照して説明する。また、当業者であれば、ここでの問題は、ホームプリフィックスのモビリティがＧＴＰ（Generic Tunnelling Protocol）メカニズムにより管理される場合にも適用することができることは明らかである。
　非特許文献７には、複数のインタフェースを有するＭＮが、これらの複数のインタフェースを介してホームリンクと外部リンクに同時に位置することができ、かつ全てのインタフェースがコアネットワークに接続（connect）するメカニズムが記載されている。このメカニズムでは、ＭＮは、１つのインタフェース経由でホームリンクを検知し、かつ他のインタフェース経由で外部リンクを検知すると、自身がホームリンクと外部リンクに同時に接続（connect）していることを示すＨフラグを有するＢＩＤオプションを含むＭＩＰｖ６のＢＵメッセージを外部リンク経由で送信する。このＨフラグは、ＨＡに対して、ＭＮあてのパケットがホーム側と外部側の両方のインタフェースに到着可能であることを示す情報を提供する。ＨＡは、この情報を受信すると、ＭＮのホームアドレスあてに到着するパケットをキャプチャするメカニズムをトリガする。非特許文献７に記載されている主要な想定とは、複数のインタフェースを有するＭＮが外部ドメインにおいて複数のインタフェース経由でネットワークに接続（connect）し、そのうちの１つのインタフェースがホームドメインに戻る想定である。
　しかし、ホームリンクと外部リンクに同時に接続（connect）する場合として、非特許文献７には全くカバーされていない３つのケースを考える。第１のケースとして、ＭＮが同時に両方のインタフェースをブートアップしたときに、１つのインタフェースがホームリンクに接続（connect）される場合がある。第２のケースとして、ＭＮが外部リンクに接続（connect）されていてハンドオフ中の１つのインタフェースを有し、かつホームリンクに接続（connect）可能な別のインタフェースをＭＮがブートアップする場合がある。第３のケースとして、両方のインタフェースで同時にハンドオフが発生し、１つのインタフェースでホームプリフィックスを参照し、かつ別のインタフェースで外部プリフィックスを参照する場合である。これを図１５に示す。
　図１５では、ＭＮ９０３は複数の異なるタイプのインタフェースとして、例えばＷＬＡＮ、ＷｉＭＡＸなどのＮｏｎ－３ＧＰＰインタフェース、さらには、ＵＴＲＡＮ（Universal Terrestrial Radio Access Network）、ＧＰＲＳ（General Packet Radio Service）、ＣＤＭＡ（Code Division Multiple Access）２０００及びＥ－ＵＴＲＡＮ（evolved-UTRAN）などの３ＧＰＰインタフェースを有することが考えられる。ここでは、ＭＮ９０３は、３ＧインタフェースとＮｏｎ３ＧＰＰインタフェースの２つを有しているとする。ＭＮ９０３がＷｉＭＡＸアクセスネットワーク９０１に接続（attach）した場合は、そのネットワークのＭＡＧ機能が、ワイヤレス・アクセスネットワークに位置するアクセスゲートウェイと共存していることが考えられる。また、ＭＮ９０３が、Ｎｏｎ３ＧＰＰインタフェースとしてＷＬＡＮインタフェースを有しており、信頼できないＷＬＡＮアクセスネットワークに接続（attach）した場合には、そのネットワークのＭＡＧ機能がｅＰＤＧ（evolved Packet Data network Gateway）と共存していることが考えられる。さらに、ＭＮ９０３が、例えばＥ－ＵＴＲＡＮ、ＵＴＲＡＮ、ＧＥＲＡＮのような３Ｇアクセスネットワークに接続（attach）した場合に、そのネットワークのＭＡＧ機能がＳ－ＧＷ（Serving GateWay）と共存していることが考えられる。さらに、ＭＮ９０３が、３ＧＰＰアーキテクチャでは、ＬＭＡ／ＨＡ機能がＰ－ＧＷ（Packet data network GateWay）と共存していることが考えられる。
　図１５における想定として、ＭＮ９０３は２つのインタフェースＩｆ１、Ｉｆ２のみを使用するものとする。２つのインタフェースＩｆ１、Ｉｆ２の同時接続（attachment）を実現するために、ＷｉＭＡＸインタフェース（ここでは、Ｎｏｎ３Ｇインタフェースと称す）Ｉｆ２とＬＴＥ（Long-Term Evolution）タイプのインタフェース（ここでは、３Ｇインタフェースと称す）Ｉｆ１を使用する。ただし、ＭＮ９０３が同時に接続（attach）するために他のタイプのインタフェースを使用できることは明らかであり、また、３ＧＰＰ規格で使用が想定されるインタフェースにも適用できる。さらに、本発明は、同様なアーキテクチャやモビリティ・プロトコルを使用するネットワークにも適用できる。
　以下の第１の想定では、ＭＮ９０３は、まずＷｉＭＡＸインタフェースＩｆ２の電源のみをオンにし、幾らかの時間が経過した後、負荷バランシング及び負荷分担の利点のために３ＧインタフェースＩｆ１の電源をオンにするものとする。ここでは、ＭＮ９０３は、外部ネットワーク（例えばＶＰＬＭＮ：Visited Public Land Mobile Network）においてＷｉＭＡＸインタフェースＩｆ２の電源のみをオンにするものとする。また、ＭＮ９０３は、ＷｉＭＡＸインタフェースＩｆ２のモビリティを管理するためにＭＩＰｖ６メカニズムを使用しているとする。その後、ＭＮ９０３は、ＷｉＭＡＸインタフェースＩｆ２の電源をオンにしたまま、ホームドメインであるＥＰＣ９００に戻るものとする。ここで、ＭＮ９０３がＥＰＣ９００として例えばＨＰＬＭＮ（Home Public Land Mobile Network）に移動したときに、ＬＴＥインタフェースＩｆ１の電源をオンにすることが考えられる。ＬＴＥインタフェースＩｆ１の電源をオンにする理由は多く存在し、例えばＨＰＬＭＮ９００においてＬＴＥセルが識別されて、そのフローのパーフォーマンスを改善するために負荷バランシング及び負荷分担の利点を実現するよう決定することが考えられる。
　ＭＮ９０３は、ＨＰＬＭＮ９００すなわちＥＰＣ（evolved packet core）９００に移動して、ＷｉＭＡＸインタフェースＩｆ２をＭＡＧ９１１に接続（connect）することによりＥＰＣ９００に接続（attach）するものとする。ＷｉＭＡＸインタフェースＩｆ２のモビリティは、ホームドメイン９００ではＭＩＰｖ６メカニズムにより管理されるとする。さらに、ＷｉＭＡＸインタフェースＩｆ２は、ＶＰＬＭＮからＨＰＬＭＮ９００へのハンドオフ処理中であるとする。さらに、ＭＮ９０３がＷｉＭＡＸアクセスネットワーク９０１を介してＭＡＧ９１１に接続（attach）した場合、ＭＮ９０３がＬＴＥインタフェースＩｆ１経由でＬＴＥ（又はＥ－ＵＴＲＡＮ）アクセスネットワーク９０２に対して接続（attachment）処理を開始する。さらに、ＬＴＥインタフェースＩｆ１のモビリティがＰＭＩＰｖ６メカニズムにより管理されて、非特許文献６に示すようにＭＩＰｖ６－ＢＵメッセージの使用が非常に制限されることが考えられる。
　ＷｉＭＡＸインタフェースＩｆ２経由のＭＮ９０３のアクセス認証がいったん完了すると、ＭＮ９０３は、ＭＡＧ９１１によって通知されるプリフィックスＰ２を参照する。このプリフィックスＰ２は、ＷｉＭＡＸインタフェースＩｆ２のＣｏＡを構成するのに使用される。また、ＭＡＧ９１１によって通知されるプリフィックスＰ２は、ルータ広告（ＲＡ）メカニズム又はＷｉＭＡＸ固有のシグナリングメカニズムを使用してＭＡＧ９１１により広告される（図のプリフィックス広告シグナリング・メッセージ９０５）。ＭＮ９０３は、メッセージ９０５を参照すると、ＷｉＭＡＸインタフェースＩｆ２のＣｏＡを構成し、また、ＭＩＰｖ６－ＢＵメッセージ９０６をＬＭＡ／ＨＡ９０４に送信する（ＢＵ１）。この場合、ＬＭＡ／ＨＡ９０４は、ＭＮ９０３のホームエージェントとなる。さらに、ＭＩＰｖ６－ＢＵメッセージ９０６は、ＢＩＤオプション及びＨフラグなしの通常のメッセージとなる。この動作は、ＭＩＰｖ６で動作するＭＮにとって通常の動作である。
　ＭＩＰｖ６－ＢＵメッセージ９０６が、Ｈフラグのようなマルチホーミングを意味するパラメータを有しない理由は、ＭＮ９０３がＬＴＥアクセスネットワーク９０２に対する接続（attachment）処理を開始するが、未だホームプリフィックスＰ１を参照していないからである。この場合、ＬＴＥアクセスにおいて、ＰＭＩＰｖ６ベアラ又はＧＴＰ（Generic Tunnelling Protocol）ベアラのセットアップが完了するまでに遅延が生じてしまう。この遅延の理由として考えられる１つの理由は、過剰な輻輳であり、別の理由は、地理的な配置によるホームリンクを経由するパスの転送遅延であり、また、別の理由は、Ｅ－ＵＴＲＡＮ内の多くのエンティティ（例えば基地局、evolved node B、Ｓ－ＧＷなど）をパケットが通過することで生じる遅延である。このため、ＭＮ９０３は、ＬＴＥアクセス経由で参照するプリフィックスＰ１のタイプ（すなわちＭＩＰｖ６ホームプリフィックスか又は別のホームネットワーク・プリフィックスか）を知得しない。その結果、ＭＮ９０３は、ＷｉＭＡＸ経由で接続（attach）し、ＭＩＰｖ６ホームプリフィックスに関連するフローを送受信するために、マルチホーミングを意味するパラメータを有しないＢＵメッセージ９０６を送信する。
　重要なことは、ＭＮ９０３が何故、ＬＴＥインタフェースＩｆ１経由で広告されるプリフィックスＰ１のタイプを知得しないかということである。ＭＮ９０３が知得するのは、非特許文献６で説明されているように、ＬＴＥインタフェースＩｆ１経由で取得するサービスタイプのみである。プリフィックス管理はＬＭＡ／ＨＡ９０４が行い、ＬＭＡ／ＨＡ９０４は、ＷｉＭＡＸインタフェースＩｆ２経由でＭＩＰｖ６プリフィックスを既に通知しているので、ＰＭＩＰｖ６ベアラに対して、どんなプリフィックスでも割り当てることができる。
　次の仮定として、ＭＮ９０３がＬＴＥアクセスネットワーク９０２に接続（attach）した後に、ＭＡＧ９１０をトリガして、ＰＭＩＰｖ６ベアラをセットアップするものとする。データトラフィック用のこのＰＭＩＰｖ６ベアラは、ＰＭＩＰｖ６－ＰＢＵメッセージ９０７によりセットアップされる。ＰＭＩＰｖ６－ＰＢＵメッセージ９０７及びそのＰＢＡメッセージ（不図示）の交換が完了すると、ＭＮ９０３は、ＬＭＡ／ＨＡ９０４によって管理されているプリフィックスＰ１をＭＡＧ９１０からのメッセージ９０８で参照する。メッセージ９０８で参照されるプリフィックスＰ１は、ＰＭＩＰｖ６メカニズムにより管理される。しかし、メッセージ９０８で参照されるプリフィックスＰ１は、ＭＮ９０３のＭＩＰｖ６のホームプリフィックスであるかもしれないし、ＬＭＡ／ＨＡ９０４により管理される何らかのホームネットワーク・プリフィックスであるかもしれない。また、ＬＭＡ／ＨＡ９０４がＭＩＰｖ６キャッシュとＰＭＩＰｖ６キャッシュの両方を管理するので、ＰＭＩＰｖ６－ＰＢＵメッセージ９０７により生成されるバインディングキャッシュは使用停止となる（アクティブでない）。その理由は、ＬＭＡ／ＨＡ９０４により生成されたＭＩＰｖ６キャッシュが既にアクティブであるからである。ここでは、ＭＩＰｖ６キャッシュの優先度がＰＭＩＰｖ６キャッシュより高いものとする。
　次に、ＭＮ９０３がＬＴＥインタフェースＩｆ１経由で接続（attach）したときに、ＬＭＡ／ＨＡ９０４がＭＩＰｖ６ホームプリフィックスＰ１を付与する場合を考える。ＭＮ９０３は、ＭＩＰｖ６ホームプリフィックスＰ１をメッセージ９０８で参照すると、ホームリンクに接続（connect）しているものと了解する。さらに、ＭＮ９０３は、メッセージ９０５でプレフィックスＰ２を参照した後に、メッセージ９０８でホームプリフィックスＰ１を遅れて参照した場合、ホームのリンクと外部リンクに同時に接続（connect）しているものと了解する。つまり、ＭＮ９０３は、ホームプリフィックスＰ１を参照すると、別のＢＵメッセージ９０９をＬＭＡ／ＨＡ９０４に送信して（ＢＵ２）、ホームのリンクと外部リンクの同時バインディング（以下、ホームアンドアウェイ・バインディング）をＬＭＡ／ＨＡ９０４に生成しなければならない。これは重要であり、その理由は、フローの負荷シェアリング及び負荷バランシングを実現するためにＭＮ９０３がホームのリンクと外部のリンクに同時に接続（connect）しているという情報をＬＭＡ／ＨＡ９０４が必要とするからである。このため、ここでの重要な問題とは、ＰＭＩＰｖ６のセットアップが遅れるので、ＭＮ９０３がＭＩＰｖ６のホームプリフィックスＰ１に対する同時接続を実現するためにＭＩＰｖ６のＢＵメッセージの送信を二重に実行することである（図のＢＵ１、ＢＵ２）。
　以上の説明では、特定の想定例に対する問題について記載したが、当業者であれば、ＭＮ９０３の両方のインタフェースＩｆ１、Ｉｆ２の電源が同時にオンになったときと、両方のインタフェースＩｆ１、Ｉｆ２が同時に移動したときにも、上記の問題が発生すると考えることは明らかである。また、上記の問題は、ＨＰＬＭＮにおける同時接続（attachment）について記載されているが、ＭＮ９０３の両方のインタフェースＩｆ１、Ｉｆ２がＶＰＬＭＮに同時に接続（connect）して、３Ｇインタフェース又はＬＴＥインタフェースＩｆ１の移動がＰＭＩＰｖ６メカニズムにより管理されるときにも発生する。さらに、上記の問題は、同時にＬＴＥインタフェースＩｆ１がＶＰＬＭＮに接続（connect）してＷｉＭＡＸインタフェースＩｆ２がＨＰＬＭＮに接続（connect）するときにも発生する。
　特許文献５には、外部ドメインに位置するＭＮが第２のＨＡを構成して新しいホームアドレスを取得する方法について記載されている。さらにＭＮは、外部ドメインを通過するＢＵシグナリングを減少するために、このホームアドレスを使用してホームドメインにおける前のＨＡをバインドする。特許文献５に記載されている方法の目的は、外部ドメインを通過する位置管理シグナリングを減少することにある。しかし、この方法は、図１５に記載されているシグナリングの問題に関するものではない。図１５におけるＭＮ９０３は、同時接続（connection）のセットアップを実現するため、また、両方のインタフェースＩｆ１、Ｉｆ２が同時に移動するときにおける同時接続（connection）のモビリティを管理するために二重のシグナリング（図のＢＵ１、ＢＵ２）を行っている。
　特許文献６には、複数の同時接続（connection）を確立し、また、ＭＮのオペレーティング・システム・ソフトウエアを使用してフローベースのルーティングを確立する方法が開示されている。しかし、特許文献６には、図１５に記載されている問題を解決するような方法は開示されていない。
　特許文献７には、ハンドオフ中にコンテキスト情報を転送するのではなく、ハンドオフ前にＭＮのコンテキスト情報を隣接する基地局から取得することにより、高速ハンドオフを確立する方法が開示され、ＭＮのコンテキスト情報をハンドオフ前に早く取得することにより、高速ハンドオフを実現できる。しかし、この方法は、ネットワーク・セグメントに放出されるシグナリング負荷が増大する。その理由は、ターゲットのネットワーク・エンティティが、ＭＮのコンテキスト情報を取得して高速ハンドオフを実現するために、複数の基地局に問い合わせるからである。図１５で着目する問題とは、不要なシグナリングを防止してＷｉＭＡＸインタフェースＩｆ２と３ＧインタフェースＩｆ１の高速接続（connection）を実現することであり、特許文献７に記載されている方法は、１つのインタフェースのみの高速接続（connection）が確立することを取り扱っており、図１５で着目する問題を解決しない。
　特許文献８には、バッファリング技術を用いてハンドオフ中のパケットロスを減少する方法が開示されている。しかし、特許文献８は、高速接続（connection）の確立についても、また、複数のインタフェースを有する端末のハンドオフ遅延を少ないシグナリングで減少することについても着目していない。
　特許文献９には、ＭＮが、ホームに接続（connect）したインタフェースのＣｏＡを使用して、ホームアンドアウェイ登録を同時に実現する方法が開示されている。しかし、特許文献９は、ホームアンドアウェイを示すＨフラグを直接には取り扱っておらず、また、ＰＭＩＰｖ６のセットアップが遅れることに対して、高速接続（connection）のセットアップを実現するメカニズムについては何ら提供していない。
　特許文献１０には、１つのインタフェースのためのＰＭＩＰｖ６－ＢＵとＣＭＩＰｖ６－ＢＵの間の競合を解決する方法が開示されている。しかし、図１５に記載されている問題は、同じインタフェースの位置登録信号の競合により起こるのではなく、ＭＩＰｖ６のＢＵ確立よりＰＭＩＰｖ６のＢＵ確立が遅れるから起こるのであり、このため、複数のインタフェースＩｆ１、Ｉｆ２の接続（attachment）中に二重登録（図のＢＵ１、ＢＵ２）を引き起こす。したがって、特許文献１０に提供されている解決策は、図１５に記載されている問題を解決しない。
　本発明は上記の問題点に鑑み、複数のインタフェースを有するモバイルノードがホームドメイン内をローミングする場合に、ホームエージェントにおいてクライアントベースのバインディングキャッシュを生成して管理する場合のシグナリングを減少させることができるバインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノードを提供することを第１の目的とする。
　本発明はまた、複数のインタフェースを有するモバイルノードがホームリンクと外部リンクに同時に接続（connect）しているときのバインディング登録のシグナリングを減少することができるバインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノードを提供することを第２の目的とする。
　本発明は上記第１の目的を達成するために、
　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成方法であって、
　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録するステップと、
　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録するステップと、
　前記ホームエージェントが、前記第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記生成したクライアントベースのバインディングキャッシュを前記モバイルノードによりリフレッシュされることなく維持するステップとを、
　有する構成とした。
　また本発明は上記第１の目的を達成するために、
　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成システムであって、
　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録する手段と、
　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録する手段と、
　前記ホームエージェントが、前記第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記生成したクライアントベースのバインディングキャッシュを前記モバイルノードによりリフレッシュされることなく維持する手段とを、
　有する構成とした。
　上記構成により、複数のインタフェースを有するモバイルノードがホームドメイン内をローミングする場合に、ホームエージェントにおけるクライアントベースのバインディングキャッシュをリフレッシュする要求メッセージをモバイルノードが頻繁に送信しないので、シグナリングを減少することができる。
　また本発明は上記第１の目的を達成するために、
　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成システムにおける前記ホームエージェントであって、
　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを登録する手段と、
　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録する手段と、
　前記第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記生成したクライアントベースのバインディングキャッシュを前記モバイルノードによりリフレッシュされることなく維持する手段とを、
　有する構成とした。
　また本発明は上記第１の目的を達成するために、
　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成システムにおける前記モバイルノードであって、
　前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュが前記ホームドメインのホームエージェントに登録される際に、前記ホームエージェントに対して、前記第１及び第２のインタフェース用の第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して維持するよう要求するメッセージを送信する手段を、
　有する構成とした。
　また本発明は上記第１の目的を達成するために、
　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合、前記モバイルノードが、前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュが前記ホームエージェントに登録される際に、前記ホームドメインのホームエージェントに対して、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して維持するよう要求するメッセージを送信するバインディングキャッシュ生成システムにおける前記ホームエージェントであって、
　前記要求メッセージを受信した後、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録した場合に、前記第１及び前記登録した第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するとともに、前記モバイルノードに対して前記要求メッセージを再度送信しないように通知する手段を、
　有する構成とした。
　また本発明は上記第１の目的を達成するために、
　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成方法であって、
　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録するステップと、
　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録するステップと、
　前記モバイルノードが前記ホームエージェントに対し、前記ホームエージェントが前記第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記生成したクライアントベースのバインディングキャッシュを通常時より長い存続期間の間、前記モバイルノードによりリフレッシュされることなく維持するよう要求するステップとを、
　有する構成とした。
　また本発明は上記第１の目的を達成するために、
　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成方法であって、
　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録するステップと、
　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録するステップと、
　前記モバイルノードが前記ホームエージェントに対し、前記ホームエージェントが前記登録した第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するよう要求するステップと、
　前記ホームエージェントが、前記要求されたクライアントベースのバインディングキャッシュを生成して通常時より長い存続期間を設定するとともに、前記モバイルノードに対して、前記存続期間の間、前記生成したクライアントベースのバインディングキャッシュをリフレッシュしないよう通知するステップとを、
　有する構成とした。
　また本発明は上記第１の目的を達成するために、
　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成方法であって、
　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録するステップと、
　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録するステップと、
　前記ホームエージェントが、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュが登録されたときに、前記モバイルノードに対して前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成する要求を送信しないよう通知するとともに、前記第１及び第２のプロキシ・バインディングキャッシュに関連するクライアントベースのルーティングを実行するステップとを、
　有する構成とした。
　さらに、本発明は上記の第２の目的を達成するために、ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードがローミングする場合に、前記第１及び第２のインタフェース用のバインディングキャッシュを前記モバイルノードのホームエージェントに生成するバインディングキャッシュ生成方法であって、
　前記第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に、前記モバイルノードが前記ホームエージェントに対し、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを登録するとともに、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録されるときにホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットするよう要求するステップと、
　前記第１のインタフェースが前記ホームドメインに接続した場合に、前記モバイルノードの代理ノードが前記ホームエージェントに対し、前記第１のインタフェース用のプロキシ・バインディングキャッシュを登録するステップと、
　前記ホームエージェントが、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録された場合に、前記フラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットするステップとを、
　有する構成とした。
　また、本発明は上記の第２の目的を達成するために、ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードがローミングする場合に、前記第１及び第２のインタフェース用のバインディングキャッシュを前記モバイルノードのホームエージェントに生成するバインディングキャッシュ生成システムであって、
　前記第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に、前記モバイルノードが前記ホームエージェントに対し、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを登録するとともに、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録されるときにホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットするよう要求する手段と、
　前記第１のインタフェースが前記ホームドメインに接続した場合に、前記モバイルノードの代理ノードが前記ホームエージェントに対し、前記第１のインタフェース用のプロキシ・バインディングキャッシュを登録する手段と、
　前記ホームエージェントが、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録された場合に、前記ホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットする手段とを、
　有する構成とした。
　また、本発明は上記の第２の目的を達成するために、ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードがローミングする場合に、前記第１及び第２のインタフェース用のバインディングキャッシュを前記モバイルノードのホームエージェントに生成するバインディングキャッシュ生成システムにおける前記モバイルノードであって、
　前記第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に、前記ホームエージェントに対し、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを登録するとともに、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録されるときにホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットするよう要求する手段を、
　有する構成とした。
　また、本発明は上記の第２の目的を達成するために、ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードがローミングする場合に、前記第１及び第２のインタフェース用のバインディングキャッシュを前記モバイルノードのホームエージェントに生成するバインディングキャッシュ生成システムにおける前記ホームエージェントであって、
　前記第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを登録するとともに、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録されるときにホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットする要求を受信する手段と、
　前記第１のインタフェースが前記ホームドメインに接続した場合に、前記第１のインタフェース用のプロキシ・バインディングキャッシュを登録する手段と、
　前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録された場合に、前記ホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットする手段とを、
　有する構成とした。
　上記構成により、ホームとアウェイの同時接続を示すフラグを含む第２の登録メッセージをモバイルノードがホームエージェントに送信しないので、複数のインタフェースを有するモバイルノードがホームリンクと外部リンクに同時に接続（connect）しているときのバインディング登録のシグナリングを減少することができる。
　本発明によれば、複数のインタフェースを有するモバイルノードがホームドメイン内をローミングする場合に、ホームエージェントにおいてクライアントベースのバインディングキャッシュを生成して管理する場合のシグナリングを減少することができる。
　また、本発明によれば、複数のインタフェースを有するモバイルノードがホームリンクと外部リンクに同時に接続（connect）しているときのバインディング登録のシグナリングを減少することができる。
第１の実施の形態が想定する通信システムを示す構成図 第１の実施の形態が想定する他の通信システムを示す構成図 第１の実施の形態の通信方法及び通信システムの通信シーケンスを示す説明図 第１の実施の形態のホームエージェントにおけるバインディングキャッシュの構成を示す説明図 図３におけるＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージの他の形態を示す説明図 図３におけるＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ（Ｌ２メッセージの場合）のフォーマットを示す説明図 図３におけるＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ（新しいモビリティ拡張ヘッダを有するシグナリング・パケットの場合）のフォーマットを示す説明図 図３におけるＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ（ＢＵメッセージのパケットの場合）のフォーマットを示す説明図 第１の実施の形態のモバイルノードの動作を説明するためのフローチャート 第１の実施の形態のホームエージェントの動作を説明するためのフローチャート 第１の実施の形態のモバイルノードの構成を機能的に示すブロック図 第１の実施の形態のホームエージェントの構成を機能的に示すブロック図 第２の実施の形態の通信システム及び通信シーケンスを示す説明図 第５の実施の形態の通信システム及び通信シーケンスを示す説明図 第８の実施の形態の通信システム及び通信シーケンスを示す説明図 本発明が解決しようとする課題を示す説明図 第９の実施の形態の課題を説明するための想定システムを示す説明図 第９の実施の形態を説明するための想定システムを示す説明図 第９の実施の形態におけるバインディング・キャッシュ・エントリを示す説明図 第９の実施の形態におけるＨフラグ生成要求メッセージのパケット構造の第１の例を示す説明図 第９の実施の形態におけるＨフラグ生成要求メッセージのパケット構造の第２の例を示す説明図 第９の実施の形態におけるＨフラグ生成要求メッセージのパケット構造の第３の例を示す説明図 第９の実施の形態におけるＨフラグ生成要求メッセージのパケット構造の第４の例を示す説明図 第９の実施の形態におけるモバイルノードの構成を機能的に示すブロック図 第９の実施の形態におけるモバイルノードの処理を説明するためのフローチャート 第９の実施の形態におけるホームエージェントの処理を説明するためのフローチャート 第９の実施の形態を説明するための他の想定システムを示す説明図 第９の実施の形態を説明するためのさらに他の想定システムを示す説明図
　＜第１の実施の形態の概要＞
　第１の実施の形態の概要について説明すると、複数のインタフェースを有するＭＮは、ある１つのインタフェースを介してホームプリフィックスを参照すると、ＭＮのＨＡであるＬＭＡ（以下、ホームＬＭＡ／ＨＡ）が位置するホームＰＭＩＰｖ６ドメインに接続（connection）中であると判断し、また、他のインタフェースがこれから同じホームＰＭＩＰｖ６ドメインに接続（connect）するものと予測する。ＭＮは、このように予測した後に、他のインタフェースが同じホームＰＭＩＰｖ６ドメインに接続（connect）した場合、外部プリフィックスを参照した他のインタフェースのためのＣＭＩＰｖ６バインディングを生成して維持管理するようにホームＬＭＡ／ＨＡに要求する。本発明の主要な目的は、ＭＮがホームＰＭＩＰｖ６ドメイン内で外部プリフィックスを参照したすべてのインタフェースに対して、ホームの利点とアウェイの利点をＭＮが同時に取得することであり、ＭＮがクライアントベースのＢＵ登録をホームＬＭＡ／ＨＡに継続して行わないことにある。
　＜想定システム＞
　図１は第１の実施の形態が想定する通信システムを示す構成図である。ここで、図１に示すＭＮ１０Ａ、１０Ｂは同じＭＮ１０が移動したことを示す。ＭＮ１０は複数のインタフェースとして３ＧセルラインタフェースＩｆ１とＷＬＡＮインタフェースＩｆ２を有し、図１では、ＭＮ１０ＡはＷＬＡＮ３０に位置していてＷＬＡＮインタフェースＩｆ２がＭＡＧ／ｅＰＤＧ２０に接続されている状態を示し、ＭＮ１０ＢはＷＬＡＮ３１に位置していてＷＬＡＮインタフェースＩｆ２がＭＡＧ／ｅＰＤＧ２１に接続されている状態を示す。なお、ＭＮ１０の複数のインタフェースは、セルラインタフェース（３G、３．９G、４G以降などの３GPP等の携帯電話に関する標準化団体で規定されるセルラインタフェース）やIEEE802やWiFiなどで規定されるＷＬＡＮインタフェースに限らず、ＷｉＭＡＸインタフェースやBluetoothインタフェースなどでもよい。なお以下では、セルラインタフェースを３Gセルラインタフェース、サービングゲートウェイを３Gサービングゲートウェイと記述しているが、これらは３Gに限らない。
　一方、３ＧセルラインタフェースＩｆ１はホームＰＭＩＰｖ６ネットワーク（ドメイン）１００の１つのＭＡＧ／３Ｇサービングゲートウェイ（Ｓ－ＧＷ）２２に接続（attach）し、ホームＰＭＩＰｖ６ネットワーク１００の範囲は、ＭＮ１０がＷＬＡＮ３０に位置していてもＷＬＡＮ３１に位置していても、３ＧセルラインタフェースＩｆ１が１つのＭＡＧ２２に接続できるほど大きい。ホームＰＭＩＰｖ６ネットワーク１００は、例えば、ネットワーク１００内でモビリティ管理サービスを提供するためにＰＭＩＰｖ６のプロトコルを採用した３GPP－ＨＰＬＭＮ（Home Public Land Mobile Network）であって、ＭＮ１０のホームネットワーク・ドメインである。また、ＬＭＡ／ＨＡ／ホームＰＤＮゲートウェイ４０は、ＭＮ１０のホームエージェント（以下、ＬＭＡ／ＨＡ）である。
　ホームＰＭＩＰｖ６ネットワーク１００の意味は、ＬＭＡ／ＨＡ４０がＭＮ１０のＭＩＰｖ６のＨＡであって、更にＭＮ１０がネットワーク１００をローミングするときにネットワーク１００のプリフィックスＰ１をＭＩＰｖ６ホームプリフィックスとして参照するということである。基本的に、ＬＭＡ／ＨＡ４０は、ＭＮ１０のＰＭＩＰｖ６バインディングとＭＩＰｖ６／ＣＭＩＰｖ６バインディングを受け付ける。
　次に、ホームＰＭＩＰｖ６ネットワーク１００のネットワークレイアウトを考察する。ホームＰＭＩＰｖ６ネットワーク１００内には、図１では１つのネットワークのみが記載されているが、多くのセルラ・アクセスネットワークが存在するものとする。セルラ・アクセスネットワークではＭＡＧ機能を有するルータがＭＡＧ／３Ｇ・Ｓ－ＧＷ２２に存在し、このルータは３Ｇアクセスネットワーク内の最初のホップルータであるものとする。さらに、３Ｇアクセスネットワークの受信エリア内に２つのＷＬＡＮ３０、３１が存在するものとする。さらにＷＬＡＮ３０、３１は、３ＧＰＰアーキテクチャを経由してトラフィックを転送するために３ＧＰＰコアネットワークにアクセスするためのゲートウェイ・ルータ及びトラスティッド・ルータであるＭＡＧ／ｅＰＤＧ２０、２１を有するものとする。さらに、ＷＬＡＮ３０、３１は連続（すなわち一方が他方に近接）し、かつＭＡＧ／３Ｇ・Ｓ－ＧＷ（以下では単にＭＡＧ）２２におけるルータ機能を有する大きな領域の３Ｇセル（すなわちネットワーク１００）配下に存在するものとする。
　ここで、最初にＭＮ１０がＭＮ１０Ａで示すようにＷＬＡＮ３０及び３Ｇのネットワーク１００に接続（attach）し、次いでＭＮ１０Ｂで示すようにＷＬＡＮ３１及び３Ｇのネットワーク１００に接続（attach）した場合、ＭＮ１０は移動中でも常にＭＡＧ／３Ｇゲートウェイ２２に接続（connect）しているものとする。ネットワーク１００がＭＮ１０のホームＰＭＩＰｖ６ドメインであるので、ＭＮ１０はネットワーク１００に接続（attach）したときにネットワーク１００のホームＭＩＰｖ６プリフィックスＰ１を確実に参照するものとする。また、ＬＭＡ／ＨＡ４０がＭＩＰｖ６機能を有するので、ＭＮ１０のＮＡＩがＰＢＵメッセージでＬＭＡ／ＨＡ４０に到達したときに、ホームＭＩＰｖ６プリフィックスＰ１がＭＮ１０に与えられるものとする。なお、ホームＭＩＰｖ６プリフィックスＰ１は、ＭＮ１０においてあらかじめ静的に構成されていてもよく、また、ブートストラッピング・メカニズムのような動的なメカニズムにより取得されていてもよい。
　最初にＭＮ１０が３ＧセルラインタフェースＩｆ１経由でネットワーク１００のルータであるＭＡＧ２２に接続（attach）すると、ＭＮ１０はＭＡＧ２２からのルータ広告（ＲＡ）メッセージ２６で、ネットワーク１００のプリフィックスであるホームＭＩＰｖ６プリフィックスＰ１を参照する。次にＭＮ１０がＷＬＡＮインタフェースＩｆ２経由でＷＬＡＮ３０のルータであるＭＡＧ２０に接続（connect）すると、ＭＮ１０はＭＡＧ２０からのＲＡメッセージ２５で、ＷＬＡＮ３０のプリフィックスである外部プリフィックスＰ２を参照する。ここで、その理由を理解することが重要である。その理由は、非特許文献２に開示されているＰＭＩＰプロトコルでは、インタフェースごとにユニークなプリフィックスを与えるので、ＬＭＡ／ＨＡ４０が外部プリフィックスＰ２をＷＬＡＮインタフェースＩｆ２に与えるからである。なお、ＭＮ１０が複数のプリフィックスをＬＭＡ／ＨＡ４０から取得している場合、ＣＮとの通信に使用しているプリフィックスをホームプリフィックスと呼び、それ以外を外部プリフィックスと呼ぶようにしてもよい。
　このため、ＭＮ１０は３ＧセルラインタフェースＩｆ１とＷＬＡＮインタフェースＩｆ２に対して１つのみのホームプリフィックスＰ１とホームアドレス（ＨｏＡ）を有する。この場合、ＭＮ１０は外部プリフィックスＰ２を第２のＷＬＡＮインタフェースＩｆ２経由で参照すると、ＷＬＡＮインタフェースＩｆ２への到達性を得るために、従来では、ＬＭＡ／ＨＡ４０に対してＣＭＩＰｖ６登録５０を実行する。ＣＭＩＰｖ６登録５０とは、ＭＮ１０が外部プリフィックスＰ２から生成した気付アドレス（ＣｏＡ）を、ホームＭＩＰｖ６プリフィックスＰ１から生成したＨｏＡにバインディングするということである。
　さらに、ＭＮ１０は非特許文献４に記載されているマルチホーミング機能を有している場合、ＨフラグがセットされたＣＭＩＰｖ６登録５０により、ホームの登録とアウェイの登録が同時に行われるものとする。さらに、ＬＭＡ／ＨＡ４０は非特許文献４に記載されているマルチホーミング機能を有するものとする。加えて、ＭＮ１０は他のパケットデータネットワーク（ＰＤＮ）に位置する複数のＣＮ６０、６１と通信しており、ＰＭＩＰｖ６ドメインのローカルアドレスを選択してＣＮ６０、６１との通信を選択したいものとする。
　この後、ＭＮ１０がＷＬＡＮ３１にローミングして（図のＭＮ１１Ｂ）、ＭＮ１０がＷＬＡＮインタフェースＩｆ２経由で、ＭＡＧ２１からのＲＡメッセージ２８内の同じ外部プリフィックスＰ２を参照するものとする。ここでは、インタフェース間のハンドオフである水平ハンドオフが発生するものとする。もし、ＭＮ１０がＷＬＡＮ３１に到達したときにＣＭＩＰｖ６の存続期間が満了し、また、ＷＬＡＮインタフェースＩｆ２への到達性を再び確保するため、又はインタフェースＩｆ１、Ｉｆ２の両方の同時使用を取得するため、又はＷＬＡＮインタフェースＩｆ２あてのみの転送を希望する場合、従来では、ＭＮ１０は、フラグＨ付きまたはフラグＨなしのＣＭＩＰｖ６ＢＵメッセージ５１をＬＭＡ／ＨＡ４０へ送信する必要がある。
　ここで、ＷＬＡＮインタフェースＩｆ２に対するＣＭＩＰｖ６バインディングは、ＭＮ１０がＬＭＡ／ＨＡ４０に対して、ＷＬＡＮインタフェースＩｆ２が外部プリフィックスＰ２から生成したＣｏＡを使用して到達できることを通知するためであることを理解することが重要である。しかし、この外部プリフィックスＰ２から生成したＣｏＡの実際の到達性は、ＭＡＧ２０又は２１から通知されるＰＭＩＰｖ６バインディング（図１４参照）により得ることができる。したがって、ＷＬＡＮインタフェースＩｆ２に対するＣＭＩＰｖ６バインディングの内容は、静的であって、ＷＬＡＮインタフェースＩｆ２に対するＰＭＩＰｖ６バインディングに関係しているものであると結論することができる。この理由は、外部プリフィックスＰ２から生成したＣｏＡは、外部プリフィックスＰ２のＰＭＩＰｖ６バインディングにより与えられる情報を使用することで、到達性を得ることができるからである。
　このため、従来のように、外部プリフィックスＰ２から生成したＣｏＡをＭＮ１０がホームプリフィックスＰ１から生成したＨｏＡにバインディングするためにシグナリングすると（図１のＣＭＩＰｖ６登録５０、５１）、ＭＮ１０に関連するシグナリング負荷が増大する。よって、ＬＭＡ／ＨＡ４０において、外部プリフィックスＰ２のＰＭＩＰｖ６バインディングに基づいてＣＭＩＰｖ６バインディングを生成、再生成することができるようにすることで、このシグナリング（５０、５１）を最適化することができる。ここで、ＣｏＡがＰＭＩＰｖ６ローカルプリフィックスでない他のプリフィックスから構成されている場合には、そのＣｏＡは完全に独立しており、独立してルーティング可能なアドレスである。しかし、外部プリフィックスＰ２のＣＭＩＰｖ６バインディングは、独立してルーティング可能なアドレスではないため、明らかに、外部プリフィックスＰ２のＣＭＩＰｖ６バインディングは、到達性を確保するためにＰＭＩＰｖ６バインディングを必要とする。
　したがって、ＷＬＡＮインタフェースＩｆ２のＰＭＩＰｖ６バインディングとＣＭＩＰｖ６バインディングは最適化することができ、ＭＮ１０に関するシグナリング負荷を軽減することができ、消費電力を軽減するといった効果を得ることができる。さらに、ＣＭＩＰｖ６バインディングにおけるＨｏＡ情報は不要である。その理由は、ホームプリフィックスＰ１のＰＭＩＰｖ６バインディングがＬＭＡ／ＨＡ４０のキャッシュ２１３（図１４の第１のエントリＥ１）内に存在し、ＨｏＡ情報が取得できるからである。また、もしホームプリフィックスＰ１がＬＭＡ／ＨＡ４０Ａのキャッシュ２１３内に存在しなくても、ＬＭＡ／ＨＡ４０はＡＡＡサーバ（不図示）に問い合わせることによりプリフィックスＰ１を取得できる。したがって、このシステムでＭＮ１０が通知する必要がある内容は、ホームＭＩＰｖ６ネットワーク１００内で外部プリフィックスＰ２を参照したインタフェースＩｆ２の使用を希望することだけである。ＬＭＡ／ＨＡ４０に存在するＰＭＩＰｖ６バインディングの内容は、ＣＭＩＰｖ６バインディングの内容を正確に生成することができる内容である。
　＜他の想定システム＞
　図２は第１の実施の形態が想定する他のシステムとして、ＷＬＡＮ３０、３１が連続して配置されていない場合を示す。この意味は、ＷＬＡＮ３０、３１の各セルがお互いに隣接していないということであり、ＭＮ１０がこのネットワーク１００を移動したときにＷＬＡＮインタフェースＩｆ２がアクティブモードとアイドルモードの間で切り替えが起きる状態になるということである。他の想定は図１と同じであるので、詳細な説明を省略する。ここで、ＭＮ１０Ａ、１０Ｂ、１０Ｃ、１０Ｄは同じＭＮ１０であって、ＭＮ１０が１０Ａ→１０Ｂ→１０Ｃ→１０Ｄの順番で以下の位置に移動することを示す。また、以下の第１～第４の位置では、ＭＮ１０の３ＧセルラインタフェースＩｆ１は安定しており、３ＧセルラインタフェースＩｆ１のハンドオフはないものとする。
・ＭＮ１０Ａ：ＷＬＡＮ３０に入るとき（第１の位置）
・ＭＮ１０Ｂ：ＷＬＡＮ３０から出るとき（第２の位置）
・ＭＮ１０Ｃ：ＷＬＡＮ３１に入るとき（第３の位置）
・ＭＮ１０Ｄ：ＷＬＡＮ３１から出るとき（第４の位置）
　図２において、ＭＮ１０は第１の位置（ＭＮ１０Ａ）において３ＧセルラインタフェースＩｆ１及びＷＬＡＮインタフェースＩｆ２を介してそれぞれＭＡＧ２２及びＭＡＧ２０に接続（attach）すると、それぞれＭＡＧ２２及びＭＡＧ２０からのＲＡメッセージ２６及び２５内のプリフィックスＰ１、Ｐ２を参照する。ＭＮ１０は外部プリフィックスＰ２を参照すると、従来ではＬＭＡ／ＨＡ４０に対してＣＭＩＰｖ６登録５０を実行する。また、ＭＮ１０が移動してＷＬＡＮ３０と接続性（connectivity）のない第２の位置（ＭＮ１０Ｂ）に来たとき、従来ではＭＮ１０はＣＭＩＰｖ６登録削除５１を送信するかもしれない。次に、ＭＮ１０が別のＷＬＡＮ３１と接続性のある第３の位置（図のＭＮ１０Ｃ）に移動したときに、従来ではＭＮ１０はＷＬＡＮインタフェースＩｆ２への到達性を取得するためのＣＭＩＰｖ６登録５２を送信する。次にＭＮ１０がＷＬＡＮ３１と接続性のない第４の位置（図のＭＮ１０Ｄ）に移動すると、従来ではＭＮ１０はＣＭＩＰｖ６登録削除５３を送信するかもしれない。
　従来のＣＭＩＰｖ６登録５０～５２及びＣＭＩＰｖ６登録削除５３のＢＵメッセージは、すべてＷＬＡＮインタフェースＩｆ２のＰＭＩＰｖ６接続のためのＢＵ（ＰＢＵ：Proxy Binding Update）登録及びＰＢＵ登録削除に関連している。したがって、本発明の第1の実施の形態で説明した手法を用いることで、このようなＣＭＩＰｖ６のシグナリング（５０～５３）を削減して最適化することができる。これは、ＷＬＡＮインタフェースＩｆ２がホームＰＭＩＰｖ６ドメインであるネットワーク１００に接続（attach）していて、ＷＬＡＮインタフェースＩｆ２のＣＭＩＰｖ６のキャッシュの内容がＬＭＡ／ＨＡ４０で生成可能とする手法を用いることで実現されている。以上の説明から、本発明の第1の実施の形態では、ＭＮ１０がホームＰＭＩＰｖ６ドメイン１００をローミングしてすべてのインタフェースＩｆ１、Ｉｆ２がホームＰＭＩＰｖ６ドメイン１００に接続（attach）していることを判断、予測又は推定し、外部プリフィックスＰ２を参照したインタフェースＩｆ２のＣＭＩＰｖ６シグナリングを最適化するメカニズムを提供する。
　そこで、第１の実施の形態では、ＭＮ１０は、すべてのインタフェースＩｆ１、Ｉｆ２がホームＰＭＩＰｖ６ドメイン１００に接続（connect）するかもしれないことを予測すると、ＬＭＡ／ＨＡ４０に対して、ＣＮ６０、６１からＭＮ１０の１つのＨｏＡあてに到着する１つのフローに対してすべてのインタフェースＩｆ１、Ｉｆ２を同時に使用できるようにするために、外部プリフィックスＰ２を参照したインタフェースＩｆ２のＣＭＩＰｖ６バインディングキャッシュを生成して、ＭＮ１０がリフレッシュしなくても維持管理するように要求する。なお、ＭＮ１０は、割り当てられたプリフィックスが異なる場合に、各インタフェースが同一のホームドメインに接続しているか否かを判断した上で、ＬＭＡ／ＨＡ４０に対して上記の要求を行ってもよい。この場合、以下にも記述するように、ＭＮ１０がネットワークに接続した際に、接続しているドメインを示すドメインＩＤやドメイン番号、オペレータ（PLMN:Public Land Mobile Network）ＩＤやオペレータ番号などの識別子を取得・比較することで、同一のドメインに接続しているか否かを判断してもよい。また、あらかじめ割り当てられているプリフィックスの情報と、ネットワークに接続した際に割り当てられたプリフィックスを比較することで、ホームドメインに接続しているか否かを判断してもよい。
　＜メッセージシーケンス及びＢＣ＞
　図３は第１の実施の形態に係るメッセージシーケンス（１）～（１１）を示し、図４はＬＭＡ／ＨＡ４０におけるバインディングキャッシュ（ＢＣ）２１３ａを示す。ＭＮ１０は３ＧセルラインタフェースＩｆ１及びＷＬＡＮインタフェースＩｆ２の２つのインタフェースを有する。まず、ＭＮ１０は３ＧセルラインタフェースＩｆ１を介して、１つのＬＭＡ／ＨＡ４０を有するホームＭＩＰｖ６ドメイン（ネットワーク１００）に接続（connect）する。ＬＭＡ／ＨＡ４０はまた、ホームＰＤＮゲートウェイとも呼ばれる。ＭＮ１０は別のデータパケット・ネットワークに接続（connect）しているＣＮ６０と通信している。ＭＮ１０はインタフェースＩｆ１、Ｉｆ２の両方に対して、１つのホームプリフィックスＰ１と１つのＨｏＡを有し、ＣＮ６０はデータパケットをＭＮ１０のＨｏＡあてに送信する。ＭＮ１０はそのデータパケットをインタフェースＩｆ１、Ｉｆ２の両方を使用して受け取りたい。
　（１）ＭＮ１０は３ＧセルラインタフェースＩｆ１経由でＭＡＧ（ＭＡＧ／３Ｇ）２２からの広告ビーコン（不図示）を検知すると、Ｌ２アソシエート信号（L2 associate signal）３０５をＭＡＧ２２に送信する。このビーコンはあるパラメータ、例えばネットワークタイプ（ＰＭＩＰを採用しているか否か）を特徴付けるドメインＩＤ及びドメイン番号を含む。ＭＮ１０は自身のホームＭＩＰｖ６ネットワーク１００のドメインＩＤに関する何かの静的な情報を自身のメモリ内にストアしていてもよい。したがって、ＭＮ１０はビーコンから入手したドメインＩＤと上記の自身の静的な情報を比較することにより、このドメインがＭＮ１０のホームＭＩＰｖ６ドメイン１００であってＭＡＧ２２がホームのＬＭＡ／ＨＡ（ＬＭＡ／ＨＡ／ＰＤＮ４０ Gateway）４０でないものと推論してもよい。
　（２）ここで、ＭＮ１０は、ＭＮ１０をユニークに識別するＬ２セキュリティ証明書（credential）をＬ２アソシエート信号３０５で送信するものとする。ＭＡＧ２２はこの証明書を不図示のＡＡＡサーバに転送して、ＡＡＡサーバから資格認証（authorization）を受け取る。ＭＮ１０が資格認証されると、ＰＢＵ／ＰＢＡシグナリング３０６で示すようにＭＡＧ２２はＰＢＵメッセージをＬＭＡ／ＨＡ４０に送信し、ＬＭＡ／ＨＡ４０からその応答としてＰＢＡｃｋ（ＰＢＡ）メッセージを受信する。このとき、ＬＭＡ／ＨＡ４０は、図４に示すＢＣ２１３の第１のエントリＥ１においてインタフェースＩｆ１のＰＭＩＰｖ６キャッシュを作成する。
　（３）次いで、ＭＡＧ２２はＲＡメッセージ３０７を送信し、ＭＮ１０は、ＲＡメッセージ３０７内のＭＮ１０のホームＭＩＰｖ６プリフィックスＰ１を参照する。
　（４）ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ
　ＭＮ１０は、ホームＭＩＰｖ６プリフィックスＰ１を参照してこのドメインがホームＭＩＰｖ６ドメインであることを知得すると、ＭＮ１０の他のインタフェース（ＷＬＡＮインタフェースＩｆ２）が更にこの同じホームＭＩＰｖ６ドメイン１００及びＬＭＡ／ＨＡ４０に接続（connect）する可能性が高いことを予測する。ＭＮ１０はこのように予測すると、本発明に係るＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を、ＭＡＧ２２（及びインタフェースＩｆ１）を介してＬＭＡ／ＨＡ４０に送信する。
　ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８の送信元アドレスは、ホームＭＩＰｖ６プリフィックスＰ１から構成したＭＮ１０のＨｏＡである。ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８の目的は、ＬＭＡ／ＨＡ４０に対し、ＬＭＡ／ＨＡ４０に接続（attach）して外部プリフィックスＰ２を参照したＭＮ１０のすべてのインタフェースのＣＭＩＰｖ６バインディングキャッシュ（図４の第３のエントリＥ３参照）を生成して維持管理するよう要求することにある。ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８は多くの内容を有し、ホームＭＩＰｖ６プリフィックスＰ１を参照した３ＧセルラインタフェースＩｆ１を除くＭＮ１０のすべてのインタフェース（Ｉｆ２）の識別子（Ｉｆ２－ＩＤ）を含む。このインタフェース識別子（Ｉｆ２－ＩＤ）は、ホームＭＩＰｖ６ドメイン内で外部プリフィックスＰ２を参照したＭＮ１０のインタフェースＩｆ２のＣｏＡをＬＭＡ／ＨＡ４０が生成するのに使用される。なお、ＭＮ１０は、すべてのインタフェースに関するＣｏＡそのものを通知してもよい。
　さらに、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８内のＭＮ１０のインタフェースＩｆ２がホームＭＩＰｖ６ドメイン１００に接続（attach）したか否かは、ＬＭＡ／ＨＡ４０により、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８内のインタフェース識別子（Ｉｆ２－ＩＤ）と、他のＭＡＧ２０からＰＢＵメッセージ（シグナリング３１０）内のインタフェース識別子（Ｉｆ２－ＩＤ）で示されるＭＮ１０のＰＭＩＰｖ６接続（attachment）の情報を用いてトレースされる。上記のＣｏＡは、そのインタフェースＩｆ２に関連するＰＭＩＰｖ６プリフィックスＰ２とインタフェース識別子Ｉｆ２－ＩＤをＬＭＡ／ＨＡ４０が連結することにより生成される。
　ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８は更に、すべてのインタフェース（インタフェース識別子）に関連するバインディング識別子（ＢＩＤ）を含む。ただし、ＭＮ１０が２つのインタフェースＩｆ１、Ｉｆ２のみを有する場合には、単にフラグＨの情報だけを用いてもよい。しかし、ＭＮ１０の２つ以上のインタフェースが同じホームＭＩＰｖ６ドメインに接続（connect）していて、個々のＣＭＩＰｖ６キャッシュ及びＰＭＩＰｖ６キャッシュを区別する場合には、それぞれのキャッシュに対してＢＩＤを必要とする。
　ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８は望ましくは、新しいモビリティ拡張ヘッダを有する新しいモビリティ・メッセージで構成することができる。この種のモビリティ・メッセージは、ＩＡＮＡ（Internet Assigned Numbers Authority）によりメッセージの識別番号が割り当てられることを必要とする。インタフェース識別子とＢＩＤは、その新しいモビリティ・メッセージのオプションとして伝送される。又は、そのモビリティ・メッセージは、インタフェース識別子とＢＩＤを新しいオプションとして含むＢＵメッセージでもよい。又は、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８は、３Ｇネットワークへ接続する際の接続手続き（Attach Procedure）の中で送信するメッセージであってもよいし、ＭＡＧ２２あてのセキュリティ・トークン付きのＬ２メッセージでもよい。ただし、ＬＭＡ／ＨＡ４０はこのセキュリティ・トークンをユニークに解読できるものとする。ＭＡＧ２２はＬ２メッセージで受信したキャッシュ生成・維持管理要求の内容をＰＢＵメッセージ（３０６）でＬＭＡ／ＨＡ４０に転送することもできる。ＬＭＡ／ＨＡ４０は、セキュリティ・トークンを用いて転送されたメッセージの有効性をベリファイしてそのメッセージを処理してもよい。
　ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８をＬＭＡ／ＨＡ４０に送信する方法は多くある。なお、インタフェース識別子を用いてキャッシュを識別できる場合は、ＢＩＤを送信する必要はない。また、ＢＩＤを用いてキャッシュを識別できる場合は、インタフェース識別子を送信する必要はない。しかし、ＭＮ１０が１つのインタフェースに対して１つのプリフィックスから複数のアドレスを生成する場合、ＢＩＤを送信することが適切である。
　ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８はインタフェースＩｆ１からＭＡＧ２２に転送されてＬＭＡ／ＨＡ４０あてにトンネル化される。ＬＭＡ／ＨＡ４０はＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を受信すると、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８内の情報をストアし、ネットワーク１００内の他のＭＡＧ２０を介したＭＮ１０の他のインタフェース接続（attachment）をモニタする。なお、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８は、インタフェースＩｆ２を介して送信されてもよい。つまり、ＭＮ１０のＷＬＡＮインタフェースＩｆ２がホームＰＭＩＰｖ６ドメイン１００に接続（attach）したと判断できる場合に、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８をＩｆ２から送信してもよい。この場合、Ｉｆ２がＭＡＧ２０に接続する際に行う接続手続き（Attach Procedure）の中のメッセージを用いて、ＭＡＧ２０に対して接続することを要求すると同時に、ＣＭＩＰｖ６キャッシュの生成・維持管理を要求する。この場合、Ｉｆ２の接続するネットワークがＮｏｎ３ＧＰＰネットワークのUntrustedネットワークである場合は、ｅＰＤＧ機能を持つＭＡＧ２０との間で行うＳＡ（Security Association）確立手続き（ＩＫＥｖ２）の中でＣＭＩＰｖ６キャッシュの生成・維持管理を要求する。一方、Ｉｆ２の接続するネットワークがＮｏｎ３ＧＰＰネットワークのTrustedネットワークである場合は、ＡＧＷ（Access Gateway）に対して行うアクセス認証、又はＬ３接続手続きの中で、ＣＭＩＰｖ６キャッシュの生成・維持管理を要求する。これにより、ＭＮ１０は、ＣＭＩＰｖ６キャッシュを生成・更新するためのＢＵメッセージを送信する必要がなくなる。なお、ＣＭＩＰｖ６キャッシュの生成・維持管理を要求する情報として、３ＧＰＰ／Ｎｏｎ３ＧＰＰネットワークに接続し、使用するモビリティ・プロトコル（ＰＭＩＰｖ６、ＣＭＩＰｖ６、ＭＩＰｖ４のいずれか１つ）を指定する際に、単なるＰＭＩＰｖ６を指定するのではなく、ＣＭＩＰｖ６キャッシュを生成することも同時に意味する値（例えば、ＰＭＩＰｖ６接続し、さらに複数ＩＦの同時に使用することを示すIndicator（ＰＭＩＰｖ６＋ＣＭＩＰｖ６））を指定してもよい。
　さらに、ＭＮ１０のＷＬＡＮインタフェースＩｆ２がＭＡＧ２０及びＬＭＡ／ＨＡ４０との接続が完了した後に、別途ＣＭＩＰｖ６キャッシュ生成・維持管理要求を、ＢＵメッセージ等を用いてＩｆ２から送信してもよい。これにより、最初に１回だけＢＵメッセージを送信すれば、以後ＣＭＩＰｖ６キャッシュを更新するためのＢＵメッセージを送信する必要がなくなる。さらには、上記ＢＵメッセージを送信する前にＬＭＡ／ＨＡ４０との間で行うＳＡ確立手続き（ＩＫＥｖ２）の中でＣＭＩＰｖ６キャッシュ生成・維持管理を要求してもよい。なお、使用するＩＫＥｖ２メッセージとしては、ＩＫＥ＿ＡＵＴＨリクエストメッセージや、ＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージなどが望ましい。
　このように、ＭＮ１０の他のインタフェースＩｆ２がネットワーク１００に接続（attach）しており、ＣＭＩＰｖ６キャッシュ生成・維持管理の要求がＩｆ２経由で通知される場合、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を受信したＬＭＡ／ＨＡ４０は、既存のインタフェースＩｆ２に関するＰＭＩＰｖ６バインディングに基づいてＩｆ２のＣＭＩＰｖ６キャッシュを生成し、更にＭＮ１０がリフレッシュすることなく維持管理する。ＬＭＡ／ＨＡ４０によって生成されるＣＭＩＰｖ６キャッシュとは、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８から得られたＨｏＡと、ＰＭＩＰｖ６プリフィックスＰ２から生成されたＣｏＡと、ＭＮ１０から送信されたインタフェース識別子を含む。ここで、インタフェース識別子は６４ビットである。
　ＬＭＡ／ＨＡ４０はまた、このＣＭＩＰｖ６バインディングに対して、ＭＮ１０によりＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８で与えられるＢＩＤを関連付ける。ＬＭＡ／ＨＡ４０は更に、このＣＭＩＰｖ６バインディングに存続期間を割り当てる。この存続期間は第１のＰＭＩＰｖ６バインディングの存続期間と同じである。ここで、第２のＰＭＩＰｖ６バインディングとは、インタフェースＩｆ２のＣｏＡを生成するのに使用された外部ＰＭＩＰｖ６プリフィックスＰ２に関連するバインディングである。基本的に、このＣＭＩＰｖ６バインディングキャッシュの構造は、図４の第３のエントリＥ３に示すように
・ＨｏＡ（ホームプリフィックスＰ１）と、
・ＣｏＡ（外部プリフィックスＰ２＋インタフェース識別子Ｉｆ２－ＩＤ）と、
・ＢＩＤと、
・存続期間３（＝第１のＰＭＩＰｖ６バインディングの存続期間１）より成る。
　（５）次に、図３では示されていないが、ＭＮ１０はメッセージ３０８の送信後に、ＷＬＡＮインタフェースＩｆ２経由でＷＬＡＮビーコンを受信するものとする。ＭＮ１０はＷＬＡＮ３０の不図示のアクセスルータ（ＡＲ）から広告されたプリフィックスＰ２からＷＬＡＮインタフェースＩｆ２のアドレスを構成し、次いでｅＰＤＧであるＭＡＧ（ＭＡＧ／ＷＬＡＮ）２０を発見すると、ＭＡＧ２０とのＩＰＳｅｃトンネル・セットアップ手続を開始する。この手続では、まず、ＭＮ１０は接続認証（authentication）パラメータ付きのＩＫＥｖ２メッセージ（IKEV2 authentication and setup）３０９をＭＡＧ２０に送信する。なお、ＩＫＥｖ２メッセージ３０９の中に、ＭＡＧ２０経由で接続するＮｏｎ３ＧＰＰネットワークへＰＭＩＰを用いて接続することを示す情報が含まれていてもよい。また、前述したように、メッセージ３０８の代わりに、（５）のＩＫＥｖ２メッセージ３０９を用いて、ＣＭＩＰｖ６キャッシュ生成・維持管理要求を通知してもよい。この場合、（９）のＩＫＥｖ２完了メッセージで、ＣＭＩＰｖ６キャッシュ生成・維持管理要求が受け入れられたか否かがＭＮ１０へ通知される。
　（６）ＭＡＧ２０は不図示のＡＡＡサーバに問い合わせてＭＮ１０が資格認証（authorize）されると、ＬＭＡ／ＨＡ４０とのＰＢＵ／ＰＢＡｃｋシグナリング３１０を実行して、インタフェースＩｆ２及び外部プリフィックスＰ２のＰＭＩＰｖ６ルーティングステートを生成する。
　（７）ＬＭＡ／ＨＡ４０は、第２のエントリＥ２であるＰＭＩＰｖ６バインディングキャッシュを生成し、次いで、ＮＡＩでユニークに識別されるＭＮ１０が、ＬＭＡ／ＨＡ４０に接続（connect）されるインタフェースＩｆ２を有することを知得すると、前述したＣＭＩＰｖ６キャッシュの生成・維持管理の要求に従い、第２のエントリＥ２であるＰＭＩＰｖ６バインディングキャッシュに関連するインタフェースＩｆ２のＣＭＩＰｖ６バインディング・キャッシュ（第３のエントリＥ３）を生成する。このキャッシュの詳しいパラメータは既に詳細に説明した。
　この時点で、ＬＭＡ／ＨＡ４０は、要求メッセージ３０８に対する応答メッセージ３１１をＭＮ１０に送信して、インタフェースＩｆ２が同じホームＭＩＰｖ６ドメイン１００（ＬＭＡ／ＨＡ４０）に接続（connect）しており、インタフェースＩＦ２用のＣＭＩＰｖ６キャッシュがＬＭＡ／ＨＡ４０によって自動的に生成されたこと、さらには、インタフェースＩｆ２用のＢＩＤ付き又はフラグＨ付きのＣＭＩＰｖ６のＢＵメッセージ（図１４の２１２）を送信する必要がないことを通知してもよい。応答メッセージ３１１は、最初のメッセージ３０８に対するＬＭＡ／ＨＡ４０からの応答を通知する方法の１つであり、メッセージ３０８に対する応答であること示すタイプを含むＣＭＩＰｖ６登録削除メッセージ（ＢＡメッセージ）を用いることができるが、他の応答方法として、ＬＭＡ／ＨＡ４０は、トンネル・セットアップ完了メッセージ３１２内の新しいオプションをＭＡＧ２０に送信して、ＭＮ１０にＣＭＩＰｖ６のＢＵメッセージ２１２を送信しないよう通知してもよく、また、ＬＭＡ／ＨＡ４０がＭＡＧ２０又はＭＡＧ２２に対して通知し、それをＭＡＧ２０，２２がＭＮ１０に対してＲＡメッセージやその他の任意のＬ３メッセージ（モビリティヘッダメッセージを含む）、あるいはＬ２メッセージなどでＭＮ１０に通知してもよい。他にも多くの方法が考えられる。
　（８）次いで、トンネル・セットアップ完了メッセージ（IPSec tunnel Setup Completion）３１２がＭＡＧ２０からＭＮ１０に送信される。
　（９）次いでＩＫＥｖ２手順が完了してＩＫＥｖ２完了メッセージ（IKEv2 IP address/Prefix assignment）３１３がＭＡＧ２０からＭＮ１０に送信されて外部プリフィックスＰ２がＭＮ１０に通知される。ＭＮ１０はＩＫＥｖ２完了メッセージ３１３を受信すると、ＷＬＡＮインタフェースＩｆ２あてのパケットを取得するためのＣＭＩＰｖ６のＢＵメッセージ２１２を送信する必要はなく、ＬＭＡ／ＨＡ４０がＷＬＡＮインタフェースＩｆ２用のＣＭＩＰｖ６バインディングを生成し、パケットがＷＬＡＮインタフェースＩｆ２に到着する。
　（１０）ＣＮ６０はＭＮ１０あてのデータパケット３１４を、プリフィックスＰ１から構成されたＭＮ１０のＨｏＡあてに送信する。ＣＮ６０から送信された上記のパケットがＬＭＡ／ＨＡ４０に到着すると、ＬＭＡ／ＨＡ４０はＢＣ２１３ａにおける第１のエントリＥ１（ＰＭＩＰｖ６エントリ）を使用したプリフィックスベースのルーティングを実行し、また、ＢＣＥ２１３ａにおける第３のエントリのＣＭＩＰｖ６キャッシュを使用したＨｏＡマッチングのルーティングを実行する。
　（１１）（１２）図３では、第１のエントリＥ１（ＰＭＩＰｖ６キャッシュ）を使用してＭＮ１０にルーティングされるデータパケット３１４ａ、３１４ｂと、第３のエントリＥ３（ＣＭＩＰｖ６キャッシュ）を使用してＭＮ１０にルーティングされるデータパケット３１５ａ、３１５ｂを示す。第１のエントリＥ１を使用してルーティングされるデータパケット３１４ａ、３１４ｂは、ＭＡＧ２２経由でトンネル化される。また、もし、ＬＭＡ／ＨＡ４０が第３のエントリＥ３であるＣＭＩＰｖ６キャッシュを使用してＭＮ１０にルーティングすることを決定すると、そのデータパケット３１４はＬＭＡ／ＨＡ４０により複数回（ここでは２回）のカプセル化が行われてトンネル化される（図のパケット３１５ａ）。データパケット３１５ａの場合、最初のカプセル化は、ＭＮ１０のＷＬＡＮインタフェースＩｆ２のＣｏＡあてにトンネル化される。そして、更に１回のカプセル化が必要となり、２回目のカプセル化では、そのデータパケット３１５はＭＡＧ２０のアドレスあてにトンネル化される。ＬＭＡ／ＨＡ４０により２回のカプセル化が行われたパケット３１５ａはＭＡＧ２０によりデ・カプセル化され、元の１回のカプセル化が行われたパケット３１５ｂがＭＮ１０に転送されてＭＮ１０により完全にデ・カプセル化される。ここで、当業者であれば、ＬＭＡ／ＨＡ４０が図４に示すＢＣ２１３ａを用いてデータパケット３１４をどのように適切にカプセル化するかは明らかである。
　また、ＷＬＡＮインタフェースＩｆ２あてのパケットはＭＮ１０あてに直接にトンネル化することができる。この場合には、あて先アドレス（トンネル化パケットのあて先アドレス）はＭＡＧ２０のアドレスであって、トンネル化パケットのルーティング・ヘッダタイプ０に、外部プリフィックスＰ２から構成したＣｏＡとＭＮ１０のＨｏＡを挿入する。このトンネル化方法によれば、ＭＡＧ２０における余分なトンネル化によるオーバヘッドが増加することを防止することができる。
　＜ＣＭＩＰｖ６キャッシュの存続期間＞
　図４に示すように、第３のエントリＥ３（ＣＭＩＰｖ６キャッシュの存続期間３）は、第２のエントリＥ２の存続期間２に関係なく、第１のエントリＥ１の存続期間１を用いて維持されて存続期間１が満了すると削除される。ＭＮ１０のＷＬＡＮインタフェースＩｆ２が、ＷＬＡＮ３０、３１の連続していない小さなセルに接続（connect）する場合、ＷＬＡＮインタフェースＩｆ２がハンドオフしてＷＬＡＮ３０、３１の配下にないことが多く発生する。この場合、ＷＬＡＮインタフェースＩｆ２のＣＭＩＰｖ６キャッシュが３ＧセルラインタフェースＩｆ１のＰＭＩＰｖ６キャッシュの存続期間１に基づいて維持されることが有益である。その理由は、ＬＭＡ／ＨＡ４０がＷＬＡＮインタフェースＩｆ２のＣＭＩＰｖ６キャッシュを頻繁に生成する必要がないからである。ここで重要な点は、３Ｇセル（ホームＰＭＩＰｖドメイン１００）がＷＬＡＮ３０、３１よりかなり大きく、３ＧセルラインタフェースＩｆ１が頻繁にハンドオフしないことにある。
　以下に動作を説明する。まず、ＭＮ１０のＷＬＡＮインタフェースＩｆ２のＣＭＩＰｖ６キャッシュ（存続期間３）が３ＧセルラインタフェースＩｆ１のＰＭＩＰｖ６キャッシュの存続期間１に基づいて維持されており、ＷＬＡＮインタフェースＩｆ２のＰＭＩＰｖ６キャッシュ（第２のエントリＥ２）がハンドオフ前に有効な場合、パケットは第２のエントリＥ２を用いてＭＡＧ３０２を経由してＷＬＡＮインタフェースＩｆ２に到達する。これに対し、ＷＬＡＮインタフェースＩｆ２のＰＭＩＰｖ６キャッシュがハンドオフにより有効でなくなると、ＷＬＡＮインタフェースＩｆ２に関連するＣｏＡあてのパケットは、第１のエントリＥ１を用いて３ＧセルラインタフェースＩｆ１に送信される。この場合、ＭＡＧ３０１はＬＭＡ／ＨＡ４０により、外部プリフィックスＰ２についての何らかの有効性の情報をトンネル化パケットヘッダ内で与えられるものとする。
　＜第１の実施の形態による利点＞
　以下に、第１の実施の形態による利点について考察する。第１の利点として、ＬＭＡ／ＨＡ４０がＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８に応答してＣＭＩＰｖ６バインディングキャッシュを生成して、ＭＮ１０によりリフレッシュされることなく維持管理するので、ＭＮ１０は、ＣＭＩＰｖ６登録メッセージを送信する必要がなくなり、さらにＬＭＡ／ＨＡ４０は、ＣＭＩＰｖ６バインディングを用いてデータパケットをルーティングするためには、ＰＭＩＰｖ６バインディングキャッシュをサーチすることが必要であると知得することができる。ＬＭＡ／ＨＡ４０がＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を受信してＣＭＩＰｖ６バインディングキャッシュを生成するとき、ＬＭＡ／ＨＡ４０は、パケットをどのようにルーティングするかを示す別のパラメータをＢＣ２１３ａに挿入することもできる。これにより、ＬＭＡ／ＨＡ４０がＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を受信しないで、ＣＭＩＰｖ６バインディングキャッシュを使用してパケットをどのようにルーティングするかを識別する必要がある場合と比較して、ＬＭＡ／ＨＡ４０の処理の負荷を減少させることができる。
　例えば、もしＭＮ１０がＷＬＡＮインタフェースＩｆ２経由で別の外部ドメインに接続（attach）すると、ＬＭＡ／ＨＡ４０はＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８の応答として、ＣＭＩＰｖ６バインディングキャッシュを生成しないで、ＷＬＡＮインタフェースＩｆ２のＣＭＩＰｖ６バインディングキャッシュには、回帰的なトレーシングを実行しなければならないエントリとしてマークしない。したがって、ＬＭＡ／ＨＡ４０は、外部ドメインから取得したＣｏＡあてにルーティングするためには、デフォルト・ルータに送信することで十分であることを知得する。
　別の顕著な利点とは、ＬＭＡ／ＨＡ４０がルーティングするホームＭＩＰｖ６ドメインに接続（connect）するとともに、外部プリフィックスＰ２を参照したインタフェースあてにトンネル化されたパケットを取得できるインタフェースについては、ＭＮ１０はＢＵを実行する必要がないことにある。本発明は、ＭＮ１０がフラグＨベースのＢＵを実行してすべてのフローがＷＬＡＮインタフェースＩｆ２のみに到着するよう要求する場合に有用である。ＭＮ１０は非常に秘密性のあるフローを有し、そのフローがＬＭＡ／ＨＡ４０からＭＮ１０に直接にトンネル化されることを希望するかもしれない。
　＜ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８の別の形態＞
　図５は別の３つの形態のＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０６Ａ、（３０７Ａ１、３０７Ａ２）、（３０８Ａ１、３０８Ａ２）を示す。ＭＮ１０はまず、３ＧインタフェースＩｆ１経由でホームＭＩＰｖ６ドメイン１００に接続（attach）してホームプリフィックスＰ１を参照した場合、前述したようにＭＮ１０が、ＬＭＡ／ＨＡ４０からの外部プリフィックスＰ２を参照したＷＬＡＮインタフェースＩｆ２のＣＭＩＰｖ６バインディング・キャッシュを生成・維持管理するようＬＭＡ／ＨＡ４０に要求するには種々の形式のシグナリングを実行できる。
　（１）最初の望ましい方法では、ＭＮ１０はＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０６Ａを直接にＬＭＡ／ＨＡ４０に送信する。この場合、メッセージ３０６Ａの送信元アドレスは、ホームプリフィックスＰ１を使用して構成したＭＮ１０のＨｏＡであり、あて先アドレスはＬＭＡ／ＨＡ４０のアドレスである。メッセージ３０６Ａは拡張ヘッダの新しいヘッダタイプを用いて構成することができる。もし、この拡張ヘッダの新しいヘッダタイプをメッセージ３０６Ａに使用すると、ＬＭＡ／ＨＡ４０におけるメッセージ３０６Ａの処理はやや簡単になる。ＬＭＡ／ＨＡ４０はメッセージ３０６Ａから新しいヘッダタイプが何かを知得してメッセージ３０６Ａをどのように処理するかを知得する。
　インタフェース識別子とＢＩＤのようにＭＮ１０の他のインタフェース（ＷＬＡＮインタフェースＩｆ２）を識別するための情報は、メッセージ３０６Ａ内のオプションとして又はデータフィールドに埋め込むことができる。メッセージ３０６ＡはＭＡＧ２２からＬＭＡ／ＨＡ４０まではトンネル化される。もし、メッセージ３０６ＡがＭＩＰｖ６に記述されているＢＵメッセージの場合、上記の他のインタフェースのインタフェース識別子とＢＩＤは、ＢＵメッセージ内にモビリティ・オプションとして埋め込まれる。このモビリティ・オプションは新しいタイプのオプションである。
　（２）また代わりに、ＣＭＩＰｖ６キャッシュ生成・維持管理要求は、ＭＡＧ２２に送信されるＬ２メッセージ３０７Ａ１で送信することもできる。このＬ２メッセージ３０７Ａ１は、上記の他のインタフェースのインタフェース識別子とＢＩＤを伝送する。ここで、Ｌ２メッセージ３０７Ａ１の送信元アドレスはＭＮ１０のインタフェースＩｆ１のＬ２アドレスであり、あて先アドレスはＭＡＧ２２のイングレス・インタフェースのＬ２アドレスである。ＭＡＧ２２はメッセージ３０７Ａ１で上記のパラメータ（インタフェース識別子とＢＩＤ）を受信すると、メッセージ３０７Ａ１の内容を、ＬＭＡ／ＨＡ４０あてのメッセージ３０７Ａ２で送信する。また、上記のＬ２メッセージと同等の内容を含む、ＲＳメッセージやＮＳメッセージ、認証メッセージ（ＩＫＥｖ２メッセージ）など、他の任意のＬ３メッセージ（モビリティヘッダメッセージを含む）を用いてもよい。さらに、３ＧＰＰネットワーク（ＭＡＧ２２）へ接続する際に行う接続手続き（Attach Requestメッセージ）の中で通知してもよい。
　メッセージ３０７Ａ２はＰＢＵメッセージでもよく、また、新しいモビリティ拡張ヘッダを有する別のシグナリング・メッセージでもよい。ここで、メッセージ３０７Ａ２がＰＢＵメッセージの場合、ＬＭＡ／ＨＡ４０がそのＰＢＵメッセージをどのように処理してＣＭＩＰｖ６キャッシュの生成・維持管理の要求を知得できるように、上記の他のインタフェースのインタフェース識別子とＢＩＤがそのＰＢＵメッセージの新しいモビリティ・オプションとして挿入される必要がある。また、メッセージ３０７Ａ２が新しいモビリティ拡張ヘッダを有する別のシグナリング・メッセージの場合、上記の他のインタフェースのインタフェース識別子とＢＩＤはメッセージ内の通常のフィールドに挿入することができる。ただし、この場合、ＬＭＡ／ＨＡ４０の構成は、この新しいメッセージを理解するために変形する必要がある。この構成が変形されたＬＭＡ／ＨＡ４０は、この新しいメッセージを受信するとどのように処理するかを知得する。
　（３）また、ＭＮ１０が３ＧインタフェースＩｆ１経由で参照したホームプリフィックスＰ１を選択する場合、ＭＮ１０はまず、メッセージ３０８Ａ１で示すようにその選択した旨をＤＮＳサーバ３０４Ａ（図のＤＮＳ／ＳＩＰ server／ＡＡＡ）に通知して、上記の他のインタフェースのインタフェース識別子とＢＩＤをメッセージ３０８Ａ１で提供することもできる。ＤＮＳサーバ３０４Ａはこの新しいプリフィックスＰ１をアクセプトして、ＬＭＡ／ＨＡ４０に対してメッセージ３０８Ａ２で、選択されたプリフィックスＰ１と、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８の内容を転送する。
　ここで、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０６Ａ、（３０７Ａ１、３０７Ａ２）、（３０８Ａ１、３０８Ａ２）による各方法が特有の利点を有することを理解するべきである。メッセージ（３０８Ａ１、３０８Ａ２）の場合、２つの実現を達成することができる。１つ目は、ホームプリフィックスＰ１を選択すると、ＬＭＡ／ＨＡ４０にＣＭＩＰｖ６キャッシュ生成・維持管理を要求することにある。２つ目は、ＭＮ１０がメッセージ３０８Ａ１を送信することによりＷＬＡＮアクセスポイントを識別した場合、ＭＮ１０はｅＰＤＧアドレスを取得できることにある。
　＜ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８のフォーマット＞
　メッセージ３０８の詳細な３つの構成例を図６Ａ、図６Ｂ、図６Ｃを参照して説明する。
　（ａ）図６Ａに示すフレーム３０７Ｂは、メッセージ３０８がＬ２メッセージ３０７Ａである場合のフレーム構造を示し、先頭から順次、開始フラグ（Flag）３００Ｂと、アドレス（Address）３０１Ｂと、制御（Control）３０２Ｂと、プロトコルＩＤ（Protocol ID）３０３Ｂと、情報（Information）３０４Ｂと、ＦＣＳ（Frame Check Sequence）３０５Ｂと終了フラグ（Flag）３０６Ｂの各フィールドにより構成されている。
　開始フラグ３００Ｂはフレーム３０７Ｂの先頭を示すフラグであり、２番目のフィールドのアドレス３０１Ｂは、ＭＡＣ（Media Access Control）アドレスであって、Ｌ２パケットの送信元アドレスとあて先アドレスを含む。例えば送信元アドレスはＭＮ１０のインタフェースＩｆ１のＭＡＣアドレスであり、あて先アドレスはＭＡＧ２２のイングレス・インタフェース（不図示）のＭＡＣアドレスである。３番目のフィールドの制御３０２Ｂは、使用されているフレームのタイプを識別するための情報であって、受信側がこのＬ２のフレーム３０７Ｂを正しく処理するために重要である。基本的に、制御３０２Ｂは、フレーム３０７ＢのタイプすなわちＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８（３０７Ａ）のタイプを識別するために使用される。
　４番目のフィールドのプロトコルＩＤ３０３Ｂは、上位の層で発生するパケットのみに対する値であって、メッセージ３０８（３０７Ａ）がＬ２で発生する場合にはオール０である。ただし、メッセージ３０８がＬ２で発生することができても、メッセージ３０８を送信する決定と、メッセージ３０８内に埋め込まれている関連パラメータは、Ｌ３から来なければならない。次のフィールドの情報３０４Ｂは、インタフェース識別子とＢＩＤを含む。情報３０４Ｂの後にＦＣＳ３０５Ｂのフィールドが続き、ＦＣＳ３０５Ｂは、フレーム３０７Ｂが誤りなく伝送（誤りが識別及び訂正）されるように送信側と受信側により計算される。最後のフィールドの終了フラグ３０６Ｂは、フレーム３０７Ｂのデ・リミタとして、基本的にはフレーム３０７Ｂの終了を識別するために使用される。
　ここで、フレーム３０７Ｂの構造は、本発明を逸脱しない範囲で図６Ａに示す構造と同じである必要はない。前述したように、ＭＮ１０はＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を送信するためのパケットをＬ３で送信することもできる。Ｌ３のシグナリングが使用される場合には、ＭＮ１０は新しいモビリティ拡張ヘッダか又は新しいオプション付きのＢＵメッセージを使用することができる。
　（ｂ）図６Ｂは、新しいモビリティ拡張ヘッダ（New Mobility extension Header）３１０Ｂを有するシグナリング・パケット３１５Ｂを示す。パケット３１５Ｂについて以下に詳しく説明する。パケット３１５Ｂの最初のヘッダは、標準のＩＰｖ６ヘッダ（IPv6 Header）３０８Ｂであり、ＩＰｖ６ヘッダ３０８Ｂは、ＭＮ１０のＨｏＡがセットされる送信元アドレスと、ＬＭＡ／ＨＡ４０のアドレスがセットされるあて先アドレスを含む。パケット３１５Ｂの次のヘッダは接続認証ヘッダ（Authentication Header）３０９Ｂであり、ＭＮ１０とＬＭＡ／ＨＡ４０の間で交換されたセキュリティ・キーにより署名された接続認証データを有する。ヘッダ３０９Ｂは望ましいフィールドであるが、必須ではない。
　第３のヘッダが新しいモビリティ拡張ヘッダ３１０Ｂであり、ヘッダ３１０Ｂは最初に標準のモビリティ拡張ヘッダ（Standard fields of mobility extension Header）３１１Ｂを有し、標準のモビリティ拡張ヘッダ３１１Ｂは、プロトコル番号、モビリティ・ヘッダタイプ、チェックサムなどを含む。新しいモビリティ拡張ヘッダ３１０Ｂは更に３つの標準のフィールド３１２Ｂ、３１３Ｂ、３１４Ｂを有する。第１のフィールド（Number of interfaces）３１２Ｂは、ホームプリフィックスＰ１を参照したインタフェースＩｆ１からＭＮ１０が除外したインタフェースＩｆ２の数を示す。次のフィールド（interface identifier）３１３Ｂは、第１のフィールド３１２ＢのインタフェースＩｆ２のインタフェース識別子Ｉｆ２－ＩＤを示す。３番目のフィールド（Binding identifier）３１４Ｂは、第２のフィールド３１３Ｂのインタフェース識別子Ｉｆ２－ＩＤに関連する１以上のＢＩＤを示す。ここで、新しいモビリティ拡張ヘッダ３１０Ｂのフィールドを構成する方法は多く存在することを強調したい。ただし、ここでは、望ましい１つの方法であるパケット３１５Ｂを示す。
　（ｃ）図６Ｃは、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を送信するための第３の例としてＢＵメッセージのパケット３２３Ｂの構造を示す。図６Ｂと同様に、パケット３２３Ｂの最初のヘッダはＩＰｖ６ヘッダ（IPv6 Header）３１６Ｂであり、次のヘッダは望ましくは接続認証ヘッダ（Authentication Header）３１７Ｂである。接続認証ヘッダ３１７Ｂの後にＢＵモビリティ拡張ヘッダ（Binding Update mobility extension Header）３１８Ｂが続く。ヘッダ３１８Ｂの最初のフィールドは標準のＢＵ拡張ヘッダ（Standard fields of binding update extension Header）３１９Ｂであり、例えば存続期間、シーケンス番号などのＢＵ内の標準のすべてのフィールドを含む。
　標準のＢＵ拡張ヘッダ３１９Ｂの後に新しいオプション・フィールド（Mobility new option 1,2,3）３２０Ｂ、３２１Ｂ、３２２Ｂが設けられている。図６Ｂと同様に、最初のオプション・フィールド（Mobility new option 1）３２０Ｂはインタフェース数（Number of interfaces）である。また、２番目のオプション・フィールド（Mobility new option 2）３２１Ｂは、ＭＮ１０が最適化したいインタフェース識別子（Interface Identifier）であり、３番目のオプション・フィールド（Mobility new option 3）は、あるインタフェースに関連するＢＩＤが、１つ、または複数含まれる。
　＜ＭＮの動作＞
　次に、図７を参照してＭＮ１０の動作を更に詳しく説明する。複数のインタフェースＩｆを有するＭＮ１０は、まず、あるインタフェースＩｆ経由であるネットワーク・エンティティに接続（attach）すると、ＰＭＩＰｖ６ドメインに接続（attach）しているか否かをチェックする（ステップ４００）。もしＮＯであれば、通常のＣＭＩＰｖ６動作を実行する（ステップ４０２）。ステップ４００でＹＥＳの場合には、ＰＭＩＰｖ６ドメインからそのインタフェースＩｆに対して与えられたプリフィックスがホームプリフィックスＰ１か否かをチェックし、更にこのホームプリフィックスＰ１を知得しているか否かをチェックする（ステップ４０１）。もしＹＥＳの場合には、すべてのインタフェース識別子付きのＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８をＬＭＡ／ＨＡ４０に送信する（ステップ４０３）。
　ステップ４０１でＮＯであれば、すなわちホームプリフィックスＰ１を有しない場合には、ＰＭＩＰｖ６プリフィックスをホームプリフィックスＰ１として選択し、ＨＡのアドレスをＤＮＳサーバに要求して取得する（ステップ４０４）。ここで、ＤＮＳサーバは、ＭＮ１０が選択したホームプリフィックスＰ１でホームのＬＭＡ／ＨＡ４０を更新するものとする。ステップ４０４の処理後、ステップ４０３の処理を実行する。ここで、ステップ４０１でＮＯであってホームプリフィックスＰ１を有しないということは、ＭＮ１０が外部ＰＭＩＰｖ６ドメインに接続（attach）していることを黙示しているので、ＭＮ１０は通常のＣＭＩＰｖ６動作を実行する。
　ステップ４０３の処理後、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８に対する確認（Ａｃｋ）を受信したか否か、又はその応答（フラグ）がＲＡメッセージ又はＩＰｓｅｃトンネル確立確認メッセージ内に記述されているか否かをチェックする（ステップ４０５）。もしＹＥＳであれば、ＣＭＩＰｖ６のＢＵメッセージを送信しないでＲＡメッセージ内のフラグを処理する（ステップ４０６）。その理由は、ホームのＬＭＡ／ＨＡ４０により与えられる外部プリフィックスＰ２を参照したインタフェースＩｆ２のＣＭＩＰｖ６キャッシュは、ホームＬＭＡ／ＨＡ４０が生成して維持管理するからである。ステップ４０５でＮＯの場合は、ＭＮ１０のインタフェースＩｆ２が、ＰＭＩＰｖ６バインディングを使用する同じＬＭＡ／ＨＡ４０に接続（connect）していないことを意味するので、そのインタフェースＩｆ２に対する到達性を取得するためにＣＭＩＰｖ６のＢＵメッセージを送信する（ステップ４０７）。
　＜ＬＭＡ／ＨＡの動作＞
　次に図８を参照してＬＭＡ／ＨＡ４０の動作を更に詳しく説明する。ＬＭＡ／ＨＡ４０は、まず、パケットを受信すると、その受信パケットがＭＮ１０からのシグナリング・パケットか否かをチェックする（ステップ５００）。もしＹＥＳであれば、その受信パケットがＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８か否かをチェックする（ステップ５０１）。もしＮＯであれば、標準のＣＭＩＰｖ６の動作で受信パケットを処理する（ステップ５０３）。ステップ５０１でＹＥＳの場合には、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８に対してＡｃｋメッセージを送信し、また、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８内のインタフェース識別子Ｉｆ－ＩＤとＢＩＤを一時的に保持する（ステップ５０２）。
　ステップ５００で受信パケットがＭＮ１０からのシグナリング・パケットでない場合には、その受信パケットが、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を送信したＭＮ１０あてのデータパケットか否かをチェックする（ステップ５０４）。もしＹＥＳであれば、ＢＣ２１３ａをチェックして、受信パケットをＭＮ１０のすべてのインタフェースＩｆを経由するか、又はＭＮ１０によりセットされたプリファレンスに従って特定のインタフェースＩｆを経由してルーティングする（ステップ５０７）。ステップ５０４でＮＯであれば、受信パケットが、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を送信したＭＮ１０からのデータパケットか否かをチェックする（ステップ５０６）。もしＹＥＳであれば、受信データパケットをデ・カプセル化してイーグレス・インタフェースを介してルーティングする（ステップ５０５）。ＬＭＡ／ＨＡ４０はデ・カプセル化の際、トンネル・エントリポイントがＢＣ２１３ａ内で有効に登録された送信元アドレスかをチェックする。
　ステップ５０６でＮＯであれば、ＬＭＡ／ＨＡ４０は、受信パケットが、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を送信したＭＮ１０のＰＭＩＰｖ６接続（attachment）を示すＭＡＧからのシグナリング・パケットか否かをチェックする（ステップ５０８）。もしＹＥＳであれば、ＬＭＡ／ＨＡ４０はＡｃｋメッセージを送信することにより、ＭＮ１０の他のインタフェースＩｆ２が同じＬＭＡ／ＨＡ４０に接続（attach）していることと、Ａｃｋメッセージが以前に送信されていない場合にはＭＮ１０はＣＭＩＰｖ６－ＢＵを実行する必要がないことを通知する。又はＲＡメッセージでＣＭＩＰｖ６－ＢＵを実行する必要がないことを通知する（ステップ５０９）。ここで、Ａｃｋメッセージは、最初に接続（attach）して外部プリフィックスＰ２を参照したインタフェースＩｆ２には送信する必要はない。ステップ５０９ではまた、ＬＭＡ／ＨＡ４０は、外部プリフィックスＰ２を参照したインタフェースＩｆ２のＣＭＩＰｖ６キャッシュを生成する。
　ステップ５０８でＮＯであれば、ＬＭＡ／ＨＡ４０は、受信パケットがＭＡＧからの、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を送信したＭＮ１０のＰＭＩＰｖ６登録解除を示すシグナリング・パケットか否かをチェックする（ステップ５１０）。もしＹＥＳであれば、ＬＭＡ／ＨＡ４０はＢＣ２１３ａから、そのＣＭＩＰｖ６バインディング（第３のエントリＥ３）と、そのＣＭＩＰｖ６バインディングに関連するＰＭＩＰｖ６バインディング（第２のエントリＥ２）を削除する（ステップ５１１）。ここで、そのＣＭＩＰｖ６バインディングとは、ステップ５０９においてＰＭＩＰｖ６バインディングのパラメータを用いて生成したバインディングのことである。ステップ５１０でＮＯであれば、ＬＭＡ／ＨＡ４０は、受信したシグナリング・パケットを通常のＰＭＩＰｖ６動作で処理する（ステップ５１２）。
　＜ＭＮの構成＞
　次に図９を参照してＭＮ１０の構成について詳しく説明する。図９はＭＮ１０のハードウエア、ソフトウエア及びファームウエアを機能的に示すブロック図である。ＭＮ１０の機能は、概略的にはレイヤ３プロトコル・モジュール４０２Ａと、レイヤ３より上位のレイヤ（層）のプロトコルを実行する上位層プロトコル・モジュール４０１Ａと、レイヤ３より下位の層のプロトコルを実行する下位層プロトコル・モジュール４０８Ａにより構成される。下位層プロトコル・モジュール４０８Ａは、ＭＮ１０の各インタフェースＩｆに関連する複数の層のプロトコル・モジュールにより構成され、下位層プロトコル・モジュール４０８Ａの機能は、主にデータリンク層の制御及び伝送のメカニズムに関連している。
　レイヤ３プロトコル・モジュール４０２Ａは、詳しくは５つのサブ・モジュール（ユニット）、すなわちＩＰｖ６ルーティング・ユニット４０３Ａと、ＭＩＰｖ６モビリティ管理ユニット４０４Ａと、ホームＰＭＩＰドメイン用決定ユニット４０５Ａと、マルチホーミング・サポートユニット４０６Ａと、シグナリング最適化ユニット４０７Ａにより構成される。ここで、図示されていないが、レイヤ３プロトコル・モジュール４０２Ａは、各ユニット４０３Ａ～４０７Ａ間のメッセージを伝達するためのインタフェースを有するものとする。また、各ユニット４０３Ａ～４０７Ａはまた、関連するバインディングを有するものとする。
　ＩＰｖ６ルーティング・ユニット４０３Ａは、近隣探索（neighbor discovery）、アドレス構成、及びＩＰｖ６の基本的なルーティングのメカニズムを担当する。ＭＩＰｖ６モビリティ管理ユニット４０４Ａは、ＢＵの実行及び登録解除のようなＭＩＰｖ６モビリティ管理のメカニズムを担当する。マルチホーミング・サポートユニット４０６Ａは、ＢＩＤの生成及びＢＵメッセージへのフラグＨの添付のようなＭＯＮＡＭＩ６（非特許文献４：複数ＣｏＡ登録）の機能を担当する。シグナリング最適化ユニット４０７Ａは、ＭＮ１０が本発明に係るＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を構成した場合の機能を担当する。ホームＰＭＩＰドメイン用決定ユニット４０５Ａは、ＭＮ１０がＰＭＩＰｖ６ドメインに接続（attach）しようとしているか否かを決定する場合の機能を担当する。ここで、当業者であれば、各ユニット４０３Ａ～４０７Ａが適切なソフトウエア・インタフェースを必要とすることは明らかである。
　最後に、上位層プロトコル・モジュール４０１Ａは、ＭＮ１０に備えられているトランスポート層やアプリケーション層のような上位の層のプロトコルを担当する。ここで、当業者であれば、上位層プロトコル・モジュール４０１Ａが１つのブロックで示されているが、本発明を逸脱しない範囲で複数のブロックで構成されることは明らかである。
　＜ＬＭＡ／ＨＡの構成＞
　次に図１０を参照してＬＭＡ／ＨＡ４０の構成について詳しく説明する。図１０はＬＭＡ／ＨＡ４０を機能的に示すブロック図である。ＬＭＡ／ＨＡ４０は概略的には、ルーティング層すなわちレイヤ３プロトコル・モジュール５０１Ａと、レイヤ３より下位の層のプロトコルを実行する下位層プロトコル・モジュール５１１Ａの２つの機能エンティティにより構成される。なお、図示されていないが、モジュール５０１Ａ、５０２Ａの間には適切なインタフェースが存在する。レイヤ３プロトコル・モジュール５０１Ａは４つのサブ・モジュールとして、ＩＰｖ６ルーティング・モジュール５０２Ａと、Ｍｏｎａｍｉ６ルーティング・モジュール５０３Ａと、ＰＭＩＰｖ６ルーティング・モジュール５０４Ａと、シグナリング最適化サポート・モジュール５０５Ａを有する。
　ＩＰｖ６ルーティング・モジュール５０２Ａは、１ホップ内の基本的なルーティングのメカニズムと、ＬＭＡ／ＨＡ４０の不図示のイングレス・インタフェース及びイーグレス・インタフェースのアドレス構成と、通常のパケットルーティング及び近隣探索のメカニズムを担当する。Ｍｏｎａｍｉ６ルーティング・モジュール５０３Ａは、マルチホーミング・シグナリングも処理可能なＨＡの機能を備えたマルチホーミング・モジュールである。ここで、モジュール５０３Ａは特に、フラグＨとＢＩＤを処理することができ、また、個々にＢＩＤを使用して１つのＨｏＡに対する複数のＣＭＩＰｖ６バインディング・エントリを維持できるものとする。ＩＰｖ６ルーティング・モジュール５０２ＡとＭｏｎａｍｉ６ルーティング・モジュール５０３Ａはシグナリング・インタフェース５１０Ａを有し、シグナリング・インタフェース５１０Ａは、ＣＭＩＰｖ６タイプのシグナリング及びデータパケットを処理してそのデータパケットをルーティングするために重要である。
　ＰＭＩＰｖ６ルーティング・モジュール５０４Ａは、純粋にＬＭＡタイプの機能のすべてを担当する。ＬＭＡタイプの機能として、例えば複数のインタフェースＩｆを有するＭＮ１０のＰＭＩＰｖ６キャッシュを維持したり、ＭＡＧ経由でＭＮ１０あてにパケットをトンネル化したり、受信したＰＢＵメッセージを処理したり、送信すべきＰＢＡメッセージを生成する。モジュール５０４Ａはさらに、ＩＰｖ６ルーティング・モジュール５０２Ａとのシグナリング・インタフェース５０９Ａを有し、シグナリング・インタフェース５０９Ａは、ＰＭＩＰｖ６キャッシュを用いてシグナリング及びデータパケットを処理してそのデータパケットをルーティングするために使用される。ここで、Ｍｏｎａｍｉ６ルーティング・モジュール５０３ＡとＰＭＩＰｖ６ルーティング・モジュール５０４Ａはそれぞれ、自身のＢＣＥを有するものとする。また、ＰＭＩＰｖ６ルーティング・モジュール５０４ＡとＭｏｎａｍｉ６ルーティング・モジュール５０３Ａは、非常に強く結合されているものとする。
　ここで、ＣＭＩＰｖ６キャッシュはＰＭＩＰｖ６キャッシュから別個に維持されるので、ＰＭＩＰｖ６ルーティング・モジュール５０４ＡとＭｏｎａｍｉ６ルーティング・モジュール５０３Ａは別個に示されているが、ＣＭＩＰｖ６キャッシュとＰＭＩＰｖ６キャッシュを分離するシグナリング・メッセージ内にＢＩＤとフラグＨがないときにＣＭＩＰｖ６キャッシュがＰＭＩＰｖ６キャッシュを上書きできる場合には、ＰＭＩＰｖ６ルーティング・モジュール５０４ＡとＭｏｎａｍｉ６ルーティング・モジュール５０３Ａ、及びＣＭＩＰｖ６キャッシュとＰＭＩＰｖ６キャッシュは相互に動作する必要がある。前述したように、ＣＭＩＰｖ６キャッシュとＰＭＩＰｖ６キャッシュは、別個に設けられているにもかかわらず、相互に密接して動作する必要がある。ここで、当業者であれば、ＣＭＩＰｖ６キャッシュとＰＭＩＰｖ６キャッシュを別個に設けるのは、実際に用いられる形態に依存する。代わりとして、ＰＭＩＰｖ６ルーティング・モジュール５０４ＡとＭｏｎａｍｉ６ルーティング・モジュール５０３Ａを図１０に示すように別個に設けるが、ＣＭＩＰｖ６キャッシュとＰＭＩＰｖ６キャッシュは一緒に設けてもよい。
　最後に、重要なシグナリング最適化サポート・モジュール５０５Ａについて説明する。シグナリング最適化サポート・モジュール５０５Ａは、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を処理してＣＭＩＰｖ６キャッシュをＭｏｎａｍｉ６ルーティング・モジュール５０３Ａに生成するために設けられている。モジュール５０５Ａは、モジュール５０３Ａとの間でシグナリング・インタフェース５０７Ａを介して通信するものとする。シグナリング・インタフェース５０７Ａは、ＣＭＩＰｖ６キャッシュ生成・維持管理要求などのメッセージや、ＣＭＩＰｖ６キャッシュを生成・維持管理するのに必要なパラメータを転送するために使用される。
　シグナリング最適化サポート・モジュール５０５Ａはまた、ＭＮ１０の他のインタフェースＩｆ２がＰＭＩＰｖ６ドメインに接続（attach）しているか否かをモニタする。このモニタに関して、シグナリング最適化サポート・モジュール５０５Ａは、ＰＭＩＰｖ６ルーティング・モジュール５０４Ａとの間にシグナリング・インタフェース５０６を必要とする。シグナリング最適化サポート・モジュール５０５Ａは、ＰＭＩＰｖ６ルーティング・モジュール５０４Ａからシグナリング・インタフェース５０６を経由して、ＭＮ１０の他のインタフェースＩｆ２がＰＭＩＰｖ６ドメインに接続（attach）していることを知得すると、ＭＮ１０がＣＭＩＰｖ６のＢＵメッセージを送信しないようＭＡＧに通知することを決定する。この通知情報は、シグナリング最適化サポート・モジュール５０５Ａで構成されてＰＭＩＰｖ６ルーティング・モジュール５０４Ａに転送される。以上、ＬＭＡ／ＨＡ４０の望ましい構成について説明したが、本発明を逸脱しない範囲でＬＭＡ／ＨＡ４０を構成することができる。
　＜第２の実施の形態＞
　次に、図１１を参照して第２の実施の形態について説明する。図１１に示すネットワークでは、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８の代わりに、ＣＭＩＰｖ６のＢＵメッセージ送信停止要求シグナル６１５が追加されていることを除いて同じである。以下、図１１に示した構成部材及びシグナルを簡単に繰り返して説明する。図１１に示すネットワークでは、複数のインタフェース（３ＧセルラインタフェースＩｆ１及びＷＬＡＮインタフェースＩｆ２）を有するＭＮ２００がインタフェースＩｆ１、Ｉｆ２の両方を介してホームＰＭＩＰｖ６ネットワーク（ドメイン）２０４に接続（connect）されている。このとき、３ＧセルラインタフェースＩｆ１は、ホームＰＭＩＰｖ６ネットワーク２０４のＭＡＧ２０１を介してＬＭＡ／ＨＡ２０３に接続（connect）され、また、ＷＬＡＮインタフェースＩｆ２は、ＷＬＡＮ２０６のＡＲ２０７と、ホームＰＭＩＰｖ６ネットワーク２０４のＭＡＧ２０２を介してＬＭＡ／ＨＡ２０３に接続（connect）されている。さらに、ＷＬＡＮ２０６はインタネット２０５に接続（connect）され、また、ＭＮ２００は、インタネット２０５に接続（connect）されているＣＮ２１４との間で通信している。
　上記構成において、ＭＮ２００が最初に３ＧセルラインタフェースＩｆ１を介してＭＡＧ２０１に接続（attach）すると、ＭＡＧ２０１がＰＢＵメッセージ（シグナリング２０８）をＬＭＡ／ＨＡ２０３に送信して、ＬＭＡ／ＨＡ２０３のＢＣ２１３に第１のエントリＥ１（ＰＭＩＰｖ６キャッシュ）が生成され、また、ＭＮ１０がＭＩＰｖ６のホームプリフィックスＰ１を参照する。同様に、ＭＮ２００がＭＡＧ２０２に対するトンネル確立をトリガすると、ＭＡＧ２０２がＰＢＵメッセージ（シグナリング２０９）をＬＭＡ／ＨＡ２０３に送信して、ＬＭＡ／ＨＡ２０３のＢＣ２１３に第２のエントリＥ２（ＰＭＩＰｖ６キャッシュ）が生成される。この結果、ＭＮ２０はＬＭＡ／ＨＡ２０３により与えられる外部プリフィックスＰ２をＩＰＳｅｃ完了メッセージ２１１で参照する。
　ここで、ＭＮ２００はＣＮ２１４から、ホームプリフィックスＰ１から構成されたＨｏＡあてのフローがＷＬＡＮインタフェースＩｆ２経由で来ることを希望するものとする。また、前述したように、ＭＮ１０はインタフェースＩｆ１、Ｉｆ２に対して１つのホームプリフィックスＰ１と１つのＨｏＡのみを有するものとする。ＭＮ１０はＣＮ２１４から１つのＨｏＡあてのフローがＷＬＡＮインタフェースＩｆ２経由で来ることを希望する場合、ホームとアウェイで接続（attach）することを示すフラグＨ付きのＣＭＩＰｖ６のＢＵメッセージ２１２をＬＭＡ／ＨＡ２０３に送信して、ＬＭＡ／ＨＡ２０３のＢＣＥ２１３に第３のエントリＥ３（ＣＭＩＰｖ６キャッシュ）を生成する。ここで重要なことは、フラグＨ付きのＣＭＩＰｖ６のＢＵメッセージ２１２は、第１のエントリＥ１であるＰＭＩＰｖ６キャッシュを上書きしない点である。したがって、３つのエントリＥ１、Ｅ２、Ｅ３がすべて共存し、ＬＭＡ／ＨＡ２０３が異種のバインディング（ＰＭＩＰｖ６キャッシュとＣＭＩＰｖ６キャッシュ）を維持することができる。
　第２の実施の形態におけるＬＭＡ／ＨＡ２０３は、ＣＭＩＰｖ６のＢＵメッセージ２１２をチェックして、ＣＭＩＰｖ６登録（第３のエントリＥ３）を使用するのに第２のエントリＥ２（ＰＭＩＰｖ６キャッシュ）を必要とすることを検出する機能を有する。さらに、ＬＭＡ／ＨＡ２０３は、ＣＭＩＰｖ６のＢＵメッセージ２１２が継続する必要がないこと、及びＬＭＡ／ＨＡ２０３が第２のエントリＥ２（ＰＭＩＰｖ６キャッシュ）を用いてＣＭＩＰｖ６バインディングを生成及び維持管理できることものと推論する。ＬＭＡ／ＨＡ２０３は、いったんこのように決定すると、その旨をＣＭＩＰｖ６のＢＵメッセージ送信停止要求シグナル６１５でＭＮ２００に直接に通知する。ＭＮ２００はシグナル６１５を受信すると、ＣＭＩＰｖ６のＢＵメッセージ２１２をこれ以上送信しない。ただし、ＭＮ２００が外部プリフィックスＰ２でない新しいプリフィックスをドメイン２０４内で参照した場合と、ＬＭＡ／ＨＡ２０３がこの最適化サービスを取り消す旨をＭＮ２００に通知した場合を除く。
　ＷＬＡＮ２０６のセルがタイル状に連続している場合と連続していない場合の両方において、ホームのＬＭＡ／ＨＡ２０３から来る外部プリフィックスＰ２に対してＭＮ２００がＣＭＩＰｖ６のＢＵメッセージ２１２を継続して送信する場合の問題を解決する種々の変形例が考えられるが、これらは問題を最も効率的に解決する方法ではない。以下に、不具合な点を考察する。第１に、ホームのＬＭＡ／ＨＡ２０３がこの最適化のサービス又は可能性に関する決定を行う場合にある程度の複雑さがある。第２に、ホームのＬＭＡ／ＨＡ２０３が、ホームのＬＭＡ／ＨＡ２０３に属しない外部プリフィックスＰ２から構成されたＣｏＡを無駄にサーチする（ＣｏＡのバインディングがＰＭＩＰｖ６バインディングを有するか否かをサーチする）。ＬＭＡ／ＨＡ２０３がＭＮ２００から、第１の実施の形態のようなＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８を受信しないので、ＬＭＡ／ＨＡ２０３はＭＮ２００のＷＬＡＮインタフェースＩｆ２がどこに接続（attach）しているかを知得していないので、上記のＣｏＡのサーチが無駄な努力となる。
　第３に、ＬＭＡ／ＨＡ２０３は、可能な最適化を識別するためにＭＮ２００のＷＬＡＮインタフェースＩｆ２からのＢＵメッセージを必要とする。ここで、第１の実施の形態では、ＭＮ２００のＷＬＡＮインタフェースＩｆ２からのＣＭＩＰｖ６のＢＵメッセージ２１２は不要であり、ＣＭＩＰｖ６キャッシュ生成・維持管理要求メッセージ３０８で十分である。ただし、第２の実施の形態の利点は、ＭＮ２００がホームＰＭＩＰｖ６ドメイン２０４に接続（connect）しているかを予測する必要がないが、ＭＮ２００がＷＬＡＮインタフェースＩｆ２のインタフェース識別子とＢＩＤをＬＭＡ／ＨＡ２０３に送信する必要があることにある。第２の実施の形態では、シグナリング負荷を減少させるために必要なすべての処理をＬＭＡ／ＨＡ２０３が実行する。多くのＬＭＡ／ＨＡが存在する場合、これらのＬＭＡ／ＨＡ２０３に多くの処理負荷を負わせても実現可能である。
　＜第３の実施の形態＞
　次に、前述した図１１を参照して第３の実施の形態について説明する。ここで、図１１において、ＭＮ２００がＷＬＡＮインタフェースＩｆ２を経由してホームＰＭＩＰｖ６ドメイン２０４に接続（connect）していることを知得しているものとする。その情報は、ＭＮ２００がＷＬＡＮ２０６のビーコンを参照して、ＭＡＧ２０２がＬＭＡ／ＨＡ２０３とのトンネルを確立していることをＭＡＧ２０２から取得することができる。ＭＮ２００は上記の情報から、ＣＭＩＰｖ６のＢＵのシグナリング最適化を実行できるものと知得し、ＣＭＩＰｖ６のＢＵメッセージ２１２をＬＭＡ／ＨＡ２０３に送信する。ここで、このＢＵメッセージ２１２は、ＬＭＡ／ＨＡ２０３に接続（attach）した各インタフェースＩｆ１、Ｉｆ２のＢＩＤを含み、また、それらに非常に長い存続期間を記述する。第３の実施の形態のポイントは、ＭＮ２００が非常に長い存続期間、接続（attach）した場合、ＭＮ２００がＢＵをリフレッシュする必要がないことである。
　この場合、ＭＮ２００は、ＢＵメッセージ２１２内に記述した存続期間より長くホームＰＭＩＰｖ６ドメイン２０４内をローミングした場合には、第３のエントリＥ３をリフレッシュする必要がある。また、ＬＭＡ／ＨＡ２０３が非常に長い存続期間をアクセプトしない（長い存続期間のモビリティ・サービスを保証できない）場合には、ＬＭＡ／ＨＡ２０３が受け入れる存続期間の最大の値をＭＮ２００が知得し、ＢＵメッセージ２１２で通知してもよい。また、ＬＭＡ／ＨＡ２０３は自身の負荷の状態に応じて、ＭＮ２００からのＢＵをアクセプトしたり、リジェクトしたりするかもしれない。したがって、非常に長い存続期間のバインディングや、静的又はハードコードのバインディングは、ＬＭＡ／ＨＡ２０３がアクセプトできないかもしれない。この場合、ＬＭＡ／ＨＡ２０３からＭＮ２００に対して、長い存続期間のバインディングをアクセプトできるか否かを通知し、それに応じてＭＮ２００が長い存続期間を含むＢＵメッセージ２１２を送るべきか否かを判断してもよい。
　また、ＷＬＡＮ２０６が図２に示したＷＬＡＮ３０、３１のように連続していない場合、もし、ＷＬＡＮインタフェースＩｆ２がオン、オフしたときに新しい外部プリフィックスＰ２がＷＬＡＮインタフェースＩｆ２に与えられると、外部プリフィックスＰ２に対して長い存続期間のＢＵメッセージ２１２を送信しないと判断してもよい。これにより、比較的短期間利用する外部プリフィックスに対しては通常のバインディングキャッシュとして扱わせることができる。また、ＭＮ２００は複数のインタフェースＩｆ１、Ｉｆ２を有するので、各インタフェースＩｆ１、Ｉｆ２に対して長い存続期間のＢＵメッセージ２１２を送信する。第３の実施の形態の主な利点は、ＭＮ２００の構成の変更が最小であることにある。拡張ＭＩＰｖ６タスク（Ｍｏｎａｍｉ６の機能）を備えたＭＮ２００は、ソフトウエアを変更することなくシグナリング・ストームの問題を解決できる。
　＜第４の実施の形態＞
　さらに、同じ図１１を参照して第４の実施の形態について説明する。第４の実施の形態では、ＬＭＡ／ＨＡ２０３は、ＣＭＩＰｖ６のＢＵメッセージ２１２をＭＮ２００から受信した場合に第２の実施の形態のシグナリング最適化を実行できるものと推論すると、ＢＵメッセージ２１２の応答として、ＣＭＩＰｖ６のＢＵメッセージ送信停止要求シグナル６１５の代わりに、非常に長い存続期間を記述したバインディング確認（ＢＡ）メッセージ（不図示）をＭＮ２００に送り返す。ＭＮ２００は、このＢＡメッセージ内の存続期間が満了するまで新しいＢＵメッセージ２１２をＬＭＡ／ＨＡ２０３に送信しない。
　ただし、第４の実施の形態においても、ＭＮ２００は、ＢＡメッセージ内の存続期間が満了するとＣＭＩＰｖ６キャッシュをリフレッシュする必要がある。第４の実施の形態の主要な利点は、より多くの処理負荷をＭＮ側ではなくネットワーク側にシフトできることにある。さらに、第２の実施の形態と比べて、ＬＭＡ／ＨＡ２０３の動作を簡略化できる。
　＜第５の実施の形態＞
　次に図１２を参照して第５の実施の形態について説明する。図１２において、ＭＮ２００、ＭＡＧ２０１、２０２、ＬＭＡ／ＨＡ２０３、ホームＰＭＩＰｖ６ドメイン２０４、インタネット２０５、ＷＬＡＮ２０６及びＣＮ２１４は図１１と同じであるが、図１１で示したＣＭＩＰｖ６のＢＵメッセージ２１２とＢＣ７１３内の第３のエントリＥ３がない。
　上記構成において、まず、図１１と同様に、ＭＮ２００が最初に３ＧセルラインタフェースＩｆ１を介してＭＡＧ２０１に接続（attach）すると、ＭＡＧ２０１がＰＢＵメッセージ（シグナリング２０８）をＬＭＡ／ＨＡ２０３に送信して、ＬＭＡ／ＨＡ２０３のＢＣＥ７１３に第１のエントリＥ１（ＰＭＩＰｖ６キャッシュ）が生成され、また、ＭＮ１０がＭＩＰｖ６のホームプリフィックスＰ１を参照する。同様に、ＭＮ２００がＭＡＧ２０２に対するトンネル確立をトリガすると、ＭＡＧ２０２がＰＢＵメッセージ７０９をＬＭＡ／ＨＡ２０３に送信して、ＬＭＡ／ＨＡ２０３のＢＣＥ７１３に第２のエントリＥ２（ＰＭＩＰｖ６キャッシュ）が生成される。
　第５の実施の形態では、ＬＭＡ／ＨＡ２０３がＢＣＥ７１３に第２のエントリＥ１（ＰＭＩＰｖ６キャッシュ）を生成するとき、両方のＰＭＩＰｖ６キャッシュが同じＭＮ２００に属することを、ＮＡＩを使用して推論できる。したがって、ＬＭＡ／ＨＡ２０３は、ＰＢＵメッセージ２０９の応答であるＰＢＡメッセージ７１１でＭＡＧ２０２に指示して、ＭＮ２００が外部プリフィックスＰ２を参照したときに、図１１で示したＣＭＩＰｖ６のＢＵメッセージ２１２を送信しないよう、ＭＡＧ２０２がＲＡ／ＩＫＥｖ２完了メッセージ７１２でＭＮ２００に通知する。さらに、ＬＭＡ／ＨＡ２０３は、ＰＢＡメッセージ７１１でＭＡＧ２０２に指示して、ＭＮ２００がホームプリフィックスＰ１に対するフローを複数のインタフェースＩｆ１、Ｉｆ２にロードバランスするようにＭＡＧ２０２に通知させる。
　第５の実施の形態の動作について詳しく考察する。ＬＭＡ／ＨＡ２０３の構成は、ＬＭＡ／ＨＡ２０３が同じＭＮ２００に属するＢＣＥ７１３の第１、第２のエントリＥ１、Ｅ２を識別し、更にホームプリフィックスＰ１あてのパケットを外部プリフィックスＰ２のＰＭＩＰｖ６キャッシュ（第２のエントリＥ２）を経由してルーティング可能であることを識別するように変更されている。そして、ＬＭＡ／ＨＡ２０３はＭＡＧ２０２に対し、外部プリフィックスＰ２用に送信されるＰＢＡメッセージ７１１でホームプリフィックスＰ１を通知し、ＭＡＧ２０２がＲＡメッセージ７１２で特別なオプションを送信する。この特別なオプションは、ＭＮ２００が外部プリフィックスＰ２を参照したときに、図１１で示したＣＭＩＰｖ６のＢＵメッセージ２１２を送信しないようにＭＮ２００に通知するフラグである。ここで重要な点は、ＭＡＧ２０２がＰＢＡメッセージ７１１でホームプリフィックスＰ１を通知されているので、ホームプリフィックスＰ１用のパケットがＭＡＧ２０２にルーティングされたときに、ＭＡＧ２０２はそのパケットを、外部プリフィックスＰ２から構成したアドレスのＷＬＡＮインタフェースＩｆ２に転送できることにある。
　次に、第１の実施の形態と比較して第５の実施の形態の不具合について考察する。第１に、ホームＰＭＩＰｖ６ドメイン２０４内のＭＡＧ２０１、２０２の構成が変更されている。第２に、ＭＮ２００は、ホームプリフィックスＰ１用のパケット（例えばＱｏＳが高いＶｏＩＰの場合）が、安定している３ＧセルラインタフェースＩｆ１のみに来るよう希望するかもしれない。すなわち、インタフェースＩｆ１、Ｉｆ２の両方に来ることを希望しないかもしれない。ＭＮ２００がこのような希望を有する場合、ＬＭＡ／ＨＡ２０３がホームプリフィックスＰ１をＭＡＧ２０２に通知することは無駄となる。
　第３に、ＭＮ２００がホームＰＭＩＰｖ６ドメイン２０４内で２つのＨｏＡ（ホームプリフィックスＰ１から構成したＨｏＡ１と外部プリフィックスＰ２から構成したＨｏＡ２）を有する場合、ＭＮ２００がこのシグナリング最適化サービスを希望しないかもしれない。なお、ＳＨＩＭ６（Site Multi-homing by IPv6 Intermediation）をＭＮ２００とＣＮ２１４に備えてもよい。この場合にはマルチホーミングは既に実現できるので、ＬＭＡ／ＨＡ２０３の動作は無駄となる。ここで、当業者であれば、ＬＭＡ／ＨＡ２０３が理想的には、ＭＮ２００から何かのトリガを取得した後にのみ、このシグナリング最適化をすべきであることは明らかである。その理由は、ＭＮ２００のステート（備えられているプロトコル）と、希望する内容は通常、ＭＮ２００のみが知得しているからである。第５の実施の形態の不具合について説明したが、第５の実施の形態の利点は、ＭＮ２００がマルチホーミングを実現するためにホームＰＭＩＰｖ６ドメイン２０４内では如何なるシグナリングも実行する必要がないことにある。第５の実施の形態によれば、ＭＮ２００はホームプリフィックスＰ１あてのパケットをすべてのインタフェースＩｆ１、Ｉｆ２で受信できる。
　＜第６の実施の形態＞
　同じ図１２を参照して第６の実施の形態について説明する。第６の実施の形態では、ＭＮ２００がホームプリフィックスＰ１のパケットがインタフェースＩｆ１、Ｉｆ２の両方（又はＩｆ２）に届くことを希望するものとする。ただし、ＭＮ２００はインタフェースＩｆ１、Ｉｆ２に対して１つのホームプリフィックスＰ１と１つのＨｏＡを有するものとする。ＭＮ２００はホームプリフィックスＰ１をＬＭＡ／ＨＡ２０３に通知し、また、ＬＭＡ／ＨＡ２０３に対して、ホームプリフィックスＰ１についての外部プリフィックスＰ２に関連するＭＡＧ２０２を通知するよう要求する。基本的に、そのＭＮ２００からの通知シグナリングは１回のみ必要である。
　以下に詳しく説明する。ＭＮ２００がホームプリフィックスＰ１をＬＭＡ／ＨＡ２０３に通知し、また、ＬＭＡ／ＨＡ２０３に対してＭＮの他のインタフェースＩｆ２に接続（connect）しているＭＡＧ２０２に対して、ホームプリフィックスＰ１について通知するよう要求する。この通知メッセージは、新しい種類の明示的なモビリティ・シグナリングメッセージである。ＬＭＡ／ＨＡ２０３はこの通知メッセージを受信すると、ホームプリフィックスＰ１が有効なプリフィックスであることをＭＡＧ２０２に通知する。ＬＭＡ／ＨＡ２０３は、ＭＮ２００のインタフェースＩｆ２がＭＡＧ２０２に接続（attach）したときにプリフィックスＰ１、Ｐ２をＭＡＧ２０２に通知することができる。ここで重要な点は、ＭＡＧ２０２がホームプリフィックスＰ１についての情報をいったん取得すると、ＭＡＧ２０２がこの情報を、ＭＮ２００のインタフェースＩｆ２が接続（attach）した他のＭＡＧにＣＴ（context transfer）で転送できることにある。このＣＴの動作は、古いＭＡＧから新しいＭＡＧの間でＣＴインタフェースが利用可能な場合にのみ可能である。
　第６の実施の形態では、ＬＭＡ／ＨＡ２０３においてホームプリフィックスＰ１のＨｏＡあてに到着したパケットは、ＭＡＧ２０２経由でトンネル化される。また、ＭＮ２００のインタフェースＩｆ２が移動したときにはいつでも、ＬＭＡ／ＨＡ２０３が上記のホームプリフィックスＰ１についての通知メッセージを送信する。さらに、秘密性の高いデータフローにとって、ＭＡＧ２０２経由のトンネル化は望ましくないが、ＭＮ２００経由のトンネル化が可能である。第６の実施の形態の主要な利点は、ＭＮ２００が、他のインタフェースＩｆ２がホームＰＭＩＰｖドメイン２０４に接続（attach）したことを予測する必要がなく、また、第１の実施の形態のようにインタフェースＩｆ２のインタフェース識別子を送信する必要がないことにある。第１の実施の形態と比較して、第６の実施の形態では、ＭＮ２００から来るシグナリングの負荷をやや減少できる。
　＜第７の実施の形態＞
　同じ図１２を参照して第７の実施の形態について説明する。第７の実施の形態では、ＭＮ２００がホームプリフィックスＰ１のパケットがインタフェースＩｆ１、Ｉｆ２の両方（又はＩｆ２）に届くことを希望するものとし、このため、ＭＮ２００がホームプリフィックスＰ１をＭＡＧ２０２に通知する。ＭＡＧ２０２はＬＭＡ／ＨＡ２０３からホームプリフィックスＰ１の証明（verification）を取得する。
　以下に詳しく説明する。ここで、ＭＮ２００は既に、インタフェースＩｆ１がＭＡＧ２０１に接続（attach）しており、また、ホームプリフィックスＰ１をＲＡメッセージ２１０で参照しているものとする。次に、ＭＮ２００は、ＷＬＡＮインタフェースＩｆ２とＭＡＧ２０２との初期接続（initial attachment）の間のトンネル・セットアップメッセージでホームプリフィックスＰ１についてＭＡＧ２０２に通知する。ＭＡＧ２０２はホームプリフィックスＰ１の情報を取得すると、その情報をＰＢＵメッセージ７０９でＬＭＡ／ＨＡ２０３に送信する。ＬＭＡ／ＨＡ２０３はＰＢＵメッセージ７０９をＭＡＧ２０２から受信すると、ＭＡＧ２０２に対して外部プリフィックスＰ２とホームプリフィックスＰ１が有効なプリフィックスであることを通知する。
　基本的に、ＭＮ２００は、ＷＬＡＮインタフェースＩｆ２経由でホームＰＭＩＰｖドメイン２０４内の各ＭＡＧに接続（attach）すると、ホームプリフィックスＰ１の証明（verification）のために上記のトンネル・セットアップメッセージを各ＭＡＧに送信する必要がある。なお、代わりに、ＭＡＧ２０２がいったん、ＬＭＡ／ＨＡ２０３からホームプリフィックスＰ１の確認を取得すると、この情報は他のＭＡＧにＣＴで転送することができる。基本的に、各ＭＡＧはＣＴでホームプリフィックスＰ１と外部プリフィックスＰ２を転送することができ、ＭＮ２００のＷＬＡＮインタフェースＩｆ２に接続（attach）したすべてのＭＡＧは、有効なホームプリフィックスＰ１と外部プリフィックスＰ２を有する。このため、ホームプリフィックスＰ１のフローあてのデータパケットは、ＷＬＡＮインタフェースＩｆ２に接続（attach）した各ＭＡＧにトンネル化できる。
　第７の実施の形態では、ホームプリフィックスＰ１のパケットをインタフェースＩｆ１、Ｉｆ２の両方で取得するために、シグナリングがコアネットワーク内で発生する。例えばホームプリフィックスＰ１の有効性をＬＭＡ／ＨＡ２０３に問い合わせるシグナリングと、ＷＬＡＮインタフェースＩｆ２がホームＰＭＩＰｖドメイン２０４接続（attach）したときに必ずＭＮ２００がホームプリフィックスＰ１を転送するシグナリングは、追加されたシグナリングである。第７の実施の形態の主要な利点は、ＭＮ２００がホームプリフィックスＰ１をＭＡＧに通知することのみを必要とすることにある。この通知はＬ２シグナルで可能である。したがって、シグナリング最適化を実現するために、ＭＮ２００から発生するシグナリング負荷を第１の実施の形態より少なくすることができる。
　＜第８の実施の形態＞
　次に図１３を参照して第８の実施の形態について説明する。第８の実施の形態では、ＭＮ２００が外部ＰＭＩＰｖ６ドメイン８１０をローミングしているときのＨｏＡあてのパケットロスを防止する方法について説明する。ここでの想定では基本的に、ＬＭＡ／ＨＡ２０３は、ホームプリフィックスＰ１のフローを、外部プリフィックスＰ２が与えられたＭＡＧ経由で送信できるものとする。また、基本的に、ＭＮ２００のインタフェースＩｆ２に接続（connect）したＭＡＧは、ＭＮ２００のホームプリフィックスＰ１に関してある機能を有するものとする。この機能は、ＬＭＡ／ＨＡ２０３によりそのＭＡＧに直接に提供してもよく、又は、最初にあるＭＡＧに与えられて他のＭＡＧにはＣＴで転送してもよい。
　図１３において、複数のインタフェースＩｆ１、Ｉｆ２を有するＭＮ２００は、最初にインタフェースＩｆ１、Ｉｆ２の両方を介してホームＰＭＩＰｖドメイン２０２に接続（connect）するものとする。ここで、ＭＮ２００は、最初にインタフェースＩｆ１経由でＭＡＧ２０１に接続（connect）し、次いでインタフェースＩｆ２経由でＭＡＧ２０２に接続（connect）するものとする。さらに、ＭＮ２００が最初に接続（connect）するＷＬＡＮ２０６がインタネット２０５に接続（connect）されているものとする。さらに、ホームＰＭＩＰｖドメイン２０２が同様にインタネット２０５に接続（connect）されているものとする。
　ＭＮ２００が最初にインタフェースＩｆ１経由でＭＡＧ２０１に接続（attach）すると、ＭＡＧ２０１がＰＢＵメッセージ（不図示）をＬＭＡ／ＨＡ２０３に送信してＬＭＡ／ＨＡ２０３のＢＣ８１３に第１のエントリＥ１（ＰＭＩＰｖ６キャッシュ）が生成され、また、ＭＮ２００がＲＡメッセージ（不図示）からホームプリフィックスＰ１を参照する。次いでＭＮ２００がインタフェースＩｆ２経由でＭＡＧ２０２に対するトンネル確立をトリガすると、ＭＡＧ２０２はＰＢＵメッセージ（不図示）をＬＭＡ／ＨＡ２０３に送信してＬＭＡ／ＨＡ２０３のＢＣ８１３に第２のエントリＥ２（ＰＭＩＰｖ６キャッシュ）が生成される。
　ここで、ＬＭＡ／ＨＡ２０３は第１、第２のエントリＥ１、Ｅ２を用いて、ホームプリフィックスＰ１から構成されたＨｏＡあてに来るパケットをＭＡＧ２０２あてにトンネル化でき、また、ＭＡＧ２０２はホームプリフィックスＰ１を通知されるものとする。また、ＭＮ２００は、ＭＡＧ２０１に未だ接続（attach）しているときに、ＷＬＡＮインタフェースＩｆ２がＭＡＧ２０２から切断（disconnect）して、別の外部ＰＭＩＰｖ６ドメイン８１０のＭＡＧ８０３に接続（attach）するものとする。このとき、基本的に、ＭＮ２００はＷＬＡＮインタフェースＩｆ２経由で、外部ＰＭＩＰｖ６ドメイン８１０のＬＭＡ／ＨＡ８０８から外部プリフィックスすなわちローカル・ブレークアウト・プリフィックスを参照する。そこで、ＭＮ２００はＣＭＩＰｖ６のＢＵメッセージ８１２を外部ＰＭＩＰｖ６ドメイン８１０経由でホームＬＭＡ／ＨＡ２０３に送信してＬＭＡ／ＨＡ２０３のＢＣ８１３に第３のエントリＥ３（ＣＭＩＰｖ６キャッシュ）が生成される。
　ここで、重要な点は、ＭＮ２００がＣＭＩＰｖ６のＢＵメッセージ８１２をフラグＨ付きで送信して、ＬＭＡ／ＨＡ２０３に対してＨｏＡあてのパケットをＷＬＡＮインタフェースＩｆ２経由の送信を希望することにある。非常に可能性が低いケースとして、ＷＬＡＮインタフェースＩｆ２が外部ＰＭＩＰｖ６ドメイン８１０のＬＭＡ／ＨＡ８０８に接続（attach）してＬＭＡ／ＨＡ２０３のＢＣ８１３に第３のエントリＥ３（ＣＭＩＰｖ６キャッシュ）が生成された後に、ＭＡＧ２０２による第２のエントリＥ２の登録が解除されずに残っている場合があり、この場合にはパケットロスが発生する。その理由は、ＬＭＡ／ＨＡ２０３は第２のエントリＥ２を使用してパケットをルーティングしてもよいからである。したがって、ＭＮ２００がＣＭＩＰｖ６のＢＵメッセージ８１２を送信するときに、ＭＮ２００が新しいオプションをＢＵメッセージ８１２に添付して第２のエントリＥ２はもう有効でないことを通知することが望ましい。この目的のため、ＢＵメッセージ８１２内のオプション内に外部プリフィックスＰ２を送信することができる。
　なお、ＭＮ２０２がＷｉＭＡＸアクセスネットワークに接続（attach）した場合、ＭＡＧ機能は、ワイヤレス・アクセスネットワークに位置するアクセスゲートウェイ（ＡＧＷ）に共存している。さらに、信頼できないＷＬＡＮアクセスネットワークにＭＮが接続（attach）した場合、ＭＡＧ機能はそのｅＰＤＧに共存している。さらにＭＮがＥ－ＵＴＲＡＮ、ＵＴＲＡＮ、ＧＥＲＡＮのような３Ｇアクセス経由で接続（attach）した場合、ＭＡＧ機能はそのＳ－ＧＷ（Serving GateWay）に共存している。さらに、３ＧＰＰアーキテクチャでは、ＬＭＡ／ＨＡ機能はＰ－ＧＷ（Packet data network GateWay）に共存している。
　＜第９の実施の形態＞
　第９の実施の形態では、図１５に示す二重登録（ＢＵ１、ＢＵ２）の問題を解決するために、ＭＮがＬＭＡ／ＨＡに対し、ＰＭＩＰｖ６ベアラがセットアップされるときにホームアンドアウェイ・バインディングを生成するよう要求する。図１６～図２３を参照して第９の実施の形態について詳しく説明する。図１６に示す想定では、ＭＮ１００３は最初に、ＷｉＭＡＸインタフェースＩｆ２（及びＷｉＭＡＸアクセスネットワーク１００１、ＭＡＧ１００６）経由で、ホームドメインであるＥＰＣ（evolved packet core）１０００に接続（attach）し、次いでＬＴＥ（long-term evolution）インタフェースＩｆ１すなわち３ＧインタフェースＩｆ１（及びＵＴＲＡＮ、ＬＴＥ、Ｅ－ＵＴＲＡＮなどのアクセスネットワーク１００２、ＭＡＧ１００５）経由でＥＰＣ１０００に接続（attach）するものとする。
　ＭＮ１００３は、最初にＷｉＭＡＸインタフェースＩｆ２がＷｉＭＡＸアクセスネットワーク１００１に接続（attach）すると、ＭＡＧ１００６による認証が成功した後、ＭＡＧ１００６が管理するプリフィックスＰ２をシグナリング・メッセージ１００７経由で参照する。図１５と同様に、ＷｉＭＡＸインタフェースＩｆ２のモビリティは、ＭＩＰｖ６メカニズムにより管理される。また、ＭＮ１００３は、ＷｉＭＡＸインタフェースＩｆ２経由で接続（attach）する処理を開始するときに、ＬＴＥ／３ＧインタフェースＩｆ１で接続（attach）する処理を開始する。ＭＮ１００３は、最初にプリフィックスＰ２をＷｉＭＡＸインタフェースＩｆ２経由で参照すると、内部的にこれからＬＴＥ／３ＧインタフェースＩｆ１経由で参照するであろうプリフィックス・タイプを予測して決定する。なお、ＬＴＥ／３ＧインタフェースＩｆ１経由で参照するプリフィックスＰ１のモビリティは、ＰＭＩＰｖ６メカニズムにより管理されるものとする。
　ＭＮ１００３は、多くのファクタに基づいて、Ｅ－ＵＴＲＡＮアクセスネットワーク１００２に接続（connect）されるＬＴＥ／３ＧインタフェースＩｆ１経由で参照するＭＩＰｖ６ホームプリフィックスＰ１を予測することができる。第１のファクタとしては、非特許文献６に示すようにＭＩＰｖ６－ＢＵがＬＴＥ／３ＧインタフェースＩｆ１経由で実行できない、つまりネットワークベースのローカル・モビリティ管理プロトコルが使われるので、ＭＮ１００３は、ＷｉＭＡＸインタフェースＩｆ２の電源をオフにした場合でもセッションが継続できるように、ＬＭＡ／ＨＡ１００４が常にホームプリフィックスＰ１を継続して付与するであろうと予測してもよい。
　上記の予測に貢献する第２のファクタとしては、ＭＮ１００３が１つのＡＰＮ（Access Point Name）によって示される１つのサービスタイプのみに加入していて、かつＷｉＭＡＸバインディングがＬＭＡ／ＨＡ１００４にセットアップされる場合、ＭＮ１００３は、ＬＭＡ／ＨＡ１００４はＵＥ１００３に対してマルチホーミングを実現するために、ＭＩＰｖ６ホームプリフィックスＰ１を３Ｇ／ＬＴＥインタフェースＩｆ１経由で付与すると予測する。ＡＰＮは、３ＧＰＰではあるサービスタイプを特徴付ける。ＡＰＮの詳しい説明は、非特許文献６に記載されている。ＭＮ１００３が１つのＰＤＮのみに加入している場合は、１つのＡＰＮのみを保持しているため、ＬＴＥインタフェースＩｆ１経由で接続（connect）したときにＬＭＡ／ＨＡ１００４が同じＭＩＰｖ６プリフィックスを割り当てるかもしれないと予測することは合理的である。
　ＭＮ１００３が複数のＰＤＮに加入している場合は、複数のＡＰＮを保持しているため、ＬＭＡ／ＨＡ１００４は、別のＰＤＮにアクセスするために別のプリフィックスをＬＴＥインタフェースＩｆ１経由で割り当てるかもしれない。基本的に、複数のＡＰＮの想定では、同時接続（connection）中は、Ｐ－ＧＷは、異なるインタフェースに対して異なるＰＤＮからのプリフィックスを割り当てるかもしれない。すなわち、マルチホーミングを実現するためにＰＤＮ１からのプリフィックスをＷｉＭＡＸインタフェースＩｆ２経由で、ＰＤＮ２からのプリフィックスを３ＧインタフェースＩｆ１経由で割り当てる。
　上記の予測に貢献する第３のファクタとしては、ＭＮ１００３がリアルタイムに関するフローをＷｉＭＡＸインタフェースＩｆ２経由で使用していて、次に３ＧインタフェースＩｆ１経由に切り換える場合、ネットワークポリシーとして、３ＧインタフェースＩｆ１の方がリアルタイムフローには理想的であるため、ＷｉＭＡＸインタフェースＩｆ２からのフローを３ＧインタフェースＩｆ１側に通過させたいという場合がある。ネットワークは、このフローを３ＧインタフェースＩｆ１側に通過させたい場合、ＭＩＰｖ６プリフィックスをＰＭＩＰｖ６プリフィックスとして３ＧインタフェースＩｆ１経由で送信する必要がある。ＭＮ１００３は、上記のネットワークポリシーを知得している場合、ＭＩＰｖ６ホームプリフィックスＰ１を３ＧインタフェースＩｆ１経由で参照するであろうと簡単に予測できる。
　上記の予測に貢献する第４のファクタは、ＭＮ１００３において静的に構成されたポリシーである。ＭＮ１００３は、例えば「ＬＴＥリンクをＭＩＰｖ６ホームリンクとしたい」というポリシーをＨＳＳ（Home Subscription Server）においてあらかじめ構成してもよい。ＭＮ１００３は、「リアルタイムなフローを同時使用したい」という理由などによりこの静的なポリシーを構成していて、リアルタイムなサービスを提供するＰＤＮにＭＮ１００３が加入している場合にこのポリシーをＨＳＳに構成する。リアルタイムなサービスを提供するＰＤＮとは、ＩＭＳ（IP Multimedia Service）タイプである。別の理由として、ＬＴＥアクセスがリアルタイムなサービスに対してより良いＱｏＳを提供し、リアルタイムなフローが３ＧインタフェースＩｆ１に来ることをＭＮ１００３が望む場合がある。
　上記の説明から、「ＭＩＰｖ６ホームプリフィックスＰ１を３ＧインタフェースＩｆ１経由で参照するであろう」ということを予測する決定基準をＭＮ１００３が使用できることがわかる。ＭＮ１００３は、この決定プロセスを完了すると、ＢＵメッセージ１００８をＬＭＡ／ＨＡ１００４に送信する。ＢＵメッセージ１００８には、例えばＭＩＰＶ６ホームプリフィックスＰ１用のＰＭＩＰｖ６ベアラがセットアップされるときにホームアンドアウェイのバインディングを生成するようＬＭＡ／ＨＡ１００４に要求する新しい情報を埋め込むことができる。以下、ＢＵメッセージ１００８に埋め込まれる情報を「ホームバインディング生成要求」又は「Ｈフラグ生成要求」と称す。ここで、当業者であれば、ＭＮ１００３は、ＭＩＰｖ６ホームプリフィックスＰ１をＬＴＥアクセス経由で参照するであろうということを予測できるので、ホームアンドアウェイのバインディングを生成するためにＬＭＡ／ＨＡ１００４に送信するＢＵメッセージとして、図１５に示す複数のＢＵメッセージ（ＢＵ１、ＢＵ２）ではなく、ホームバインディング生成要求を含む１つのＢＵメッセージ１００８のみを送信すればよいことは明らかである。
　ＬＭＡ／ＨＡ１００４は、ＢＵメッセージ１００８内の上記の「ホームバインディング生成要求」を処理して、応答メッセージ又はＢＡメッセージ１０１０をＭＮ１００３に送信する。ＢＡメッセージ１０１０はＭＮ１００３に対し、「ＭＩＰＶ６ホームプリフィックスＰ１に対するＰＭＩＰｖ６ベアラがセットアップされるときに、Ｈフラグを生成することを要求するリクエストをサポートするか否か」を通知する。ＢＵメッセージ１００８はまた、このＰＭＩＰｖ６ベアラがセットアップされるときにＨフラグを生成するトリガに加えて、ＰＭＩＰｖ６ベアラを識別する何らかの情報を含んでもよい。この識別情報は、インタフェース識別子やＡＰＮ（Access Point Name）のようなパラメータでよい。
　シグナリング・メッセージ１００８は、種々の異なるタイプで送信することができ、後述する実施の形態に開示している。シグナリング・メッセージ１００８内に埋め込まれる重要な情報は、ＭＩＰＶ６ホームプリフィックスＰ１に対するＰＭＩＰｖ６ベアラがセットアップされるときに、図１７に示すＣＭＩＰｖ６キャッシュ１６０８のＨフラグ・フィールドにＨフラグを生成するようＬＭＡ／ＨＡ１００４に要求する「ホームバインディング生成要求」である。加えて、メッセージ１００８は、ＭＩＰｖ６ホームプリフィックスＰ１をＰＭＩＰｖ６プリフィックスとしてＬＴＥインタフェースＩｆ１経由で送信することを要求する情報を、ＬＭＡ／ＨＡ１００４がそのメカニズムを有しないときに含むことができる。このＰＭＩＰｖ６プリフィックスとしてＭＩＰｖ６ホームプリフィックスＰ１を要求するのはオプションである。この要求は、ホームプリフィックスＰ１のフローに対して同時バインディングを実現するか否かのＭＮ１００３のポリシー次第である。
　さらに、メッセージ１００８は、ＬＭＡ／ＨＡ１００４におけるホームアンドアウェイのバインディングを実現するための他の情報を含むことができる。例えばメッセージ１００８は、ホームに接続（connect）したインタフェースＩｆ１のＢＩＤ値をＬＭＡ／ＨＡ１００４が生成することを要求するためのトリガを含むことができる。このＢＩＤ生成トリガがメッセージ１００８で送信されると、ＬＭＡ／ＨＡ１００４は、ホームに接続（connect）したＰＭＩＰｖ６ベアラのキャッシュに対してＢＩＤ値を生成する。さらに、ＬＭＡ／ＨＡ１００４は、このＢＩＤ値が、ＣＭＩＰｖ６メカニズムにより取り扱われているインタフェースのＢＩＤ値と異なることを保証する。このホームに接続（connect）したインタフェースＩｆ１に対して生成されたＢＩＤ値を有することにより、現在のメカニズムを使用してホームに接続（connect）されているインタフェースＩｆ１に対してフィルタリングルールをセットすることが容易となる。代わりに、ＭＮ１００３は、ＢＩＤオプションをメッセージ１００８内に記述することができる。このＢＩＤオプションは、ホームバインディングのＢＩＤ値を示すために使用される。ＢＩＤオプションを用いて、ＭＮ１００３は、ＬＭＡ／ＨＡ１００４にＢＩＤ値を生成させる代わりに、自身でホームバインディングのＢＩＤ値を記述することができる。
　ＬＭＡ／ＨＡ１００４は、メッセージ１００８を受信するとメッセージ１００８を処理して、インタフェースＩｆ１用のＰＢＵメッセージ１００９がＬＭＡ／ＨＡ１００４に到着するのを待つ。ここで、ＬＭＡ／ＨＡ１００４は、ＣＭＩＰｖ６バインディングを図１７に示すエントリ１６０８に生成しているが、生成したＣＭＩＰｖ６バインディングには未だＨフラグを挿入しない。ＬＭＡ／ＨＡ１００４は、ＭＡＧ１００５からインタフェースＩｆ１用のＰＢＵメッセージ１００９が到着すると、ＰＭＩＰｖ６バインディングを図１７に示すエントリ１６０７に生成するとともに、ＣＭＩＰｖ６バインディングにＨフラグを挿入する。ＨフラグがＣＭＩＰｖ６バインディングに挿入されると、ＭＮ１００３は、ホームに接続（connect）したインタフェースＩｆ１と、外部ドメインに接続（connect）したインタフェースＩｆ２経由で到着することができる。
　ここで、重要なことは、メッセージ１００８経由で送信された「ホームバインディング生成要求」すなわち「Ｈフラグ生成要求」は、ＰＭＩＰｖ６ベアラがセットアップされるまでアクティブではないということである。ＨフラグがＬＭＡ／ＨＡ１００４によりいったん挿入されると、ＭＮ１００３は、ＭＩＰｖ６ホームプリフィックスＰ１あてのフローを全てのインタフェースＩｆ１、Ｉｆ２経由で到着させることができ、マルチホーミングを実現することができる。
　ＰＭＩＰｖ６ベアラがいったんセットアップされると、ＬＴＥアクセスネットワーク１００２側のＭＡＧ１００５により、ホームプリフィックスＰ１がメッセージ１０１０で広告される。アクセスネットワーク１００２がＥ－ＵＴＲＡＮの場合、このホームプリフィックスＰ１は、接続（attach）が成功したＭＮ１００３に対し、ＭＭＥ（Mobility Management Entity）により広告される。当業者であれば、この実施の形態の解決策は、ＬＴＥ／３ＧインタフェースＩｆ１がブートアップされている一方で、ＷｉＭＡＸインタフェースＩｆ２がハンドオフを実行中である場合や、両方のインタフェースＩｆ１、Ｉｆ２が同時のモビリティを実行している場合にも適用することができることは明らかである。メッセージ１００８がホームバインディングに関する情報（例えばＢＩＤオプション（ＨｏＡをＣｏＡフィールドに含む））を含む場合には、ＬＭＡ／ＨＡ１００４は、その情報を、生成したホームバインディングに適用する。
　＜ＬＭＡ／ＨＡにおけるＢＣＥ＞
　次に、図１７を参照して、ＭＮ１００３が「Ｈフラグ挿入要求」をＬＭＡ／ＨＡ１００４に送信する場合に、ＬＭＡ／ＨＡ１００４において生成されるバインディングキャッシュの構造について説明する。図１７は、特定のＭＮ１００３のみに関連するバインディング・キャッシュ・エントリ（ＢＣＥ）１６００の構造を示す。ＬＭＡ／ＨＡ１００４は、ホームエージェント機能とローカル・モビリティ・アンカー機能を有するので、ＭＮ１００３のために生成されるＢＣＥ１６００は、ＰＭＩＰｖ６キャッシュとＣＭＩＰｖ６キャッシュの両方を有することが考えられる。なお、当業者であれば、ＢＣＥ１６００は、ＬＭＡ／ＨＡ１００４がサービスする多数のＭＮのバインディング・キャッシュ・エントリを有することは明らかである。このバインディングキャッシュの構造は、非常に特有である。
　マルチホーミング・パラメータがＢＵメッセージ１００８でＬＭＡ／ＨＡ１００４に通知されない場合には、ＣＭＩＰｖ６エントリがＰＭＩＰｖ６エントリより優先することが一般的に考えられる。しかし、図１７に示すようにバインディングキャッシュが例えばＨフラグ及び／又はＢＩＤオプションのような適切なマルチホーミング・パラメータを用いて生成される場合には、ＣＭＩＰｖ６とＰＭＩＰｖ６の各バインディング・キャッシュ・エントリ１６０８、１６０７は同じ優先度を有し、ＭＮ１００３あてのフローは、どちらか一方のエントリ１６０８、１６０７を使用してルーティングできる。
　図１７に示すＢＣＥ１６００における第１のフィールド１６０１は、ＭＮ１００３に関連するホームネットワーク・プリフィックス（ホームプリフィックス）Ｐ１又はホームアドレス（ＨｏＡ）を示す。ホームネットワーク・プリフィックスＰ１は一般的にＰＭＩＰｖ６バインディング（図１７の１６０７）に関連し、ホームアドレス（ＨｏＡ）は一般的にＣＭＩＰｖ６バインディング（図１７の１６０８）に関連する。なお、ＣＭＩＰｖ６バインディングもホームネットワーク・プリフィックスＰ１に関連していてもよい。第２のフィールド１６０２は、フィールド１６０２がＰＭＩＰｖ６エントリ１６０７により生成される場合には、ＭＡＧ１００５のイーグレス・アドレス（ＭＡＧ ＣｏＡ）を示す。また、ＣＭＩＰｖ６エントリ１６０８により生成されるフィールド１６０２は、ＭＮ１００３のインタフェースに関連するＣｏＡ（ＭＮ ＣｏＡ）を示す。第３のフィールド１６０３は、ＭＮ１００３のインタフェースの識別子（ＩＦ－ＩＤ）を示す。ただし、フィールド１６０３は、ＭＡＣアドレス、又は特定のインタフェースに付与されるインタフェース識別子を示すことができる。ＩＦ－ＩＤのフィールド１６０３は、ＰＭＩＰｖ６バインディングの場合には必須であるが、ＣＰＭＩＰｖ６バインディングの場合には使用されない。
　次のフィールド１６０４は、ＭＮ１００３のネットワーク・アクセス識別子（ＮＡＩ）を示し、このＮＡＩは、ＭＮ１００３の一時的な識別子であっても永久的な識別子でもよい。ＮＡＩのフィールド１６０４は、ＰＭＩＰｖ６バインディングの場合には必須であるが、ＣＰＭＩＰｖ６バインディングの場合には必須ではない。次のフィールド１６０５は、特定のバインディングのバインディング識別子（ＢＩＤ）を示し、特定のホームアドレスに関連する特定のバインディングを識別するために使用される。最後のフィールド１６０６は、ＣＭＩＰｖ６エントリ１６０８に関連するＨフラグを示す。
　「ホームバインディング生成要求」がＬＭＡ／ＨＡ１００４に到着したときにＰＭＩＰｖ６ベアラが未だ確立されていない場合、ＬＭＡ／ＨＡ１００４は、ＨフラグをＣＭＩＰｖ６エントリ１６０８のＨフラグ・フィールド１６０６に挿入しない。ＬＭＡ／ＨＡ１００４は、ＰＭＩＰｖ６キャッシュが生成されるまで待機し、ＰＭＩＰｖ６キャッシュが生成されると、ＨフラグをＣＭＩＰｖ６エントリ１６０８のＨフラグ・フィールド１６０６に挿入する。ＰＭＩＰｖ６キャッシュが既に生成されている場合に、Ｈフラグを生成するＣＭＩＰｖ６要求が到着すると、ＬＭＡ／ＨＡ１００４は、Ｈフラグ付きのＣＭＩＰｖ６エントリ１６０８を生成する。
　当業者であれば、ＭＮ１００３がホームアンドアウェイの同時登録をＬＭＡ／ＨＡ１００４に生成する方法が多くあることは明らかである。例えばＨフラグはＰＭＩＰｖ６に関連付けすることができる。代わりに、フィールド１６０５におけるＢＩＤオプション値がホームアンドアウェイの同時登録を示すことができる。
　＜Ｈフラグ生成要求メッセージのパケット構造＞
　本実施の形態で説明した「ホームバインディング生成要求」を送信する方法としては、種々の方法がある。前述した実施の形態では、ホームプリフィックスＰ１用のＰＭＩＰｖ６ベアラがセットアップされるときにＨフラグをＣＭＩＰｖ６キャッシュに挿入することをＬＭＡ／ＨＡ１００４に指示するための「ホームバインディング生成要求」は、ＢＵメッセージ１００８内の新しいオプションで行うことを記載したが、多くの変形例が考えられる。以下、詳細に説明する。
　図１８Ａ、図１８Ｂ、図１８Ｃ、図１８Ｄを参照して、「ホームバインディング生成要求」すなわち「Ｈフラグ挿入要求」を含む他の信号の構造について説明する。図１８Ａ、図１８Ｂでは、「Ｈフラグ挿入要求」は、新しいモビリティ・ヘッダタイプで送信される。図１８Ａに示すパケット１４１０は、ＩＰｖ６ヘッダ１４１１と、認証ヘッダ１４１２と新モビリティ拡張ヘッダ１４１３の各フィールドを含み、新モビリティ拡張ヘッダ１４１３のフィールドは、標準フィールド１４１４と、「Ｈフラグ挿入要求」を示す新フィールド１４１５を含む。図１８Ｂに示すパケット１４３０は、ＩＰｖ６ヘッダ１４３１と、認証ヘッダ１４３２と新モビリティ拡張ヘッダ１４３３の各フィールドを含み、新モビリティ拡張ヘッダ１４３３のフィールドは、標準フィールド１４３４と、ＢＩＤオプション１４３５のフィールドと、「Ｈフラグ挿入要求」を示す新フィールド１４３６を含む。なお、信号としてはＭＮ１００３がネットワークに接続した際に行うＩＫＥｖ２メッセージを用いてもよい。
　図１８Ｃ、図１８Ｄでは、「Ｈフラグ挿入要求」は、通常のＢＵヘッダタイプで送信される。図１８Ｃに示すパケット１４２０は、ＩＰｖ６ヘッダ１４２１と、認証ヘッダ１４２２とＢＵヘッダ１４２３の各フィールドを含み、ＢＵヘッダ１４２３のフィールドは、標準フィールド１４２４と新モビリティ・オプション１４２５の各フィールドを含む。新モビリティ・オプション１４２５のフィールドは、「Ｈフラグ挿入要求」と、ＰＭＩＰｖ６ベアラを識別するためのインタフェース識別子を含む。図１８Ｄに示すパケット１４４０は、ＩＰｖ６ヘッダ１４４１と、認証ヘッダ１４４２とＢＵヘッダ１４４３の各フィールドを含み、ＢＵヘッダ１４４３のフィールドは、標準フィールド１４４４と、ＢＩＤオプション１４４５のフィールドと、「Ｈフラグ挿入要求」を示す新モビリティ・オプション１４４５の各フィールドを含む。ＩＰｖ６ヘッダ１４１１、１４２１、１４３１、１４４１における送信元アドレスはＭＮ１００３のＣｏＡであり、あて先アドレスはＭＮ１００３のホームエージェントであるＬＭＡ／ＨＡ１００４のアドレスである。
　以上、「Ｈフラグ挿入要求」を送信する種々のパケット構造について説明したが、他にも多くの方法がある。新しいオプションや新しいフィールドで送信する代わりに、例えば新しいフラグで「Ｈフラグ挿入要求」を送信することができる。さらに、「Ｈフラグ挿入要求」を、保留されている新しいＢＩＤ値でも送信することができる。新しいＢＩＤ値は、他の複数ＣｏＡバインディングには使用されないように保留されていることをグローバルに告知される。
　また、他の方法として、「Ｈフラグ挿入要求」を第１の実施の形態において図６Ａに示したＬ２フレーム３０７Ｂの信号でＭＮ１００３から、ＭＮ１００３の代理ノードであるＭＡＧ１００５に通知してもよい。この場合、ＭＮ１００３は、ＰＣＯ（Protocol Configuration Option）を用いることができる。ＭＡＧ１００５は、この「Ｈフラグ挿入要求」をＬＭＡ／ＨＡ１００４に対し、ＰＢＵメッセージ１００９内のＰＣＯ、又は新しいオプション又は新しいフラグで通知する。ＬＭＡ／ＨＡ１００４は、このＰＣＯ、又は新しいオプション又は新しいフラグを参照すると、ホームプリフィックスＰ１用のＰＭＩＰｖ６ベアラがセットアップされるときにＨフラグをＣＭＩＰｖ６キャッシュに挿入する。なお、信号としては、アクセスネットワークに特有のメッセージを用いてもよい。
　図６Ａに示すＬ２フレーム３０７ＢにおけるプロトコルＩＤ３０３Ｂのフィールドは、Ｌ２より上位の層で発生するパケットのときにのみ値を有する。プロトコルＩＤ３０３Ｂの値は、「Ｈフラグ挿入要求」がＬ２で発生したときにはオール０である。しかし、「Ｈフラグ挿入要求」がＬ２で発生しても、「Ｈフラグ挿入要求」を送信する決定と、Ｌ２フレーム３０７Ｂ内に埋め込む関連パラメータはＬ３から来なければならない。「Ｈフラグ挿入要求」は、情報３０４Ｂのフィールドにより伝送される。オプションとして、情報３０４Ｂのフィールドは、ＣＭＩＰｖ６バインディングのＢＩＤを伝送してもよい。「Ｈフラグ挿入要求」は、図６Ａに示すＬ２フレーム３０７Ｂ以外の他のフレーム構造でも送信することができる。
　また、ＭＮ１００３は、図６Ａに示したＬ２フレーム３０７Ｂを用いて、ＭＮ１００３の代理ノードであるＭＡＧ１００５に対して、ＢＩＤをＣＭＩＰｖ６キャッシュに挿入する要求（ＢＩＤ挿入要求）を通知してもよい。このＢＩＤは、ＭＮ１００３が付与するか、又はＭＡＧ１００５が生成することができる。代わりに、ＭＡＧ１００５は、ＣＭＩＰｖ６キャッシュのＢＩＤとしてインタフェース識別子を使用するようＬＭＡ／ＨＡ１００４に要求するために、ＰＢＵメッセージ１００９内の特別なフラグを関連付けしてもよい。ここで重要な点は、Ｌ２メッセージを使用するときには、ＷｉＭＡＸインタフェースＩｆ２のために送信されるＣＭＩＰｖ６－ＢＵメッセージ１００８が、ＰＭＩＰｖ６ベアラがセットアップされるときにＨフラグを挿入するためのトリガを含まないということである。
　＜ＭＮの構成＞
　図１９は、第９の実施の形態におけるＭＮ１００３の構成を説明するための機能的アーキテクチャ１３００を示すブロック図である。機能的アーキテクチャ１３００は、ＭＮ１００３に備えるのに必要な全てのソフトウエア、ハードウエア及びファームウエアを示す。機能的アーキテクチャ１３００は、３つのサブ・モジュールにより構成され、具体的には下位層プロトコル・モジュール１３０１と、レイヤ３プロトコル・モジュール１３０２と上位層プロトコル・モジュール１３０３により構成される。
　下位層プロトコル・モジュール１３０１は、ＭＮ１００３の各インタフェースＩｆ１、Ｉｆ２に関連する複数の下位層プロトコル・モジュールにより構成され、この複数の下位層プロトコル・モジュールは、主にリンク層の制御及び伝送のメカニズムに関連している。レイヤ３（Ｌ３）プロトコル・モジュール１３０２は、５つのサブ・モジュール、すなわちマルチホーミング・サポートユニット１３０４と、ＩＰｖ６ルーティング・ユニット１３０５と、ＭＩＰｖ６モビリティ管理ユニット１３０６と、Ｈフラグ生成要求ユニット１３０７と、ホームプリフィックス参照予測ユニット１３０８を含む。Ｌ３プロトコル・モジュール１３０２はまた、各ユニット１３０４～１３０８間でメッセージを交換するための不図示のインタフェースを有する。また、各ユニット１３０４～１３０８は、関連するバインディングリストを必要な場合に有する。
　ＩＰｖ６ルーティング・ユニット１３０５は、近隣探索と、アドレス構成と基本的なＩＰｖ６ルーティング・メカニズムを実行し、ＭＩＰｖ６モビリティ管理ユニット１３０６は、バインディングのアップデート及び登録削除のメカニズムのようなＭＩＰｖ６モビリティ管理機能を実行する。マルチホーミング・サポートユニット１３０４は、ＢＵメッセージ内のＢＩＤを生成したり、Ｈフラグを添付したりする複数登録機能を実行する。Ｈフラグ生成要求ユニット１３０７は、ホームプリフィックスＰ１用のＰＭＩＰｖ６ベアラがセットアップされるときにＨフラグを生成するようにＬＭＡ／ＨＡ１００４に要求する「ホームバインディング生成要求」を構成する機能を有する。ホームプリフィックス参照予測ユニット１３０８は、種々の多くのファクタに基づいてホームプリフィックス参照を予測する機能を有する。ホームプリフィックス参照の予測については、既に詳しく説明した。当業者であれば、各ユニット１３０４～１３０８は、実施するときには適当なソフトウエア・インタフェースを必要とすることは明らかである。
　最後に上位層プロトコル・モジュール１３０３は、ＭＮ１００３に備えるトランスポート層とアプリケーション層のような上位層プロトコルの機能を有する。当業者であれば、図１９に示した機能的モジュールは、一例であって、本発明の範囲及び精神を逸脱しない限り、種々の実施方法があることは明らかである。
　＜ＭＮの動作＞
　次に、図２０に示すフローチャートを参照して、ＭＮ１００３（３ＧＰＰではＵＥ(User Equipment)と呼ばれる）の動作を説明する。ＭＮ１００３はまず、ステップ１１００を実行して、ホームプリフィックスＰ１を３ＧインタフェースＩｆ１経由で参照するかもしれないか否かを予測する。この予測処理については、既に詳しく説明したので、ここでは繰り返して説明しない。ステップ１１００における判断がＮＯの場合、すなわちＭＮ１００３は、ホームプリフィックスＰ１を３ＧインタフェースＩｆ１経由で参照することを高い確率で予測できない場合には、ステップ１１０１に進み、通常の動作、すなわちＨフラグなしのＢＵメッセージを送信する。ステップ１１０１では、マルチホーミングに関するパラメータも添付せず、また、新しいオプションも埋め込まないＷｉＭＡＸインタフェースＩｆ２用の通常のＢＵメッセージを送信する。
　他方、ステップ１１００における判断がＹＥＳの場合にはステップ１１０２に進み、ＭＮ１００３は、「ホームバインディング生成要求」を追加した新しいＢＵメッセージ１００８をホームエージェント（ＬＭＡ／ＨＡ）１００４に送信して、ホームプリフィックスＰ１用のＰＭＩＰｖ６ベアラがセットアップされるときにＨフラグをＣＭＩＰｖ６エントリ１６０８に挿入するようにＬＭＡ／ＨＡ１００４に要求する。ＭＮ１００３は、ステップ１１０２においてこの新しい（すなわち、新しいオプションを含む）ＢＵメッセージ１００８を送信した後、ＨＡからの応答であるＡＣＫ信号（ＢＡメッセージ１０１０）を待つ。
　ＭＮ１００３は、ＡＣＫ信号を受信すると、ＡＣＫ信号をチェックして、「ホームプリフィックスＰ１用のＰＭＩＰｖ６ベアラがセットアップされるときにＬＭＡ／ＨＡ１００４がＨフラグをセットするという応答」が有るか否かをチェックする（ステップ１１０３）。ＨＡがＨフラグをセットする場合には（ステップ１１０３でＹＥＳ）、ＭＮ１００３は、ホームプリフィックスＰ１をＬＴＥインタフェースＩｆ１経由で参照しても、Ｈフラグ付きのＢＵメッセージ（図１５に示す９０９）をＬＭＡ／ＨＡ１００４に送信しないことを決定する（ステップ１１０４）。ステップ１１０３でＮＯの場合とは、ＭＮ１００３がステップ１１０２で送信したＢＵメッセージ１００８をＬＭＡ／ＨＡ１００４が了解していない場合か、又はＬＭＡ／ＨＡ１００４がＭＩＰｖ６ホームプリフィックスＰ１をＬＴＥインタフェースＩｆ１経由で付与したくない場合かである。この場合には、ＭＮ１００３は、通常の動作に戻って、ホームプリフィックスＰ１を参照するまで待機し、参照すると、ＢＩＤオプションにＨフラグをセットしたＢＵメッセージ（図１５に示す９０９）をＨＡに送信する（ステップ１１０５）。
　＜ＬＭＡ／ＨＡの処理＞
　次に、図２１を参照してＬＭＡ／ＨＡ１００４の処理について説明する。なお、第９の実施の形態のＬＭＡ／ＨＡ１００４の構成については示されていないが、その機能的な構成は、第１の実施の形態における図１０とほぼ同じであるので、図示を省略する。図２１において、ＬＭＡ／ＨＡ１００４は第１ステップ１５００では、受信したメッセージが、ホームプリフィックスＰ１用のＰＭＩＰｖ６バインディングが生成されるときにＨフラグを挿入するよう要求する新しいタイプのメッセージ（ＢＵメッセージ１００８、以下では「Ｈフラグ挿入要求メッセージ」）か否かをチェックする。ステップ１５００においてＮＯの場合には、ＬＭＡ／ＨＡ１００４はステップ１５０１において、通常の動作としてＰＢＵ又はＢＵのメッセージのような他の標準のシグナリング・メッセージの処理を実行する。
　他方、ステップ１５００においてＹＥＳの場合には、ＬＭＡ／ＨＡ１００４はステップ１５０２において、Ｈフラグ挿入要求メッセージが到着した時点でＰＭＩＰｖ６バインディング（エントリ１６０７）がセットアップされているか否かをチェックする。ステップ１５０２においてＮＯの場合にはステップ１５０３に進む。この場合、ＣＭＩＰｖ６バインディング（エントリ１６０８）が最初に生成されたが、ＬＭＡ／ＨＡ１００４のＰＭＩＰｖ６ベアラがセットアップされるときにＨフラグが挿入されると考えられる。このため、ＬＭＡ／ＨＡ１００４はステップ１５０３において、エントリ１６０８のＣＭＩＰｖ６バインディングを用いてパケットをルーティングする。他方、ステップ１５０２においてＹＥＳの場合には、ＬＭＡ／ＨＡ１００４のＰＭＩＰｖ６ベアラが既にセットアップされているので、ＬＭＡ／ＨＡ１００４はステップ１５０４において、エントリ１６０８においてＨフラグ付きのＣＭＩＰｖ６キャッシュを生成する。
　＜第９の実施の形態の他の想定例＞
　図２２は、３ＧＧＰネットワーク間でチェーン（Chained Scenario）が形成されているとなっている場合のシステムを想定している。この３ＧＧＰチェーンのシステムでは、外部ドメインであるＥＰＣ（ＶＰＬＭＮ）１２０１におけるＳ－ＧＷ（Serving GateWay）１２０６がＭＮ（ＵＥ１２００）に対して、経路途中のモビリティ管理アンカーとして動作する。この想定では、ＵＥ１２００に接続（attach）するＭＡＧであるｅＰＤＧ１２０７が、Ｐ－ＧＷ（Packet data network GateWay）１２０５のアドレスと関連するバインディング・パラメータを、経路途中のモビリティ管理アンカーであるＳ－ＧＷ１２０６に送信する。さらに、Ｓ－ＧＷ１２０６は、受信したバインディング・パラメータをＰ－ＧＷ１２０５に送信して、ＰＭＩＰｖ６バインディングをＰ－ＧＷ１２０５に生成する。
　３ＧＧＰは、特に、ＵＥ１２００がＶＰＬＭＮ１２０２に位置していて、プリフィックスを管理するノードが、ＨＰＬＭＮ１２０１に位置するＰ－ＧＷ１２０５である場合に、上記のチェーンのアーキテクチャを使用してモビリティ管理を実現する。上記の経路途中のモビリティ管理アンカーが存在しない場合、ＵＥがＭＡＧに接続するたびに、新しいＰＭＩＰｖ６－ＢＵメッセージがＶＰＬＭＮ１２０２からＨＰＬＭＮ１２０１に転送されなければならず、このため、ハンドオフ遅延を招く。ＵＥ１２００がＶＰＬＭＮ１２０２に位置し、かつＵＥ１２００がＭＡＧを変更しているときにＳ－ＧＷ１２０６が変化しない場合、そのＳ－ＧＷ１２０６は、バインディング・パラメータをＰ－ＧＷ１２０５に送信する必要がなく、ＶＰＬＭＮ１２０１に位置するＵＥ１２００にとっては高速モビリティ管理が実現する。３ＧＧＰチェーンの想定の詳細は、非特許文献６に記載されている。
　３ＧＧＰチェーンのシステムについて詳しく説明する。この想定例における主要な目的は、３ＧＧＰの非常に現実的なネットワーク・アーキテクチャではホームプリフィックスＰ１が遅延することを示すことにある。図２２において、ＵＥ１２００は、３ＧＰＰコアネットワークであってＵＥ１２００のＨＰＬＭＮ（Home Public Land Mobile Network）でもあるＥＰＣ（Evolved Packet Core）１２０１に対し、ＷｉＭＡＸインタフェースＩとＷＬＡＮインタフェースの２つを介して接続（connect）している。さらに、ＵＥ１２００は、ＥＰＣ１２０１のＰ－ＧＷ１２０５をホームエージェントとして構成していることが考えられる。さらに、ＵＥ１２００は、ＷｉＭＡＸインタフェースがＷｉＭＡＸアクセスネットワーク１２０４経由で接続（attach）し、かつＷＬＡＮインタフェースがＷＬＡＮアクセスネットワーク１２０３、及びＶＰＬＭＮ（visited public land mobile network）であるＥＰＣ１２０２経由で接続（attach）しているものとする。図２２から明らかなように、ＷＬＡＮインタフェースは３ＧＰＰチェーンのアーキテクチャに接続（connect）されている。さらに、ＷｉＭＡＸインタフェースのモビリティがＭＩＰｖ６メカニズムにより管理され、かつＷＬＡＮインタフェースのモビリティがＰＭＩＰｖ６メカニズムにより管理されることが考えられる。このような想定例において、ＵＥ１２００は、同時接続によりマルチホーミングを実現したい。
　ＵＥ１２００は、ＷｉＭＡＸインタフェースがＷｉＭＡＸアクセスネットワーク１２０４に接続（attach）すると、アクセス認証（authentication）の完了後に、ＣｏＡを構成するために、アクセスゲートウェイ（ＡＧＷ）１２０８にルーティングされるプリフィックスＰ２をプリフィックス広告メッセージ１２０９で取得する。さらに、ＵＥ１２００は、ＷＬＡＮインタフェース経由の接続（attachment）処理を開始するものとする。しかし、ＷＬＡＮアクセスの接続認証（authentication）と資格認証（authorization）の成功後に、ＶＰＬＭＮ１２０２側のｅＰＤＧ１２０７は、バインディング・パラメータをＳ－ＧＷ１２０６に送信し（シグナリング・メッセージ１２１１）、さらにＳ－ＧＷ１２０６は、ＰＭＩＰｖ６バインディングをＨＰＬＭＮ１２０１側のＰ－ＧＷ１２０５に送信する（ＰＢＵメッセージ１２１２）。
　上記の３ＧＰＰチェーンの想定において全てのＰＭＩＰｖ６ベアラをセットアップするのには、チェーニングプロセスためにある程度時間がかかる。図２２において、ＵＥ１２００は、ＡＧＷ１２０８からのプリフィックス（Ｐ２とする）を参照したときには、未だＰＭＩＰｖ６プリフィックス（ホームプリフィックスＰ１とする）をＷＬＡＮインタフェース経由で参照していない。
　図２２において、ＵＥ１２００は、ホームプリフィックスＰ１をＷＬＡＮインタフェース経由で参照するかもしれないと予測すると、「ホームバインディング生成要求」を含むＢＵメッセージ１２１０をＰ－ＧＷ１２０５に送信する。ここで、Ｐ－ＧＷ１２０５は、最初にＢＵメッセージ１２１０を参照してＨフラグなしのＣＭＩＰｖ６キャッシュを生成し、Ｓ－ＧＷ１２１２からのＰＢＵメッセージ１２１２を受信したときに、ＨフラグをＣＭＩＰｖ６キャッシュに挿入するものとする。ここで、当業者であれば、Ｐ－ＧＷ１２０５は、Ｓ－ＧＷ１２１２からのＰＢＵメッセージ１２１２の前にＵＥ１２００からのＢＵメッセージ１２１０を最初に受信したときには、ＵＥ１２００のホームアンドアウェイのバインディングを生成できることは明らかである。
　＜第９の実施の形態のさらに他の想定例：ホームに接続（connect）しているインタフェースがハンドオフする場合＞
　上記のホームアンドアウェイの同時登録の想定では、ＣＭＩＰｖ６バインディングとＰＭＩＰｖ６バインディングが同時に行われなければならない。次に、変形例として、「ホームバインディング生成要求」が、ホームに接続（connect）しているインタフェースのハンドオフを取り扱う場合について説明する。ここで、外部に接続（connect）しているインタフェースは、未だ同じアクセスルータに接続（connect）している。図２３を参照して詳しく説明する。ＭＮ１７０３は２つのインタフェースを有し、例えばＷｉＭＡＸインタフェースは、ＷｉＭＡＸアクセスネットワーク１７０１経由でＭＡＧ１７０６に接続（connect）していることが考えられる。ここで、ＬＴＥインタフェースは、ＬＴＥアクセスネットワーク１７０２経由で最初はＭＡＧ１７０５に接続（connect）し、次にＭＮ１７０３の移動により別のＭＡＧ１７０７に接続（connect）するものとする。さらにＭＮ１７０３は、３ＧのＬＴＥアクセスネットワーク１７０２により、ＭＡＧ１７０５とＭＡＧ１７０７に接続（connect）するものとする。
　上記の場合、ＭＮ１７０３は、ハンドオフ前のＭＡＧ１７０５からのメッセージ１７１１でホームプリフィックスＰ１を参照する前に、ＷｉＭＡＸ側のＭＡＧ１７０６からのルータ広告メッセージ１７０８で付与されるプリフィックスＰ２を使用してＣｏＡを生成して、「ホームバインディング生成要求」をＢＵメッセージ１７０９でＬＭＡ／ＨＡ１７０４に送信する。次にハンドオフ前のＭＡＧ１７０５からのＰＭＩＰｖ６－ＰＢＵメッセージ１７１０（ＰＢＵ１）がＬＭＡ／ＨＡ１７０４に到着すると、ＬＭＡ／ＨＡ１７０４におけるＣＭＩＰｖ６バインディングキャッシュにＨフラグが挿入される。
　ここで、「ホームバインディング生成要求」を含むＢＵメッセージ１７０９は、ハンドオフのＰＭＩＰｖ６－ＰＢＵメッセージ１７１２（ＰＢＵ２）がＢＩＤやＨフラグのようなマルチホーミング・パラメータを含まなくても、ホームアンドアウェイ登録を削除しないようＬＭＡ／ＨＡ１７０４に通知するための新しい情報を含む。非特許文献５によれば、水平ハンドオフの場合は、ＰＢＵメッセージ１７１０、１７１２内にハンドオフ指示オプション（オプション値＝３）を含む。このため、ＭＮ１７０３のホームに接続（connect）しているＬＴＥインタフェースＩｆ１が別のＭＡＧ１７０７に移動すると、ＭＡＧ１７０７からＬＭＡ／ＨＡ１７０４に送信されるＰＭＩＰｖ６－ＰＢＵメッセージ１７１２（ＰＢＵ２）は、水平ハンドオフ指示を含み、マルチホーミング・パラメータを含まないであろう。この場合、「ホームバインディング生成要求」を含むＢＵメッセージ１７０９が上記の新しい情報を含むので、ＰＭＩＰｖ６－ＰＢＵメッセージ１７１２（ＰＢＵ２）は、ＬＭＡ／ＨＡ１７０４におけるホームアンドアウェイのステートを上書きせず、ホームアンドアウェイ登録を削除しない。ホームアンドアウェイのステートを削除できるのは、ＭＮ１７０３がＬＭＡ／ＨＡ１７０４に対し、ホーム又は外部に接続（connect）しているインタフェースの登録を解除するよう明示したときのみである。ホームに接続（connect）しているインタフェースの登録解除は、ＰＭＩＰｖ６メカニズムにより行われ、外部に接続（connect）しているインタフェースの登録解除は、ＣＭＩＰｖ６メカニズムにより行われる。
　ホームアンドアウェイ同時接続の情報は、新しいトリガとして、ハンドオフ後の新しいＭＡＧ１７０７に送信することもできる。この新しいトリガとしては、Ｌ２特有のメッセージや、近隣探索に関するメッセージのようなＬ３特有のメッセージを使用することができる。ホームアンドアウェイに関する新しいトリガがＭＡＧ１７０７に送信されると、ＭＡＧ１７０７は、この情報をハンドオフのＰＢＵメッセージ１７１２（ＰＢＵ２）でＬＭＡ／ＨＡ１７０４に送信する。このハンドオフのＰＢＵメッセージ１７１２（ＰＢＵ２）内のホームアンドアウェイの情報により、上記のハンドオフの想定例においてもＬＭＡ／ＨＡ１７０４におけるホームアンドアウェイのバインディングが維持される。
　以上、最も実際的かつ望ましい実施の形態について説明したが、当業者であれば、本発明の範囲及び精神を逸脱しない範囲で構成及びパラメータについて種々の変形が可能であることは明らかである。例えば３ＧとＷｉＭＡＸのインタフェースを例にして説明したが、本発明は、他の異なるアクセス技術タイプを有し、そのアクセス技術タイプのインタフェースをネットワークに接続（attach）する場合にも適用することができる。さらに、前述した想定例は３ＧＰＰに関するが、本明細書に記載した問題及び解決策は、異種のアクセスネットワークにより構成されていて、あるアクセス技術タイプ経由のあるモビリティ管理メカニズムの使用を制限する他の全てのＳＤＯに適用することができる。
　以上、本発明について実施の形態を参照して説明したが、当業者であれば、本発明を逸脱しない種々の変形が可能であることは明らかである。例えば上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。
　本発明によれば、特許請求の範囲に記載したように、以下のような発明が提供される。
（１）請求項１に記載のバインディングキャッシュ生成方法、又は請求項５に記載のバインディングキャッシュ生成システムにおいて、前記ホームエージェントが、前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュの存続期間が満了した場合に前記第２のインタフェース用のクライアントベースのバインディングキャッシュを削除することを特徴とする。
（２）請求項１又は２に記載のバインディングキャッシュ生成方法、又は請求項５又は６に記載のバインディングキャッシュ生成システムにおいて、前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュが前記ホームエージェントに登録された後に、前記モバイルノードが前記ホームエージェントに対して、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して維持する要求メッセージを送信し、
　前記ホームエージェントが、前記要求メッセージを受信した後、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュが登録された場合に、前記第１及び登録された第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するとともに、前記モバイルノードに対して前記要求メッセージを再度送信しないように通知することを特徴とする。
（３）請求項１又は２に記載のバインディングキャッシュ生成方法、又は請求項５又は６に記載のバインディングキャッシュ生成システムにおいて、前記ホームエージェントが、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録するプロキシ・バインディング・アップデートメッセージを受信した場合に前記第２のプロキシ・バインディングキャッシュを生成するとともに、前記第１及び前記生成した第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記モバイルノードに対して前記クライアントベースのバインディングキャッシュを登録する要求メッセージを送信しないように通知することを特徴とする。
（４）請求項１６に記載のバインディングキャッシュ生成方法において、前記ホームドメインの各プロキシノードの間で、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するための情報を転送することを特徴とする。
（５）請求項１から４、及び１４から１７までのいずれか１つに記載のバインディングキャッシ生成方法において、前記モバイルノードが、前記ホームドメインから外部ドメインにローミングした場合に、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成する要求を前記外部ドメインを経由して前記ホームエージェントに通知することを特徴とする。
　本発明は、複数のインタフェースを有するモバイルノードがホームドメイン内をローミングする場合に、ホームエージェントにおいてクライアントベースのバインディングキャッシュを生成して管理する場合のシグナリングを減少することができるという効果を有し、ホームドメインが３ＧのＰＭＩＰｖ６ドメインなどの場合に利用することができる。
　また本発明は、複数のインタフェースを有するモバイルノードがホームリンクと外部リンクに同時に接続（connect）しているときのバインディング登録のシグナリングを減少することができるという効果を有し、ホームドメインが３ＧのＰＭＩＰｖ６ドメインなどの場合に利用することができる。

Claims (29)

  1. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成方法であって、
    　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録するステップと、
    　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録するステップと、
    　前記ホームエージェントが、前記第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記生成したクライアントベースのバインディングキャッシュを前記モバイルノードによりリフレッシュされることなく維持するステップとを、
    　有するバインディングキャッシュ生成方法。
  2. 　前記ホームエージェントが、前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュの存続期間が満了した場合に前記第２のインタフェース用のクライアントベースのバインディングキャッシュを削除することを特徴とする請求項１に記載のバインディングキャッシュ生成方法。
  3. 　前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュが前記ホームエージェントに登録された後に、前記モバイルノードが前記ホームエージェントに対して、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して維持する要求メッセージを送信し、
    　前記ホームエージェントが、前記要求メッセージを受信した後、前記第１及び第２のインタフェース用の第１及び第２のプロキシ・バインディングキャッシュが登録された場合に、前記登録された第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するとともに、前記モバイルノードに対して前記要求メッセージを再度送信しないように通知することを特徴とする請求項１に記載のバインディングキャッシュ生成方法。
  4. 　前記ホームエージェントが、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録するプロキシ・バインディング・アップデートメッセージを受信した場合に前記第２のプロキシ・バインディングキャッシュを生成するとともに、前記第１及び前記生成した第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記モバイルノードに対して前記クライアントベースのバインディングキャッシュを登録する要求メッセージを送信しないように通知することを特徴とする請求項１に記載のバインディングキャッシュ生成方法。
  5. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成システムであって、
    　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録する手段と、
    　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録する手段と、
    　前記ホームエージェントが、前記第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記生成したクライアントベースのバインディングキャッシュを前記モバイルノードによりリフレッシュされることなく維持する手段とを、
    　有するバインディングキャッシュ生成システム。
  6. 　前記ホームエージェントが、前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュの存続期間が満了した場合に前記第２のインタフェース用のクライアントベースのバインディングキャッシュを削除することを特徴とする請求項５に記載のバインディングキャッシュ生成システム。
  7. 　前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュが前記ホームエージェントに登録された後に、前記モバイルノードが前記ホームエージェントに対して、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して維持する要求メッセージを送信し、
    　前記ホームエージェントが、前記要求メッセージを受信した後、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュが登録された場合に、前記第１及び前記登録された第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するとともに、前記モバイルノードに対して前記要求メッセージを再度送信しないように通知することを特徴とする請求項５に記載のバインディングキャッシュ生成システム。
  8. 　前記ホームエージェントが、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録するプロキシ・バインディング・アップデートメッセージを受信した場合に前記第２のプロキシ・バインディングキャッシュを生成するとともに、前記第１及び前記生成した第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記モバイルノードに対して前記クライアントベースのバインディングキャッシュを登録する要求メッセージを送信しないように通知することを特徴とする請求項５に記載のバインディングキャッシュ生成システム。
  9. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成システムにおける前記ホームエージェントであって、
    　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを登録する手段と、
    　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録する手段と、
    　前記第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記生成したクライアントベースのバインディングキャッシュを前記モバイルノードによりリフレッシュされることなく維持する手段とを、
    　有するホームエージェント。
  10. 　前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュの存続期間が満了した場合に前記第２のインタフェース用のクライアントベースのバインディングキャッシュを削除することを特徴とする請求項９に記載のホームエージェント。
  11. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成システムにおける前記モバイルノードであって、
    　前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュが前記ホームドメインのホームエージェントに登録される際に、前記ホームエージェントに対して、前記第１及び第２のインタフェース用の第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して維持するよう要求するメッセージを送信する手段を、
    　有するモバイルノード。
  12. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合、前記モバイルノードが、前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュが前記ホームエージェントに登録される際に、前記ホームドメインのホームエージェントに対して、前記第１及び第２のインタフェース用の第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して維持するよう要求するメッセージを送信するバインディングキャッシュ生成システムにおける前記ホームエージェントであって、
    　前記要求メッセージを受信した後、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録した場合に、前記第１及び前記登録した第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するとともに、前記モバイルノードに対して前記要求メッセージを再度送信しないように通知する手段を、
    　有するホームエージェント。
  13. 　前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録するプロキシ・バインディング・アップデートメッセージを受信した場合に前記第２のプロキシ・バインディングキャッシュを生成するとともに、前記第１及び前記生成した第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記モバイルノードに対して前記クライアントベースのバインディングキャッシュを登録する要求メッセージを送信しないように通知することを特徴とする請求項９に記載のホームエージェント。
  14. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成方法であって、
    　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録するステップと、
    　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録するステップと、
    　前記モバイルノードが前記ホームエージェントに対し、前記ホームエージェントが前記第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記生成したクライアントベースのバインディングキャッシュを通常時より長い存続期間の間、前記モバイルノードによりリフレッシュされることなく維持するよう要求するステップとを、
    　有するバインディングキャッシュ生成方法。
  15. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成方法であって、
    　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録するステップと、
    　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録するステップと、
    　前記モバイルノードが前記ホームエージェントに対し、前記ホームエージェントが前記登録した第１及び第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するよう要求するステップと、
    　前記ホームエージェントが、前記要求されたクライアントベースのバインディングキャッシュを生成して通常時より長い存続期間を設定するとともに、前記モバイルノードに対して、前記存続期間の間、前記生成したクライアントベースのバインディングキャッシュをリフレッシュしないよう通知するステップとを、
    　有するバインディングキャッシュ生成方法。
  16. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードが前記ホームドメイン内をローミングする場合のバインディングキャッシュ生成方法であって、
    　前記モバイルノードの第１のインタフェースが前記ホームドメインに接続した場合に前記第１のインタフェース用の第１のプロキシ・バインディングキャッシュを前記ホームドメインのホームエージェントに登録するステップと、
    　前記モバイルノードの第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを前記ホームエージェントに登録するステップと、
    　前記ホームエージェントが、前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュが登録されたときに、前記モバイルノードに対して前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成する要求を送信しないよう通知するとともに、前記第１及び第２のプロキシ・バインディングキャッシュに関連するクライアントベースのルーティングを実行するステップとを、
    　有するバインディングキャッシュ生成方法。
  17. 　前記ホームドメインの各プロキシノードの間で、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成するための情報を転送することを特徴とする請求項１６に記載のバインディングキャッシュ生成方法。
  18. 　前記モバイルノードが、前記ホームドメインから外部ドメインにローミングした場合に、前記ホームエージェントに対して、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成する要求を前記外部ドメインを経由して通知することを特徴とする請求項１に記載のバインディングキャッシュ生成方法。
  19. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードがローミングする場合に、前記第１及び第２のインタフェース用のバインディングキャッシュを前記モバイルノードのホームエージェントに生成するバインディングキャッシュ生成方法であって、
    　前記第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に、前記モバイルノードが前記ホームエージェントに対し、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを登録するとともに、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録されるときにホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットするよう要求するステップと、
    　前記第１のインタフェースが前記ホームドメインに接続した場合に、前記モバイルノードの代理ノードが前記ホームエージェントに対し、前記第１のインタフェース用のプロキシ・バインディングキャッシュを登録するステップと、
    　前記ホームエージェントが、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録された場合に、前記フラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットするステップとを、
    　有するバインディングキャッシュ生成方法。
  20. 　前記モバイルノードが、前記ホームドメインのプリフィックスを前記第１のインタフェース経由で参照するであろうことを予測して前記要求を前記ホームエージェントに送信することを特徴とする請求項１９に記載のバインディングキャッシュ生成方法。
  21. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードがローミングする場合に、前記第１及び第２のインタフェース用のバインディングキャッシュを前記モバイルノードのホームエージェントに生成するバインディングキャッシュ生成システムであって、
    　前記第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に、前記モバイルノードが前記ホームエージェントに対し、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを登録するとともに、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録されるときにホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットするよう要求する手段と、
    　前記第１のインタフェースが前記ホームドメインに接続した場合に、前記モバイルノードの代理ノードが前記ホームエージェントに対し、前記第１のインタフェース用のプロキシ・バインディングキャッシュを登録する手段と、
    　前記ホームエージェントが、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録された場合に、前記ホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットする手段とを、
    　有するバインディングキャッシュ生成システム。
  22. 　前記モバイルノードが、前記ホームドメインのプリフィックスを前記第１のインタフェース経由で参照するであろうことを予測して前記要求を前記ホームエージェントに送信することを特徴とする請求項２１に記載のバインディングキャッシュ生成システム。
  23. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードがローミングする場合に、前記第１及び第２のインタフェース用のバインディングキャッシュを前記モバイルノードのホームエージェントに生成するバインディングキャッシュ生成システムにおける前記モバイルノードであって、
    　前記第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に、前記ホームエージェントに対し、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを登録するとともに、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録されるときにホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットするよう要求する手段を、
    　有するモバイルノード。
  24. 　前記ホームドメインのプリフィックスを前記第１のインタフェース経由で参照するであろうことを予測して前記要求を前記ホームエージェントに送信することを特徴とする請求項２３に記載のモバイルノード。
  25. 　ホームドメインと通信可能な第１のインタフェースとローカルドメインと通信可能な第２のインタフェースを有するモバイルノードがローミングする場合に、前記第１及び第２のインタフェース用のバインディングキャッシュを前記モバイルノードのホームエージェントに生成するバインディングキャッシュ生成システムにおける前記ホームエージェントであって、
    　前記第２のインタフェースが前記ローカルドメインを介して前記ホームドメインに接続した場合に、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを登録するとともに、前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録されるときにホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットする要求を受信する手段と、
    　前記第１のインタフェースが前記ホームドメインに接続した場合に、前記第１のインタフェース用のプロキシ・バインディングキャッシュを登録する手段と、
    　前記第１のインタフェース用のプロキシ・バインディングキャッシュが登録された場合に、前記ホームとアウェイの同時接続を示すフラグを前記第２のインタフェース用のクライアントベースのバインディングキャッシュにセットする手段とを、
    　有するホームエージェント。
  26. 　前記第２のインタフェース用の第２のプロキシ・バインディングキャッシュを登録するプロキシ・バインディング・アップデートメッセージを受信した場合に前記第２のプロキシ・バインディングキャッシュを生成するとともに、前記第１及び前記生成した第２のプロキシ・バインディングキャッシュに関連する前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成して、前記モバイルノードに対して前記クライアントベースのバインディングキャッシュを登録する要求メッセージを送信しないように通知することを特徴とする請求項１２に記載のホームエージェント。
  27. 　前記モバイルノードが、前記ホームドメインから外部ドメインにローミングした場合に、前記ホームエージェントに対して、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成する要求を前記外部ドメインを経由して通知することを特徴とする請求項１４に記載のバインディングキャッシュ生成方法。
  28. 　前記モバイルノードが、前記ホームドメインから外部ドメインにローミングした場合に、前記ホームエージェントに対して、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成する要求を前記外部ドメインを経由して通知することを特徴とする請求項１５に記載のバインディングキャッシュ生成方法。
  29. 　前記モバイルノードが、前記ホームドメインから外部ドメインにローミングした場合に、前記ホームエージェントに対して、前記第２のインタフェース用のクライアントベースのバインディングキャッシュを生成する要求を前記外部ドメインを経由して通知することを特徴とする請求項１６に記載のバインディングキャッシュ生成方法。
PCT/JP2009/002637 2008-06-16 2009-06-11 バインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノード WO2009153943A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/997,951 US20110103260A1 (en) 2008-06-16 2009-06-11 Binding cache creating method, binding cache creating system, home agent, and mobile node
JP2010517703A JPWO2009153943A1 (ja) 2008-06-16 2009-06-11 バインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノード

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2008156487 2008-06-16
JP2008-156487 2008-06-16
JP2009-069493 2009-03-23
JP2009069493 2009-03-23

Publications (1)

Publication Number Publication Date
WO2009153943A1 true WO2009153943A1 (ja) 2009-12-23

Family

ID=41433867

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/002637 WO2009153943A1 (ja) 2008-06-16 2009-06-11 バインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノード

Country Status (3)

Country Link
US (1) US20110103260A1 (ja)
JP (1) JPWO2009153943A1 (ja)
WO (1) WO2009153943A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012253495A (ja) * 2011-06-01 2012-12-20 Kddi Corp プロキシモバイルＩＰｖ６におけるハンドオーバ方法
JP2013520899A (ja) * 2010-02-23 2013-06-06 アルカテル−ルーセント ユーザ機器と３ｇｐｐ発展型パケット・コアとの間でのマルチホーミング・サービス関連情報の転送
JP2013521732A (ja) * 2010-03-08 2013-06-10 ゼットティーイー コーポレーション 無線通信システムにおける端末切替の方法及びシステム

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8681739B1 (en) * 2008-08-06 2014-03-25 Marvell International Ltd. Method and apparatus for supporting multiple connections over different types of access in 3GPP systems
US10512112B1 (en) 2008-08-06 2019-12-17 Marvell International Ltd. Method and apparatus for supporting multiple connections over different types of access in 3GPP systems
US9210125B1 (en) * 2008-10-17 2015-12-08 Honeywell International Inc. System, method and apparatus for binding communication devices through common association
US20120179803A1 (en) * 2009-07-03 2012-07-12 Telemaco Melia Enhancing network-based ip mobility management protocol to provide multihoming support
US9295089B2 (en) * 2010-09-07 2016-03-22 Interdigital Patent Holdings, Inc. Bandwidth management, aggregation and internet protocol flow mobility across multiple-access technologies
US8942193B2 (en) * 2011-04-08 2015-01-27 Blackberry Limited Routing different subsets of an internet protocol flow over different points of attachment
TW201246879A (en) 2011-04-13 2012-11-16 Interdigital Patent Holdings Methods, systems and apparatus for managing and/or enforcing policies for managing internet protocol (''IP'') traffic among multiple accesses of a network
US10091028B2 (en) * 2011-08-17 2018-10-02 Nicira, Inc. Hierarchical controller clusters for interconnecting two or more logical datapath sets
US8953559B2 (en) * 2011-10-24 2015-02-10 Electronics And Telecommunications Research Institute Method and apparatus for supporting network-based flow mobility
EP2611228A1 (en) * 2011-12-27 2013-07-03 Alcatel Lucent Allowing access to services delivered by a service delivery platform in a 3GPP HPLM, to an user equipment connected over a trusted non-3GPP access network
US9807644B2 (en) 2012-02-17 2017-10-31 Interdigital Patent Holdings, Inc. Hierarchical traffic differentiation to handle congestion and/or manage user quality of experience
FR2987540B1 (fr) * 2012-02-28 2016-05-13 Commissariat Energie Atomique Methode et systeme de gestion de la mobilite d'un reseau mobile
CN103369630B (zh) * 2012-03-30 2017-02-15 华为终端有限公司 Ap响应方法、发现ap的方法、ap及终端
CN103517254B (zh) * 2012-06-27 2018-09-04 中兴通讯股份有限公司 多接入点连接处理方法及装置
US9585054B2 (en) 2012-07-19 2017-02-28 Interdigital Patent Holdings, Inc. Method and apparatus for detecting and managing user plane congestion
CN103686671B (zh) * 2012-09-14 2019-01-18 中兴通讯股份有限公司 一种通知接入网位置信息的方法和系统
WO2014110410A1 (en) 2013-01-11 2014-07-17 Interdigital Patent Holdings, Inc. User-plane congestion management
US9743334B2 (en) * 2013-02-11 2017-08-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for enabling data path selection in a virtual home gateway
US9338750B2 (en) 2013-06-13 2016-05-10 Qualcomm Incorporated Dynamic power management scheme in wireless networks based on power over ethernet (POE)
WO2015176319A1 (zh) * 2014-05-23 2015-11-26 华为技术有限公司 一种绑定注册和数据转发方法、相关设备及网络系统
KR20160014382A (ko) * 2014-07-29 2016-02-11 삼성전자주식회사 무선 통신 시스템에서 앵커 게이트웨이를 변경하기 위한 장치 및 방법
US20170310584A1 (en) * 2014-10-06 2017-10-26 Lg Electronics Inc. Routing rule updating method and user device for moving specific ip flow to specific access
WO2017014759A1 (en) * 2015-07-21 2017-01-26 Nokia Technologies Oy Localized routing in mobile networks
US11265294B2 (en) 2015-09-15 2022-03-01 Telefonaktiebolaget Lm Ericsson (Publ) Method for secure WiFi calling connectivity over managed public WLAN access
US11258694B2 (en) * 2017-01-04 2022-02-22 Cisco Technology, Inc. Providing dynamic routing updates in field area network deployment using Internet Key Exchange v2
US10742775B2 (en) 2017-07-11 2020-08-11 Futurewei Technologies, Inc. Supporting internet protocol version 4 (IPv4) extension headers

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009044539A1 (ja) * 2007-10-05 2009-04-09 Panasonic Corporation 通信制御方法及びネットワークノード並びに移動端末

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040142657A1 (en) * 2003-01-21 2004-07-22 Masahiro Maeda Location registration using multiple care of addresses
US7539159B2 (en) * 2004-04-07 2009-05-26 Nokia Corporation Maintaining reachability of a mobile node
JP4438510B2 (ja) * 2004-05-25 2010-03-24 株式会社日立製作所 通信システム及び通信制御装置
US7272123B2 (en) * 2004-09-13 2007-09-18 Nextel Communications, Inc. System and method for handoff processing
GB2422515B (en) * 2005-01-21 2009-05-27 King S College London A method of discovering multi-mode mobile terminals
FI20055091A0 (fi) * 2005-02-24 2005-02-24 Nokia Corp Paikallismobiliteetin hallinta mobiilisissa Internetprotokollaverkossa
US8050217B2 (en) * 2005-03-04 2011-11-01 Panasonic Corporation Communication node and communication control method
JP4546858B2 (ja) * 2005-03-16 2010-09-22 富士通株式会社 モバイル通信におけるＱｏＳ設定方法及びＱｏＳ設定システム並びに該システムに用いる移動端末装置、ホームエージェント、サーバ装置
EP1739893A1 (en) * 2005-06-30 2007-01-03 Matsushita Electric Industrial Co., Ltd. Optimized reverse tunnelling for packet switched mobile communication systems
WO2007049459A1 (ja) * 2005-10-25 2007-05-03 Nec Corporation 階層化移動管理システム、アクセスルータ、アンカーノード、移動通信システムおよび経路設定方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009044539A1 (ja) * 2007-10-05 2009-04-09 Panasonic Corporation 通信制御方法及びネットワークノード並びに移動端末

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
R. WAKIKAWA ET AL.: "Multiple Care-of Addresses Registration, the Internet Engineering Task Force", MEXT WORKING GROUP INTERNET-DRAFT, DRAFT-IETF-MONAMI6-MULTIPLECOA-08.TXT, 30 May 2008 (2008-05-30) *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013520899A (ja) * 2010-02-23 2013-06-06 アルカテル−ルーセント ユーザ機器と３ｇｐｐ発展型パケット・コアとの間でのマルチホーミング・サービス関連情報の転送
US10517058B2 (en) 2010-02-23 2019-12-24 Alcatel Lucent Transport of multihoming service related information between user equipment and 3GPP evolved packet core
JP2013521732A (ja) * 2010-03-08 2013-06-10 ゼットティーイー コーポレーション 無線通信システムにおける端末切替の方法及びシステム
US9301229B2 (en) 2010-03-08 2016-03-29 Zte Corporation Method and system for terminal handover in wireless communication system
JP2012253495A (ja) * 2011-06-01 2012-12-20 Kddi Corp プロキシモバイルＩＰｖ６におけるハンドオーバ方法

Also Published As

Publication number Publication date
US20110103260A1 (en) 2011-05-05
JPWO2009153943A1 (ja) 2011-11-24

Similar Documents

Publication Publication Date Title
WO2009153943A1 (ja) バインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノード
US8774039B2 (en) Communication system, mobile terminal, network node, and base station apparatus
CN101268670B (zh) 能同时使用归属网络和外部网络的多归属移动节点、归属代理及其方法
US8792453B2 (en) Secure tunnel establishment upon attachment or handover to an access network
WO2010041440A1 (ja) インタフェース切換システム、モバイルノード、代理ノード及び移動管理ノード
JP4579905B2 (ja) 分配された移動体エージェント
JPWO2009044539A1 (ja) 通信制御方法及びネットワークノード並びに移動端末
WO2009116246A1 (ja) 通信方法、通信システム、モバイルノード及びアクセスルータ
US20120106554A1 (en) Redirection method, redirection system, mobile node, home agent, and proxy node
JPWO2009066438A1 (ja) アドレス割り当て方法、アドレス割り当てシステム、モバイルノード及び代理ノード
US8824353B2 (en) Mobility route optimization in a network having distributed local mobility anchors
US8223725B2 (en) Telecommunications
KR101084138B1 (ko) Ｍａｐ 도메인 간 핸드오버 수행 방법
WO2010010693A1 (ja) 垂直ハンドオフ方法、垂直ハンドオフシステム、ホームエージェント及びモバイルノード
KR20090054145A (ko) 네트워크 기반의 고속 핸드오버 수행 방법
WO2010146815A1 (ja) 移動管理プロトコル選択方法、移動管理プロトコル選択システム、モバイルノード、ホームエージェント及び代理ノード
Jia PMIPv6 route optimization for inter-and intra-domain roaming using signaling reduction approach in LTE networks
Sharmin Afroze et al. Study Of Proxy Mobile IPv6
Isah et al. An ILNP-Based Solution for Future Heterogeneous Wireless Networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09766391

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010517703

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 12997951

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09766391

Country of ref document: EP

Kind code of ref document: A1