WO2009116276A1

WO2009116276A1 - Communication method, communication system, communication node, mobile communication device, mobile management device, and relay node

Info

Publication number: WO2009116276A1
Application number: PCT/JP2009/001200
Authority: WO
Inventors: 阿相啓吾; リムチュンキョンベンジャミン; ンーチャンワー; コーティエンミンベンジャミン
Original assignee: パナソニック株式会社
Priority date: 2008-03-19
Filing date: 2009-03-18
Publication date: 2009-09-24

Abstract

Disclosed is a technique for setting a correspondence between an arbitrary IP address and a report purpose when an IP address is transmitted as a report content of a report message between nodes. According to the technique, upon reception of a report trigger message (40) from an MN (101), an HA (102) sets an address meaning list (50) obtained by mapping correspondence of the IP address with the report content, between the HA (102) and the MN (101). When transmitting a report content set in the address meaning list (50), the HA (102) sets the IP address set in the address meaning list (50) as a destination address of a packet destined to the MN (101). The MN (101) decrypts the report content from the destination address of the packet.

Description

Communication method, communication system, communication node, mobile communication device, mobility management device, and relay node

The present invention relates to a communication method, a communication system, and a communication node that transmit using an IP address as a notification content of a notification message.
The present invention also relates to a mobile communication device and a mobility management device in the communication system.
The present invention also relates to a communication method, a communication system, a mobile communication device, a mobility management device, and a relay node in which a mobile communication device instructs a transfer destination interface of a flow addressed to the mobile communication device to a mobility management device and / or a relay node.

According to Mobile IPv6 (also referred to as MIPv6, CMIP) in Non-Patent Document 1 below, a mobile node can permanently maintain one Internet Protocol (IP) address even if the connection point to the Internet is changed. it can. This permanent IP address in MIPv6 is the address in the mobile node's home network domain and is known as the home address. When the mobile node is connected to the external network domain, the IP address used in the external network domain can be configured from a prefix advertised from the external network domain. The IP address configured in this way is called a care-of address, and the care-of address can be the destination of the mobile node.

The mobile node binds its care-of address to its home address to its home agent in order to maintain reachability regardless of its location. The home agent in MIPv6 is a router in the home network that registers the current care-of address of the mobile node. This binding can be realized by the mobile node sending a binding update (BU) message to the home agent. When the mobile node moves out of the home network, the home agent intercepts the packet addressed to the mobile node's home address and tunnels the packet to the care-of address. According to MIPv6, the host is included in the mobility management domain. For this reason, MIPv6 is known as a host-based mobility management protocol.

Here, when a plurality of network interfaces are introduced into the mobile node, the mobile node and the router can register a plurality of care-of addresses with respect to the home address. This registration method is known as MCoA (Multiple Care-of Addresses Registration) within the IETF working group. In the following Non-Patent Document 2, the registration of a plurality of care-of addresses is realized by using an identification number called BID (Binding Unique Identification) in order to distinguish a plurality of bindings to a home address. This BID is assigned to an interface or care-of address and is bound to one home address of the mobile node and router.

Thus, the home address is associated with the mobile node and the router, while the BID identifies each of a plurality of bindings registered simultaneously by the mobile node. The mobile node and the router use a binding update (BU) message to notify the home agent of this BID. The home agent records this BID in the binding cache. Further, as other conventional techniques, the following Non-Patent Documents 3, 4, 5, 6, 7 and Patent Documents 1, 2, 3, 4 are known.
D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00., June 12, 2006. T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", Internet Engineering Task Force Request for Comments 2461, December, 1998. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-00., April 08, 2007. H. Soliman, N. Montavont, N. Fikouras and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-soliman-monami6-flow-binding-05, November 19, 2007. J. Rajahalme, A. Conta, B. Carpenter and S. Deering, "IPv6 Flow Label Specification", Internet Engineering Task Force Request For Comments 3697, March 2004. T. Aura, "Cryptographically Generated Addresses (CGA)", Internet Engineering Task Force Request For Comments 3972, March 2005. K. Feyerabend, "Facilitating data transmission", US Patent Number 7,123,626, October 17, 2006. J. Leichter and S. Desimone, "Implementing managed network services for customers with duplicate IP networks", US Patent Application Publication Number 2002 / 0165982A1, November 7, 2002. A. Santharam, F. Weaver, P. Jethwa, D. Haldar and L. Bertz, "Method for managing SIP registrations in a telecommunications network", US Patent Number 7,395,336, July 1, 2008. Not constitute) R. Ludwig, NS. Lundin and P. Johnsen, "Method and system for dynamically configuring a traffic flow template", WO Patent Application Publication Number WO 2007/129199 A2, November 15, 2007.

Hereinafter, problems to be solved by the present invention will be described. FIG. 10 shows a state in which the mobile node (MN) 101 roams from the home network domain 10 to the external network domain 11 that has a roaming contract relationship with the home network domain 10. In this case, when the MN 101 obtains the prefix of the external network domain 11 from the access router (AR) 111 of the external network domain 11, the care-of address CoA1 used by the interface IF1 of the MN 101 in the external network domain 11 is obtained from this prefix. Generate. Then, the MN 101 transmits a BU message for registering the care-of address CoA1 to the home address HoA in the binding cache of the HA 102 to the home agent (HA) 102 of the home network domain 10.

By this registration, the HA 102 can transmit various option packets for the MN 101 using the care-of address CoA1 as a destination address. In FIG. 10, as an example of the option packet, the source (Scr) address is the address (HA.Addr) of the HA 102, the destination (Dest) address is CoA1, and the option contents are BRR (Binding Refresh Request) and FIO (Flow It indicates that two types of packets (Identification Option) are transmitted. However, this method has a problem that the data amount of option packets transmitted from the HA 102 to the MN 101 becomes very large. As a method of reducing the data amount of the packet, it is conceivable to divide the contents of the option into BRR and FIO and transmit two types of packets (1) and (2). Increase by the header of.

By the way, as an existing technique, an attempt has been made to introduce an IP address for other purposes. For example, as shown in Non-Patent Document 7, it is possible to bind one user to one IP address using public key encryption. This implies that the communication node can know not only the reachability of the packet but also who sent the packet intentionally. With this additional information, the access policy can be validated by using the IP address for the correct access policy with which a particular user is associated. The public key encryption method shown in Non-Patent Document 7 is known as CGA (Cryptographically Generated Addresses).

Also, if an IP address is used to indicate an identifier, it is not necessary to add subscriber information to the packet payload. By this method, it is possible to reduce adding more data to the payload of the packet, and to reduce the total data amount of the transmission packet (Patent Documents 1 and 2).

Patent Documents 1 and 2 describe the advantages of using an IP address to present an identifier. In Patent Document 1, an IP address is used to represent a subscriber identifier. The gateway retrieves the subscriber's identifier by IP address and positions the user so that the user in the communication system can set the forwarding data path to the communication system. Patent Document 1 further describes that when a subscriber has a plurality of identifiers, the plurality of identifiers are represented by IP addresses instead of packet payloads. This method reduces the overhead of the packet being transmitted.

In Patent Document 2, an IP address is used to represent a domain name in the system. In this system, a management entity controls multiple domains. Therefore, the IP address represents the domain name in the system, so that the management entity can know which domain has transmitted the notification to the management entity without describing the domain information in the packet. However, the action taken by the management entity is based on information in the payload of the packet. This implies that the aforementioned problems still exist and that the domain needs to describe multiple information to the management entity.

However, Patent Documents 1 and 2 have a problem in that a correspondence relationship between an arbitrary IP address and a notification purpose cannot be set when an IP address is transmitted between nodes as notification contents of a notification message. In particular, in a system in which a mobile node generates an arbitrary IP address based on an arbitrary prefix acquired from an arbitrary domain, there is a problem in that the correspondence relationship between the IP address and the notification purpose cannot be set. Furthermore, when the mobile node has a plurality of interfaces, there is a problem that an arbitrary IP address cannot be set to represent an interface in addition to the notification contents.

Further, in Patent Document 3, when a network entity (for example, a server) detects that a SIP (Session Initiation Protocol) client has been unexpectedly disconnected from the network, it transmits a SIP notification message to the SIP server. To delete the SIP client subscription registration for the SIP client. However, the SIP notification message includes an option indicating a client identifier (eg, NAI, MN-ID). For this reason, when the network entity needs to describe information about a plurality of subscribers, there is still a problem that the amount of transmission data is large.

Further, Patent Document 4 instructs a mobile node to generate or modify a downlink rule based on how the mobile node transmits an uplink packet to the gateway node to the gateway node. A method is described. In Patent Document 4, the gateway node uses the IP address of the uplink packet as the transfer destination address, and forwards the downlink packet of the same flow type received in the future to the mobile node. For this reason, in Patent Document 4, a mobile node can instruct an action to a gateway node without using a notification option added in a message addressed to the gateway node.

Similarly, as described in Non-Patent Document 5, when the MN 101 is applied to a message for flow routing transmitted to the HA 102, the message includes one or many FID options. Increase size.

In view of the above-described problems of the prior art, the present invention provides a communication method capable of setting a correspondence between an arbitrary IP address and a notification purpose when an IP address is transmitted between nodes as notification contents of a notification message. An object is to provide a communication system, a communication node, a mobile communication device, and a mobility management device.
The present invention is also capable of setting a correspondence relationship between an arbitrary IP address and a notification purpose even in a system that generates an arbitrary IP address based on an arbitrary prefix acquired by the mobile communication device from an arbitrary domain. An object is to provide a communication method, a communication system, a communication node, a mobile communication device, and a mobility management device.
The present invention also provides a communication method, communication system, communication node, and mobile communication that can set an arbitrary IP address to represent an interface in addition to the notification contents even when the mobile communication device has a plurality of interfaces. An object is to provide a device and a mobility management device.
The present invention also provides a communication method, a communication system, and a mobile communication device that can instruct the transfer management interface and / or relay node of a flow transfer destination interface with a small packet size that does not include a flow ID or flow label. An object is to provide a communication device, a mobility management device, and a relay node.

In order to achieve the above object, the communication method of the present invention is a communication method for transmitting from the first communication node to the second communication node using the IP address as the notification content of the notification message.
Setting a correspondence relationship between the IP address and the notification content of the notification message between the first communication node and the second communication node;
When transmitting the set notification content from the first communication node to the second communication node, the set IP address is transferred from the first communication node to the second communication node. Transmitting the packet as a destination address of the packet to be transmitted;
Decoding the set notification content from the destination address of the packet received by the second communication node from the first communication node;
It was set as the structure which has.

In order to achieve the above object, the communication system of the present invention is a communication system that transmits an IP address as a notification content of a notification message from a first communication node to a second communication node.
Means for setting a correspondence relationship between the IP address and the notification content of the notification message between the first communication node and the second communication node;
When transmitting the set notification content from the first communication node to the second communication node, the set IP address is transferred from the first communication node to the second communication node. Means for transmitting the packet as a destination address of the packet to be transmitted;
Means for decoding the set notification content from the destination address of the packet received by the second communication node from the first communication node;
It was set as the structure which has.

In order to achieve the above object, the communication node of the present invention is the first communication node in the communication system that transmits the IP address from the first communication node to the second communication node using the notification content of the notification message. There,
Means for setting a correspondence between the IP address and the notification content of the notification message between the second communication nodes;
When transmitting the set notification content to the second communication node, the set IP address is used as a destination address of a packet to be transmitted from the first communication node to the second communication node. Means for transmitting the packet;
The configuration was provided.

In order to achieve the above object, the communication node of the present invention is the second communication node in the communication system that transmits the IP address from the first communication node to the second communication node using the notification content of the notification message. There,
Means for setting a correspondence relationship between the IP address and the notification content of the notification message with the first communication node;
Means for decoding the set notification content from the destination address of the packet received from the first communication node;
The configuration was provided.
With this configuration, when an IP address is transmitted between nodes as notification content of a notification message, a correspondence relationship between an arbitrary IP address and a notification purpose can be set.

In order to achieve the above object, the communication method of the present invention is a communication method for transmitting an IP address as the notification content of a notification message.
Generating an IP address to be used for notification purposes based on a prefix or prefix length obtained from the domain by the mobile communication device;
An IP address setting step for setting a correspondence relationship between the IP address generated for the notification purpose and the notification content of the notification message between the mobile communication device and the mobility management device;
When transmitting the set notification content from the mobility management device to the mobile communication device, the set IP address is used as a destination address of a packet to be transmitted from the mobility management device to the mobile communication device. Sending a packet;
Decoding the set notification content from the destination address of the packet received by the mobile communication device from the mobility management device;
The configuration was provided.

In order to achieve the above object, the communication system of the present invention is a communication system that transmits using an IP address as the notification content of a notification message.
Means for generating an IP address used for notification purposes based on a prefix or prefix length obtained from a domain by a mobile communication device;
IP address setting means for setting a correspondence relationship between the IP address generated for the notification purpose and the notification content of the notification message between the mobile communication device and the mobility management device;
When transmitting the set notification content from the mobility management device to the mobile communication device, the set IP address is used as a destination address of a packet to be transmitted from the mobility management device to the mobile communication device. Means for transmitting packets;
Means for decoding the set notification content from the destination address of the packet received by the mobile communication device from the mobility management device;
It was set as the structure which has.

In order to achieve the above object, the mobile communication device of the present invention is a mobile communication device in a communication system that transmits using an IP address as notification content of a notification message,
Means for generating an IP address to be used for notification purposes based on a prefix or prefix length obtained from a domain;
IP address setting means for setting a correspondence relationship between the IP address generated for the notification purpose and the notification content of the notification message with the mobility management device of the mobile communication device;
Means for decoding the set notification content from the destination address of the packet received from the mobility management device;
It was set as the structure which has.

In order to achieve the above object, the mobility management device of the present invention is a mobility management device of a mobile communication device in a communication system that transmits using an IP address as a notification content of a notification message,
IP address setting means for setting a correspondence relationship between the IP address generated for the purpose of notification based on a prefix or prefix length by the mobile communication device and the notification content of the notification message with the mobile communication device;
Means for transmitting the packet using the set IP address as a destination address of a packet to be transmitted to the mobile communication device when transmitting the set notification content to the mobile communication device;
It was set as the structure which has.
Further, a policy for reserving an IP address used for the notification purpose is set in advance between the mobile communication device and the mobility management device, and a plurality of IP addresses generated by the mobile communication device based on the policy are set. To select an IP address to be used for the notification purpose.

With this configuration, even in a system that generates an arbitrary IP address based on an arbitrary prefix acquired by a mobile communication device from an arbitrary domain, it is possible to set a correspondence relationship between an arbitrary IP address and a notification purpose.

Further, when the mobile communication device has a plurality of interfaces, the IP address is further set so as to represent an interface to be notified.
The IP address represents an interface on which the notification target interface is sleeping, and an interface that is not sleeping decodes the IP address and returns the sleeping interface from a sleep state. .
With this configuration, even when the mobile communication device has a plurality of interfaces, an arbitrary IP address can be set to represent the interface in addition to the notification contents.

In order to achieve the above object, the communication method of the present invention transfers a packet addressed to the mobile communication device by a mobility management device and / or a relay node of the mobile communication device to a mobile communication device having a plurality of interfaces. In the communication method to
A correspondence relationship between a plurality of flows of packets addressed to the mobile communication device and destination IP addresses at a plurality of interfaces of the mobile communication device is previously determined between the mobile communication device and the mobility management device and / or the relay node. Steps to set,
Requesting the mobile management device and / or relay node to use the correspondence from the mobile communication device;
When the mobility management device and / or the relay node receives the request, a plurality of flows of packets addressed to the mobile communication device are selectively selected as each destination IP address of the mobile communication device based on the correspondence relationship. The step of transferring,
It was set as the structure which has.

In order to achieve the above object, the communication system of the present invention transfers a packet addressed to the mobile communication device by a mobility management device and / or a relay node of the mobile communication device to a mobile communication device having a plurality of interfaces. In a communication system
A correspondence relationship between a plurality of flows of packets addressed to the mobile communication device and destination IP addresses at a plurality of interfaces of the mobile communication device is previously determined between the mobile communication device and the mobility management device and / or the relay node. Means for setting;
Means for requesting the mobile management device and / or the relay node to use the correspondence relationship from the mobile communication device;
When the mobility management device and / or the relay node receives the request, a plurality of flows of packets addressed to the mobile communication device are selectively selected as each destination IP address of the mobile communication device based on the correspondence relationship. Means to transfer,
It was set as the structure which has.

In order to achieve the above object, the mobile communication device of the present invention provides a mobile management device and / or a relay node of the mobile communication device to a packet addressed to the mobile communication device with respect to a mobile communication device having a plurality of interfaces. The mobile communication device in a communication system to transfer,
Means for setting in advance correspondence between a plurality of flows of packets addressed to the mobile communication device and each destination IP address in a plurality of interfaces of the mobile communication device between the mobile management device and / or the relay node;
Means for requesting the mobility management device and / or the relay node to use the correspondence relationship;
It was set as the structure which has.

In order to achieve the above object, the mobility management device of the present invention is a communication system in which the mobility management device of the mobile communication device transfers packets addressed to the mobile communication device to a mobile communication device having a plurality of interfaces. The mobility management device,
Means for setting in advance a correspondence relationship between a plurality of flows of packets addressed to the mobile communication device and each destination IP address in a plurality of interfaces of the mobile communication device with the mobile communication device;
When a request is received from the mobile communication device to use the correspondence relationship, a plurality of flows of packets destined for the mobile communication device are selectively transmitted to each destination IP address of the mobile communication device based on the correspondence relationship. Means to transfer,
It was set as the structure which has.

In order to achieve the above object, the relay node of the present invention transfers a packet addressed to the mobile communication device by the mobility management device and / or the relay node of the mobile communication device to a mobile communication device having a plurality of interfaces. The relay node in a communication system that comprises:
Means for setting in advance a correspondence relationship between a plurality of flows of packets addressed to the mobile communication device and each destination IP address in a plurality of interfaces of the mobile communication device with the mobile communication device;
When a request is received from the mobile communication device to use the correspondence relationship, a plurality of flows of packets destined for the mobile communication device are selectively transmitted to each destination IP address of the mobile communication device based on the correspondence relationship. Means to transfer,
It was set as the structure which has.

With the above configuration, the mobile communication device can instruct the mobility management device and / or the relay node of the flow transfer destination interface with a small packet size not including the flow ID or flow label. *

According to the present invention, when an IP address is transmitted between nodes as notification contents of a notification message, a correspondence relationship between an arbitrary IP address and a notification purpose can be set.
Further, even in a system in which a mobile communication device generates an arbitrary IP address based on an arbitrary prefix acquired from an arbitrary domain, a correspondence relationship between the arbitrary IP address and the notification purpose can be set.
Further, even when the mobile communication device has a plurality of interfaces, an arbitrary IP address can be set to represent the interface in addition to the notification contents.
In addition, the mobile communication device can instruct the mobility management device and / or the relay node of the flow transfer destination interface with a small packet size that does not include the flow ID or flow label.

The block diagram which shows 1st Embodiment of the communication system which concerns on this invention. Explanatory diagram showing the format of the notification packet The block diagram which shows the functional structure of the mobile node of FIG. Explanatory drawing which shows the format of the notification trigger message in 1st Embodiment Explanatory drawing which shows the structure of the address meaning list in 1st Embodiment The flowchart for demonstrating the address semantic list structure process of the home agent in 1st Embodiment The flowchart for demonstrating the IP address decoding process of the mobile node in 1st Embodiment Explanatory drawing which shows the format of the notification trigger message in 7th Embodiment Explanatory drawing which shows the structure of the address meaning list | wrist in 7th Embodiment Explanatory drawing which shows the problem which this invention tends to solve Block diagram illustrating a communication system in which an external network domain has a network-based mobility management function Explanatory drawing which shows the communication sequence in 11th Embodiment Explanatory drawing which shows the format of the notification trigger message in 12th Embodiment Explanatory drawing which shows the meaning of the option type of FIG. Explanatory drawing which shows the format of the encapsulated packet in 13th Embodiment

Embodiments of the present invention will be described below with reference to the drawings.
<First Embodiment>
FIG. 1 is a block diagram showing a communication system that provides a host-based mobility management function to an MN 101 having a plurality of interfaces (IF) 1010 and 1011 as a first embodiment of a communication system according to the present invention. . Here, as indicated by a broken line in the initial state, the MN 101 is located in the home network domain 10 and is a counterpart communication node (CN: Correspondent Node) 130, which is a home agent (HA) 102 and a global communication domain 12. It is assumed that the user has a communication session with the home address via. Further, it is assumed that the MN 101 roams beyond the global communication domain 12 by MIPv6 and can continue to communicate with the CN 130. During this roaming, the MN 101 binds the current care-of address to the home address in the HA 102 in the home network domain 10.

When the MN 101 roams to the external network domain 11, the first IF 1010 of the MN 101 is assumed to associate with the first AR 111 of the external network domain 11. At this time, the IF 1010 acquires information on the external network domain 11 from the AR 111 and generates a care-of address (MN.CoA1) used by the IF 1010 in the external network domain 11. Here, this address generation can be realized by using automatic address generation described in Non-Patent Document 3. In the method according to Non-Patent Document 3, the IF 1010 can acquire a prefix in the AR 111 and generate a care-of address (MN.CoA1). The MN 101 binds the care-of address (MN.CoA1) to the home address of the MN 101 in the HA 102. Note that the home network domain 10 and the external network domain 11 do not necessarily have to be via the global communication domain 12, but may be directly connected via a gateway or the like.

Note that the system described in FIG. 1 is assumed to be a 3GPP-LTE (the Third Generation Generation Partnership Project (Long Term Term Evolution)) SAE (System Architecture Architecture Evolution) project. When the relationship between the system shown in FIG. 1 and the SAE is matched, the HA 102 is a PDN-GW (Packet Data Network Gateway) existing in the 3GPP network, and the

ARs

111 and 112 are S-GW (Serving Gateway) or ePDG. (Evolved Packet Data Gateway) and AGW (Access Gateway) existing in a Non3GPP network (non-3GPP network), and MN101 is a UE (User Equipment). Further, the external network domain 11 can be regarded as a non-3GPP network managed by the home network domain 10 or the external network domain 11. In that case, the home network domain 11 which is a 3GPP network is connected to the Non3GPP network via the ePDG. The two interfaces of the MN 101 (UE) in FIG. 1 are a 3GPP interface and a Non3GPP interface (WLAN or WiMAX (Worldwide Interoperability for Microwave Access)), and the IF 1010 is connected to a 3GPP network (in FIG. 1, the home network domain). The IF 1011 may be connected to a Non3GPP network (in FIG. 1, an external network domain). In this case, the 3GPP network uses GTP (Generic Tunnelling Protocol) or PMIP (PMIP: Proxy Mobile IP) to connect to the HA 102, and the Non3GPP network uses the mobile IP to connect to the HA 102.

Here, assuming that the second IF 1011 of the MN 101 associates with the second AR 112 of the external network domain 11, the second IF 1011 similarly acquires the information of the external network domain 11 from the second AR 112. Thus, the second IF 1011 generates a care-of address (MN.CoA2) used in the external network domain 11. Then, the MN 101 binds the care-of address (MN.CoA2) to the home address of the MN 101 in the HA 102. For this reason, the HA 102 can link two routing paths to the home address of the MN 101. The first is a routing path that passes through the first AR 111 using the care-of address (MN.CoA1), and the second is that that passes through the second AR 112 using the care-of address (MN.CoA2). Routing path to be

As another form of mobility management, there is a form in which the mobile node is released from mobility related to signaling when the mobile node roams in the mobility domain. In this form, as shown in Non-Patent Document 4, a proxy entity in the mobility domain helps mobility management of the mobile node. Such mobility management is called network-based mobility management (PMIP).

Referring to FIG. 1, when the network-based mobility management is provided in the external network domain 11, the

ARs

111 and 112 located in the external network domain 11 are connected to the proxy of the MN 101 in the external network domain 11.・ Operates as an entity. When the MN 101 roams to the external network domain 11, the first IF 1010 associates with the first AR 111. This association procedure is performed by the MN 101 presenting its own identifier (MN-ID) to the first AR 111 as part of the access authentication procedure. This MN-ID is typically used to associate with the policy profile of the MN 101 that can be obtained from the local server (LS) 13. The policy profile of the MN 101 includes the characteristics of the network-based mobility service and other related parameters such as the network prefix assigned to the mobile node (MN.Home.Prefix), the allowed address configuration mode, Includes roaming policies and other parameters essential for providing network-based mobility services.

The AR 111 that is the proxy entity of the MN 101 acquires the policy profile of the MN 101 from the LS 13 after the access authentication of the MN 101 is successful. This means that the AR 111 has all the information necessary to perform the mobility service for the MN 101. For this reason, the AR 111 periodically transmits a router advertisement message for advertising a prefix assigned to the MN 101. The MN 101 configures the IP address (care-of address) of the IF 1010 connected to the external network domain 11 from the prefix. Wherever the MN 101 moves within the external network domain 11, the IF 1010 always refers to the same prefix. This is because the AR 111 to which the MN 101 is connected always accesses the LS 13 and acquires the profile of the MN 101. For this reason, regardless of the position of the MN 101 in the external network domain 11, the MN 101 can always use the IP address configured first.

Here, an entity called a local mobility anchor acts as a geographical anchor point for each mobile node for routing within a domain with network-based mobility management. In addition, the local mobility anchor further manages the reachability state of each mobile node. Therefore, the local mobility anchor has a certain similarity with the home agent described in Non-Patent Document 1. The local mobility anchor needs to be updated with the current location of each mobile node to become the anchor point for each mobile node. For this reason, whenever the MN 101 is connected to the AR 111, the AR 111 transmits a proxy BU (PBU) message to the HA 102. By this PBU message, the unique identifier (MN-ID) of the MN 101 is bound to the care-of address of the AR 111. With this binding, the HA 102 can route a packet addressed to the MN 101 via the appropriate AR 111.

Further, while the MN 101 is located in the external network domain 11 that supports network-based mobility management, the MN 101 configures a plurality of care-of addresses using prefixes assigned by the external network domain 11, and The multiple care-of addresses can be bound at the HA 102 for routing. As a method of binding the plurality of care-of addresses, the method described in Non-Patent Document 2 can be used.

From the above, it can be seen that the purpose of the IP address is mostly used for packet routing. In order for the second communication node to be able to receive packets from the first communication nodes that communicate with each other, the second communication node transmits the IP address being used to the first communication node. There must be. In order to support packet routing from the first communication node to the second communication node, the intermediate node uses the IP address described in the packet to establish a routing path to the target communication node. To construct. The purpose of this IP address is only for the communication node to know if the packet can be transmitted.

Conventionally, since the first communication node notifies the second communication node of its intention, the first communication node describes the intention in a payload in the packet 20 transmitted to the second communication node. . FIG. 2 shows a general format of the notification packet. The notification packet 20 includes a packet header 21 and fields of a notification option 22 indicated by a broken line as a payload. The packet header 21 includes a message transmission source configured by an IPv4 or IPv6 address, a type field indicating a message type, and a message length field. The source address 210 and the destination address 211 in FIG. 2 are IP addresses, both 4 bytes for IPv4 and 16 bytes for IPv6.

The notification option 22 indicated by a broken line includes information necessary for executing an action with a communication node. The notification option 22 in FIG. 2 is composed of 1-byte option type 220 and option length 221, and option data 222 fields. The length of the option data 222 usually depends on the data amount of information.

Hereinafter, a first conventional use example of the notification packet 20 will be described in detail. In FIG. 1, the HA 102 manages a plurality of traffic flows destined for the MN 101. Assume that some of the plurality of traffic flows are assigned routing preferences by the MN 101. Suppose that the HA 102 wants to check the routing preference update for the MN 101. For this reason, the HA 102 transmits a notification packet 20 to the MN 101. The notification option 22 of the notification packet 20 includes information indicating that the MN 101 is notified to update the routing preference of the MN 101 in the HA 102. Upon receiving the notification packet 20, the MN 101 triggers an internal function according to the notification option 22 and transmits a filter update message to the HA 102.

Hereinafter, a second conventional usage example of the notification packet 20 will be described. The HA 102 notifies the MN 101 to recover the second IF 1011 that is sleeping in the MN 101 and obtain some information from the IF 1011. Therefore, the HA 102 transmits the notification packet 20 including the BID used to represent the second IF 1011 in the notification option 22 to the MN 101 via the first IF 1010. By the notification option 22 of the notification packet 20, the MN 101 knows that the HA 102 needs information from the second IF 1011, returns the second IF 1011 from the sleep state, and receives necessary information from the second IF 1011. Is transmitted to the HA 102. The second usage example is different from the first usage example. The notification option 22 of the notification packet 20 in the second usage example is used to target a specific interface of the MN 101, whereas the first usage example is different from the first usage example. The notification option 22 of the notification packet 20 in the usage example is used to target the application of the MN 101.

Furthermore, when the notification message includes a plurality of instructions instead of one, the packet size of the message increases. For example, when the HA 102 requests the MN 101 to selectively update the filter in the HA 102, this notification includes the identifier of the selected filter in order to inform the MN 101 which filter needs to be updated. Must be included in the notification option 22. Similarly, when HA 102 requests MN 101 to select a routing interface and refresh the binding, this notification is selected to inform MN 101 which binding needs to be refreshed. The BID must be included in the notification option 22. When information is added to the notification option 22 in this way, the size of the notification packet 20 transmitted from the HA 102 to the MN 101 increases.

Also, such a large packet 20 may be discarded when routed to the MN 102. The reason is that such a large packet 20 overflows in the buffer of the router on the way and is discarded. Here, by dividing such a large packet 20 into a plurality of small manageable packets, it is possible to reduce the possibility of being overflowed and discarded in the buffer of the router in the middle. For example, instead of transmitting the notification packet 20 in which the identifiers of all the selected filters are described in the notification option 22 to the MN 102, the HA 102 transmits the identifier of each filter to the MN 102 using the notification option 22 of each notification packet 20. Thereby, the large packet 20 can be divided into a plurality of small packets 20 that can be managed. However, in this case, since each packet 20 requires a packet header 21, the overhead used to transmit a plurality of notification packets 20 increases. When both are compared, the total size of the plurality of packets 20 to which the packet header 21 is added is larger than when one large packet 20 is transmitted.

<Outline of the present invention>
In the present invention, when an IP address is used as means for transmitting a notification message to a communication node, the correspondence between the IP address and the notification content of the notification message is negotiated and set between the communication nodes. As an advantage of using the IP address, it is possible to eliminate the necessity of describing the notification information in the payload of the packet 20. For this reason, it is possible to secure a degree of freedom of space for more meaningful data, for example, data from a communication session initiated by a subscriber. Thereby, the notification option 22 indicated by a broken line in FIG. 2 can be omitted, and at least 2 bytes can be saved from the packet 20.

To realize this method, the MN 101 first needs to notify the HA 102 that the IP address is used in the form of a notification message. This type of information sent to the HA 102 includes a plurality of IP addresses and a prefix or prefix length used in constructing one IP address. With this information as a trigger, the IP address does not mean routing but constitutes a certain meaning. For example, a specific IP address can mean requesting the MN 101 to update the binding in the HA 102. The method of mapping a specific IP address to a specific notification message may be static (for example, using a predetermined policy) or dynamic (for example, by message exchange between communication nodes). Once an IP address is mapped to a notification purpose, it can be used for the notification purpose. For this reason, this means that the HA 102 can notify the MN 101 of taking a predetermined action using the IP address.

<Functional configuration of MN>
FIG. 3 shows a functional configuration of the MN 101, and the MN 101 has a network interface 300, an application unit 301, an address policy database 302, and an address checking engine 303. The network interface 300 is a functional block having necessary hardware and software for communicating with other nodes via a certain communication medium. Using terminology known in the related art, the network interface 300 represents layer 1 (physical layer) and layer 2 (data link layer) communication components, firmware, drivers and profiles. Those skilled in the art will appreciate that the MN 101 includes one or more network interfaces 300. A trigger signal and a packet can be exchanged between the network interface 300 and the address checking engine 303 via the signal / data path 304. For example, the address checking engine 303 can execute an action by transferring a packet received by the network interface 300 to the address checking engine 303 via the signal / data path 304. The action of the address checking engine 303 will be described later.

The application unit 301 is a functional block having all protocols and programs above the network layer in the communication stack. These protocols and programs are necessary for communicating with other nodes such as transport layer and session layer protocols such as TCP (Transmission Control Protocol), SCTP (Stream Control Transmission Protocol) and UDP (User Datagram Protocol). Programs and software. It is obvious for those skilled in the art that the application unit 301 may have one or a plurality of applications. A trigger signal and a packet can be exchanged between the application unit 301 and the network interface 300 through the signal / data path 307. For example, the application unit 301 can route the packet of the MN 101 to a target destination by transferring the packet to the network interface 300 via the signal / data path 307.

The address policy database 302 stores information necessary for the MN 101. In the present embodiment, the database 302 stores a list of IP addresses used for notification purposes. However, it is not limited to this. A signal / data path 306 allows trigger signals and packets to be exchanged between the database 302 and the address checking engine 303. For example, the address checking engine 303 can query the IP address list of the database 302 via the signal / data path 306.

In the present invention, by introducing the address checking engine 303, the IP address used in the destination address 211 in the received packet 20 is checked, and which notification purpose the IP address means decide. As a result of the check, if the IP address of the destination address 211 means that an action of the MN 101 is triggered, the address checking engine 303 triggers an appropriate application of the application unit 301 to execute this action. To do. For example, the address checking engine 303 requests the MN 101 to update the packet filtering rule (also called a routing rule) in the HA 102 when the IP address used in the destination address 211 in the received packet 20 is In the case of an existing IP address, a command to that effect is sent to the packet filtering rule application of the application unit 301. A trigger signal and a packet can be exchanged between the address checking engine 303 and the application unit 301 through the signal / data path 305. For example, the address checking engine 303 requests the application unit 301 to execute an action corresponding to the received notification via the signal / data path 305.

<Notification trigger message>
In order for the MN 101 and the HA 102 to send a notification message using an IP address, the MN 101 must first trigger to initiate its action. In order to trigger, the MN 101 transmits a notification trigger message 40 as shown in FIG. The notification trigger message 40 can preferably be transmitted together with a binding update (BU) message that the MN 101 transmits to the HA 102. When the HA 102 receives the notification trigger message 40, it knows that the MN 101 wants to represent the notification using the IP address.

The format of the notification trigger message 40 will be described with reference to FIG. The notification trigger message 40 includes fields of a packet header 41, a mobile node identifier (MN-ID) 42, a prefix 43, and a flag 44. The packet header 41 is composed of a message transmission source constituted by an IPv4 or IPv6 address, and fields of a message type and a message length. The HA 102 can identify which mobile node has transmitted the message 40 by the MN-ID 42. The prefix 43 includes one or more prefixes that can be used by the MN 101. The prefix 43 preferably includes a prefix assigned to the MN 101 in the external network domain 11.

The MN 101 uses the flag 44 to instruct the HA 102 that the notification is to be expressed using the IP address. The flag 44 can be represented by one bit as a new mobility option. For example, '0' indicates that notification is not desired using the IP address, and '1' indicates that notification is desired using the IP address.

Hereinafter, a usage example of the notification trigger message 40 will be described in detail. In FIG. 1, it is assumed that the first IF 1010 of the MN 101 associates with the first AR 111 and is assigned a prefix (MN101.Prefix) used for communication in the external network domain 11. It is assumed that the MN 101 decides to represent the notification using the IP address, and sends a notification trigger message 40 with the flag 44 set to “1” to the HA 102. Preferably, the notification trigger message 40 is transmitted by a BU message. When the HA 102 receives the notification trigger message 40, it understands that the MN 101 wants to represent the notification using the IP address.

Further, when the HA 102 receives the notification trigger message 40, it is necessary to generate a list in which the IP address and the meaning of the notification are mapped. Hereinafter, this list is referred to as an “address semantic list”. FIG. 5 shows an address meaning list 50. The address semantic list 50 may preferably be provided for all entities (eg, MN 101,

AR

111, 112, HA 102). The address semantic list 50 shown in FIG. 5 includes a care-of address (CoA) 51 that is an IP address and a notification purpose (mobility header type) 52 as entries, but is not limited thereto. The

entries

51 and 52 constitute a mapping in which the IP address is associated with its meaning.

If this IP address is used by this mapping, an action for one or a plurality of communication nodes is instructed. For example, the HA 102 generates an address meaning list 50 including mapping as shown in FIG. MN. CoA0 is mapped to mean that the HA 102 transmits a binding-refresh request message to the MN 101. Here, the MN 101 is triggered by the binding / refresh request message to refresh all the bindings of the MN 101 in the HA 102. Therefore, the MN 101 sends an MN. When receiving the packet 20 in which CoA0 is set, the HA 102 knows that it has requested to refresh all the bindings of the MN 101 in the HA 102, and sends a BU message describing all the bindings that the MN 101 currently has to the HA 102. To do.

Also, in the example shown in FIG. CoA3 means that the HA 102 transmits a home test start (Home Test Init: HoTi) request message to the MN 101. CoA5 means that the HA 102 transmits a routing preference update request message to the MN 101. The notification purpose is not limited to this as long as the action is notified by the HA 102 to the MN 101. Further, the action does not necessarily have to be accompanied by a message transmission to the HA 102, and may be used as a trigger for causing a process to be completed within the MN 101. For example, instead of sending a BA message that is a response to the BU message sent by the MN 101, a packet encapsulated using a CoA that means that the BU has been correctly registered or a CoA that means that registration is impossible is sent to the MN 101. May be. Although not shown, when it is not necessary to notify the MN 101 in particular, the CoA registered in the normal HA 102 is used as the default CoA.

FIG. 6 is a flowchart showing a process in which the HA 102 configures the address meaning list 50. The process shown in FIG. 6 starts when the HA 102 receives the notification trigger message 40 from the MN 101 (step S60). The notification trigger message 40 may include information necessary to support the HA 102 using the IP address for notification purposes, if possible. Examples of the information are an address semantic list, one or more prefixes, and one or more prefix lengths. When the HA 102 receives the notification trigger message 40, the HA 102 checks whether or not there is a policy in the HA 102 when the IP address has been previously configured for the purpose of notification (step S61).

If it exists, the address semantic list 50 is constructed using the policy (step S62). When the address meaning list 50 is configured, this process is terminated (step S66), and the IP address is used when a notification message is transmitted to the MN 101. As an option, the HA 102 can forward the newly configured address semantic list 50 to the MN 101. This is because the HA 102 and the MN 101 share the same address semantic list 50 so that the MN 101 requests the address semantic list 50 or the HA 102 provides the address semantic list 50 to the MN 101.

On the other hand, in step S61, if there is no policy in the HA 102 when the IP address has been previously configured for notification, it is checked whether the notification trigger message 40 includes the address semantic list 50 configured by the MN 101 ( Step S63). If the address meaning list 50 exists in the notification trigger message 40, the HA 102 stores the address meaning list 50 in a cache (not shown) (step S64). Next, this process is terminated (step S63), and the use of the IP address is known when a notification message is transmitted to the MN 101.

If the address meaning list 50 does not exist in the notification trigger message 40 in step S63, the HA 102 negotiates with the MN 101 to construct the address meaning list 50. This form of negotiation includes a series of message exchanges between the HA 102 and the MN 101 until the address semantic list 50 is generated and terminated. Next, this process ends (step S63), and the IP address is used when a notification message is transmitted to the MN 101.

According to the present invention, since the IP address is used to notify the MN 101 of the action, this means that regardless of the IP address used, the MN 101 can receive any IF. This is the same in a network-based mobility management system to which a prefix used by the MN in the domain is assigned. For this reason, this implies that a packet using any IP address configured in the prefix range can be routed to the MN 101. As an example, MN101 as a prefix,
3FFF: B023: 8a2e: 73F / 124
124 bits are assigned. This is because MN101 adds 4 bits to 3FFF: B023: 8a2e: 73F0 / 128
To 3FFF: B023: 8a2e: 73FF / 128
It is implied that the above 16 IP addresses can be configured. Therefore, in the context of network-based mobility management, the packet 20 received by the AR 111 with a destination address in this range is transmitted to the MN 101.

Summarizing the embodiments described above, the present invention can be applied to the following methods. FIG. 7 is a flowchart for explaining a process in which the address checking engine 303 decodes the meaning of the IP address. This process starts when the address checking engine 303 receives the packet 20 from the network interface 300 (step S70). First, the address checking engine 303 retrieves the address semantic list 50 from the address policy database 302 (step S71), and then uses this list 50 for the destination address 211 in the received packet 20. It is determined whether or not the IP address is for notification (step S72). Assuming that the IP address being used is not for notification purposes, this implies that the received packet 20 is for routing. For this reason, the payload data in the received packet 20 is transferred to the application unit 301 (step S73), and then this process ends (step S76).

An example of step S73 will be described in detail. MN. CoA1 is used for routing of the first IF 1010. Therefore, when the HA 102 receives a packet to be routed to the MN 101, the HA 102 uses MN. CoA1 is attached to the received packet. When MN 101 receives the packet, MN. It is checked from the address meaning list 50 whether CoA1 is meaningful. In this case, MN. Since CoA1 is not in the list 50, the MN 101 understands that the received packet is for routing, and extracts data in the received packet.

On the other hand, when the IP address used in the destination address 211 in the received packet 20 exists in the address semantic list 50 in step S72, an action necessary for the notification purpose 52 related to the IP address is called, An appropriate application is triggered to execute the action (step S74).

An example of step S74 will be described in detail. From FIG. The CoA 5 is used to notify the HA 102 that the MN 101 is requesting a routing preference update. The MN 101 assigns the destination address 211 to the MN. When the packet 20 to be CoA5 is received from the IF 1010, the address semantic list 50 is checked and the destination address MN. Discover actions for CoA5. When the MN 101 considers this action “update MN 101's routing preference to the HA 102”, it triggers the appropriate application to perform this action. Therefore, the MN 101 transmits a message for updating the routing preference of the MN 101 to the HA 102.

When a correct application is started in step S74 shown in FIG. 7, it is further checked whether or not the received packet 20 includes a data payload (step S75). If the data payload is not included, this process is terminated (step S76). On the other hand, if the received packet 20 includes a data payload, the data payload is transferred to the application unit 301 (step S73), and then this process ends (step S76).

Note that the method of notifying actions according to the first embodiment of the present invention can be applied independently to each interface of the MN 101. Therefore, the MN 101 does not need to have a plurality of interfaces, and has one interface. The MN 101 provided may be used. When the network configuration of FIG. 1 is applied to a 3GPP system and the external network domain 11 is regarded as a non-3GPP network managed by the home network domain 10 or the external network domain 11, this technique uses mobile IP. And applied to a Non3GPP network connection establishing a connection with the AR102. At this time, the 3GPP interface of the MN 101 may be simultaneously connected to the 3GPP network.

In the above description, the HA 102 notifies the action using the CoA of the MN 101. As another method for notifying the action, instead of using the destination address of the encapsulated packet, the HA 102 transmits the encapsulated packet. The original address may be used. In this case, the HA 102 holds a plurality of addresses, and configures the address semantic list 50 by associating them with actions for notification purposes. When the action is notified to the MN 101, the encapsulated packet is transmitted using the address of the HA 102 corresponding to the action as the source address of the encapsulated packet transmitted to the HoA of the MN 101. Thereby, the load accompanying the generation and management of CoA in the MN 101 can be reduced.

In the above description, the case where the HA 102 instructs the MN 101 to perform an action is described. However, the method according to the first embodiment of the present invention can also be used when the MN 101 instructs the HA 102 to perform an action. . In this case, the HA 102 and the MN 101 share an address semantic list including an action to be notified to the HA 102, and use the corresponding CoA when the MN 101 instructs the HA 102 to perform an action registered in the address semantic list 50. And send the encapsulated packet. As a result, when the MN 101 wants to notify the HA 102 of some action, it is not necessary to transmit a message including a specific option that means the action to be notified, so that the message size and the number of messages can be reduced.
As another method for the MN 101 to instruct the operation to the HA 102, a destination address may be used instead of using the source address of the encapsulated packet. In this case, the HA 102 holds a plurality of addresses, and configures the address semantic list 50 by associating them with actions for notification purposes. When the MN 101 notifies the HA 102 of the action, the MN 101 transmits an encapsulated packet using the address of the HA 102 corresponding to the action as the destination address of the encapsulated packet to be transmitted to the HA 102. Thereby, it is possible to reduce the load accompanying the generation and management of CoA in the MN 101.

As described above, according to the first embodiment of the present invention, the transmission side uses the address associated with the meaning of the action to be notified as the destination address or the transmission source address of the packet to be transmitted. By executing the action corresponding to the address, it is not necessary to send a message including a specific option for notifying the action to the MN 101, and the message size and the number of messages can be reduced.

<Second Embodiment>
The second embodiment is applied to a domain that supports network-based mobility. That is, the external network domain 11 shown in FIG. 1 has a network-based mobility management function. For this reason, the MN 101 is assigned a prefix to be used in the external network domain 11, and always uses a unique address generated from this prefix in the external network domain 11. When the MN 101 transmits a message notifying the HA 102 that the IP address is used for notification purposes, the prefix of the external network domain 11 is attached to the transmission message.

When the BU message is used as the notification message, the prefix and the MN 101 use the IP address for the purpose of notification in the normal BU message including the address used by the MN 101 in the external network domain 11 as the care-of address. A BU message including the information to be shown is transmitted. In addition, a BU message including information indicating that an IP address is used for notification purposes may be transmitted by including a prefix in a field including a care-of address.

The HA 102 assigns an IP address used for notification purposes from this prefix. This type of assignment includes an example message exchange between HA 102 and MN 101 to obtain address semantic list 50. All the addresses held in the address semantic list as the transfer destination address of the MN 101 are addresses generated from the prefix assigned in the external network domain 11. Therefore, when the HA 102 presents the address semantic list 50 to the MN 101, the address semantic list 50 is generated by associating an arbitrary notification purpose with the address generated using the prefix notified from the MN 101 by the notification trigger message. To do. Once the address semantic list 50 is generated, the HA 102 uses the appropriate IP address from the address semantic list 50 whenever it needs to notify the MN 101 of the action. The advantage of this method is that the notification option 22 for transmitting the action need not be used in the packet 22 and the number of useful bytes available for other purposes can be saved. Further, since the HA 102 can arbitrarily designate an address to be included in the address semantic list as a transfer destination address to the MN 101, there is an advantage that it is not necessary to receive a notification of the transfer destination address from the MN 101 in advance.

<Third Embodiment>
In the third embodiment, the prefix 43 in the notification trigger message 40 for notifying that the MN 101 uses the IP address for the purpose of notification to the HA 102 includes a prefix length instead of the prefix assigned to the MN 101. In this case, the HA 102 needs to calculate the prefix used by the MN 101 in the external network domain 11 based on the prefix length of the notification trigger message 40 and the IP address. Thus, when the BU message is used as a notification trigger message transmitted from the MN 101 to the HA 102, the prefix length is only included in a normal BU message including the address used by the MN 101 in the external network domain 11 as a care-of address. Thus, the prefix used in the external network domain 11 can be known to the HA 102.

<Fourth embodiment>
In the fourth embodiment, a policy that reserves several IP addresses used for notification purposes is established in advance between the MN 101 and the HA 102. For example, this policy reserves the last four IP addresses for notification purposes. In this case, when the HA 102 receives the message 40 for starting to use the IP address for the notification purpose, the last four IP addresses from the prefix assigned to the MN 101 are automatically reflected to the predetermined notification purpose. Configured.

<Fifth embodiment>
In the fifth embodiment, a local mobility anchor (hereinafter referred to as LMA) (not shown) in the external network domain 11 further has a function of checking an IP address used for notification purposes. Therefore, the LMA has an address policy database 302 and an address checking engine 303 shown in FIG. The advantage of the fifth embodiment is that the number of packets to be used can be reduced particularly when a notification message needs to be transmitted from the HA 102 to the LMA. One example is when using flow labels to support packet routing performed by the LMA. Here, HA 102 and LMA have agreed on the type of flow label used to describe the type of traffic described in packet 20. Using the flow label, the LMA can know the type of traffic present in the packet 20 without having to obtain a packet encryption key from the MN 101. Once the LMA knows the type of traffic, it can perform selective routing in response to traffic demands.

Hereinafter, an operation example of the fifth embodiment will be described in detail. LMA and HA 102 indicate that the packet is carrying VoIP (Voice over IP) traffic. Assume that CoA7 implies. For this reason, when the HA 102 transmits a VoIP packet addressed to the MN 101, the HA 102 uses the MN. CoA7 is used. When the LMA receives the VoIP packet, the LMA operates the address checking engine 303 to determine that the VoIP packet is carrying VoIP traffic. For this reason, the LMA understands that this VoIP packet generally requires a good quality of service (QoS), looks for a QoS level that matches the MN 101, and forwards this packet from the LMA to the MN. Select the appropriate path to transfer.

<Sixth Embodiment>
In the sixth embodiment, the HA 102 has the address policy database 302 and the address checking engine 303 shown in FIG. Therefore, the HA 102 can identify the notification purpose related to the IP address from the source address 210 of the received packet 20. This packet 20 can be transmitted not only from the MN 101 but also from the CN 130. As an example, the MN.101 indicates that the MN 101 desires the HA 102 to transfer the home agent function of the MN 101 to another home agent (not shown, also referred to as a local home agent) in the vicinity of the MN 101. CoA8 is implied. The HA 102 sends the MN. When receiving the packet 20 in which the CoA 8 is set, it is understood that the MN 101 is searching for a local home agent, finds the local home agent of the MN 101, and transfers the home agent function of the MN 101 to the home agent. Then, the local home agent contacts the MN 101 and notifies that it is the home agent of the MN 101.

<Difference from conventional technology>
Here, it is obvious for those skilled in the art that the method of using the IP address for notifying the communication node of the action is different from the method described in Patent Document 1. In Patent Document 1, it is defined that the gateway causes only the processing related to routing based on the IP address of the packet. In this action, the gateway looks up the current location of the mobile node and establishes a forwarding path to the mobile node. Furthermore, the use of the IP address in Patent Document 1 is limited only to the gateway. Therefore, this means that the IP address means nothing other than routing for the mobile node. In contrast, in the present invention, the use of the IP address triggers the gateway and causes the MN 101 to perform one or more actions. For this reason, there is a difference between the present invention and Patent Document 1.

<Seventh embodiment>
The seventh embodiment is configured such that the MN 101 can understand that the action is for a specific interface of the MN 101 by the IP address that notifies the action between the MN 101 and the HA 102. The identifier of the specific interface is a BID described in Non-Patent Document 2. Here, normally, when it is necessary for the HA 102 to notify a specific interface of the MN 101 via another interface, the BID is used to indicate the target interface.

For example, assume that the MN 101 has two bindings in the HA 102. The first binding is identified using the first BID1 and is used for binding in the first IF 1010. The second binding is identified using the second BID2 and is used for binding in the second IF 1011. Here, it is assumed that the HA 102 needs to refresh the binding of the second IF 1011, and the HA 102 cannot contact the second IF 1011 directly through the routing path mapped to the second BID2. And A possible reason is that the binding / refresh request message cannot be routed to the second IF 1011 because the second AR 112 operating on the second IF 1011 is congested.

Therefore, the HA 102 determines to transmit the binding / refresh request message for the second IF 1011 via the first IF 1010. In order for the MN 101 to know that the binding / refresh request message via the first IF 1010 is a message for the second IF 1011, the HA 102 attaches the BID2 of the second IF 1011 to the binding / refresh request message. Thus, the MN 101 knows that the binding / refresh request message via the first IF 1010 is for the second IF 1011 and not for the first IF 1010. Here, when the BID indicating the target IF 1011 is used for a valuable data portion in the packet, the packet size increases. Also, if the second IF 1011 becomes disconnected and becomes invalid, the HA 102 may lose the binding cache related to the second IF 1011. In this case, the HA 102 loses the second BID 2 itself added to the binding cache of the second IF 1011 and cannot specify the IF using the BID. Therefore, in order to reduce the packet size, and in order to specify the IF even when the binding cache has been erased, in order to represent the second IF 1011 as follows, The MN 101 uses the IP address that is bound to the first IF 1010.

FIG. 8 shows the format of the notification trigger message 40a transmitted by the MN 101 in the seventh embodiment. The notification trigger message 40a is provided with one or more mobility options 85 for the MN 101 to indicate the meaning of a specific IP address to the HA 102 in addition to the fields (41, 42) shown in FIG. The mobility option 85 includes fields of a BID 850, a transfer destination address 851, and a notification meaning 852. With the BID 850, the MN 101 can notify the HA 102 which BID in the cache of the HA 102 is related to the transfer destination address 851 of the MN 101. Further, the source address 851 allows the MN 101 to notify the HA 102 of an IP address used when the HA 102 needs to notify the MN 101 of a specific action. The notification meaning 852 transmits the type of notification, and the IP address of the source address 851 is mapped to the notification meaning 852.

Note that the interface ID of each interface may be used as information indicating the interface of the MN 101 mapped to the transfer destination address 851. In this case, even if the HA 102 deletes the binding cache of the MN 101 and no BID exists, the HA 102 maps the transfer destination address 851 together with the interface to which the transfer destination address 851 is actually assigned. Can know the interface. In addition, as information indicating the interface mapped to the transfer destination address 851, the type of each interface (such as a cellular interface, a WLAN interface, a WiMAX interface, or a Bluetooth interface) may be used. In this case, when the HA 102 transmits a necessary message according to the type of interface included in the MN 101, the interface does not exist even if there is no binding cache related to the interface, for example, to reduce power consumption. Even if it is not active, the forwarded message is selected by choosing to use the forwarding address assigned to the active interface and mapped to that inactive interface. The MN 101 can be notified that it is for an inactive interface of the MN 101.

FIG. 9 shows the address meaning list 50a of the HA 102 in the seventh embodiment. In addition to the fields (51, 52) shown in FIG. 5, the address meaning list 50a is provided with a field of BID 90 for enabling the HA 102 to identify the binding of the MN 101. When the HA 102 receives the notification trigger message 40a shown in FIG.

As an example, the MN 101 uses the IF 1010... As the packet routing IP address (CoA) 51 of the first IF 1010. CoA1 is used. IF1010. The binding of CoA1 is identified by BID1 in BID90 in HA102 and MN101. In addition, when the MN 101 configures the IP address in this way and the HA 102 permits the packet addressed to the second IF 1011 to be transmitted via the first IF 1010, as shown in FIG. IF1010. As CoA51 representing IF1010. Configure CoA5. The MN 101 configures and transmits the mobility option 85 of the notification trigger message 40a as follows.
・ BID850: BID1
Source address 851: IF1010. CoA5
Notification meaning: identifier (BID, interface ID) of the second IF 1011 or interface type

When the HA 102 receives the notification trigger message 40a, the source address 851 = IF1010. It is understood that the CoA 5 is used as “the action addressed to the second IF 1011 via the first IF 1010”. Then, as shown in FIG. 9, the HA 102 updates the address meaning list 50a to reflect this notification type. When the HA 102 needs to request to update the binding of the second IF 1011, the IF 1021. A binding / refresh request message in which CoA 5 is set is transmitted to the first IF 1010. When the MN 101 receives this request message at the first IF 1010, the MN 101 understands that the request message means the second IF 1011. Therefore, the MN 101 triggers the second IF 1011 in response to the request message.

As a modification, the notification trigger message 40 has a plurality of mappings in which IP addresses are associated with notification purposes. Preferably, this IP address mapping is generated by the MN 101. Whenever it is necessary to notify the MN 101 of something, the HA 102 checks whether or not the notification message can be transmitted by the IP address. If possible, the HA 102 uses the IP address to notify the MN 101. As an advantage of this method, the size of the packet 20 can be made smaller than when the BID is used. Even if the HA 102 does not know the BID of the interface to which the message is to be transmitted, the HA 102 can transmit a message for that interface. That is, in this case, the HA 102 does not need to keep the BID of the IF 1011 indefinitely.

Hereinafter, the modified example will be described in detail. MN 101 confirms that a message is applied to all IFs of MN 101. It is configured as represented by CoA1. When the HA 102 needs to refresh all IF bindings of the MN 101, the HA 102 responds to the binding / refresh request message addressed to the MN 101 with the MN. Transmit using CoA1 as the destination IP address. When the MN 101 receives this binding refresh request message, the MN. CoA1 knows that this message is for all IFs. For this reason, the MN 101 transmits a binding / refresh message for refreshing all bindings to the HA 102 via each IF.

<Eighth Embodiment>
In the eighth embodiment, instead of the IP address having a specific purpose, the identifier has its function. This identifier is a BID described in Non-Patent Document 2, for example. This BID has a second meaning, thus not only distinguishing the specific binding of MN 101, but also notifies MN 101 to perform other actions. As an example, it is assumed that the HA 102 has two bindings related to the MN 101 as in the seventh embodiment. The first binding is identified using the first BID1 and is used for binding in the first IF 1010. The second binding is identified using the second BID2 and used for binding in the second IF 1011.

Here, assuming that the HA 102 needs to refresh all the bindings, the HA 102 needs to transmit a binding / refresh request message describing all the BIDs in order to make the MN 101 know its own intent. Therefore, as an eighth embodiment, BID0 represents all interfaces of MN101. Therefore, when the HA 102 describes BID0 in the binding / refresh request message, the MN 101 can know the intention of the HA 102. According to this method, the use of the option 22 for transmitting the second BID in the packet 20 can be omitted.

<Ninth embodiment>
In the ninth embodiment, the HA 102 includes means for returning the sleeping interface of the MN 101. This is particularly useful when the HA 102 receives a request to start data transfer to the sleeping interface of the MN 101 or an interface connected to a network in which congestion occurs. The HA 102 transmits, to the active IF of the MN 101, a packet in which the packet addressed to the sleeping interface of the MN 101 is encapsulated at the address of the active interface of the MN 101. When the MN 101 receives the encapsulated packet, the MN 101 detects that the destination address of the internal packet is the address of the sleeping IF, and knows that the HA 102 is returning the sleeping IF. And return the sleeping IF.

Hereinafter, an operation example of the ninth embodiment will be described in detail. The first IF 1010 of MN 101 is MN. CoA1 is assigned and the second IF 1011 is MN. Assume that CoA2 is assigned. The second IF 1011 is in the sleep mode for power saving. When the HA 102 needs to return the second IF 1011 in order to negotiate a routing path with a request server (not shown), the HA 102 sends the MN. In the request message addressed to CoA2, the MN. Attach CoA1. This attachment is known as packet encapsulation. When the MN 101 receives this encapsulated packet, the MN 101 understands that the HA 102 is requesting that the second IF 1011 return and communicate with both the HA 102 and the request server. Request to return from and start communication. As a result, even when a plurality of CoAs cannot be prepared for an active interface, a packet addressed to the other interface can be transferred using the active interface.

<Tenth Embodiment>
In the tenth embodiment, instead of the HA 102 notifying the MN 101 of the action by encapsulation as in the ninth embodiment, the same function is realized using an IP address. As an example, the first IF 1010 is MN. To CoA1 and MN. Both packets addressed to CoA2 can be received. When the HA 102 needs to notify the MN 101 to return the second IF 1011 from the sleep mode, the HA 102 transmits the MN. A message addressed to CoA2 is transmitted to the first IF 1010. The first IF 1010 is the second MN. When the message addressed to CoA2 is received, the MN 101 understands the intention of the HA 102 and requests the second IF 1011 to return from the sleep mode and start communication. The advantage of this method is that it is not necessary to encapsulate messages as in the tenth embodiment, and overhead can be saved.

As described above, the method in which the HA 102 uses the IP address for the purpose of notification instead of the encapsulation is effective for a system using a plurality of tunnels. As an example, in a 3GPP system, GTP (Generic Tunnelling Protocol) or PMIP is used as a means for establishing a link between two entities. GTP can also be used between multiple entities. For example, the user equipment (UE) establishes an end-to-end tunnel with a PDN-GW (packet data network gateway) using GTP. Similarly, this tunnel is carried in a tunnel established between S-GW (serving gateway) and user equipment (UE). Thus, it can be seen that the 3GPP system transfers a packet to the user equipment (UE) using a plurality of tunnels. This implies that tunneling protocols occupy valuable data space within the packet because tunneling the packet increases the packet size. Therefore, the 3GPP system can achieve the same effect as tunneling a packet by using an IP address instead of tunneling, and at the same time reduce the packet size.

<Eleventh embodiment>
FIG. 11 shows a case where the external network domain 11 has a network-based mobility management function. For routing within the domain 11 with network-based mobility management, an entity called a local mobility anchor (LMA) 110 acts as a geographical anchor point for each mobile node. In addition, the LMA 110 further manages the reachability state of each mobile node. Therefore, the LMA 110 has a certain similarity with the home agent described in Non-Patent Document 1. The LMA 110 needs to update the current location of each mobile node in order to become an anchor point for each mobile node. For this reason, whenever the MN 101 is connected to the AR 111, the AR 111 functions as a MAG (Mobile Anchor Gateway) and transmits a proxy BU (PBU) message to the LMA 110. With this PBU message, the LMA 110 binds the unique prefix of the MN 101 to the care-of address of the AR 111. With this binding, the LMA 110 can route a packet addressed to the MN 101 via the appropriate AR 111.

Further, while the MN 101 is located in the external network domain 11 that supports network-based mobility management, the MN 101 configures a plurality of care-of addresses using prefixes assigned by the external network domain 11, and The multiple care-of addresses can be bound to the HA 102 for routing. As a method of binding the plurality of care-of addresses, the method described in Non-Patent Document 2 can be used. Note that the home network domain 10 and the external network domain 11 do not necessarily have to be via the global communication domain 12, but may be directly connected via a gateway or the like.

In FIG. 11, it is assumed that the MN 101 associates with the AR 111 and executes a necessary authentication procedure. If the authentication is successful, the AR 111 transmits to the LMA 110 a PBU message for binding the MN-ID of the MN 101 and the prefix to the care-of address of the AR 111. When the LMA 110 receives the packet of the PBU message, it checks its own binding cache and finds a match with the MN-ID in the PBU message. In this system, the LMA 110 identifies that the MN-ID of the MN 101 is the best matching. The LMA 110 tunnels the packet addressed to the MN 101 to the AR 111, and the AR 111 transfers the packet addressed to the MN 101 to the MN 101.

The system described in FIG. 11 is assumed to be an SAE (System Architecture Evolution) where 3GPP-LTE (the Third Generation Partnership Project Long Term Evolution) project is working. When matching the relationship between the system shown in FIG. 11 and the SAE, the HA 102 or LMA 110 is a PDN-GW (Packet Data Network Gateway), and the

ARs

111 and 112 are S-GW (Serving Gateway) or ePDG (Evolved Packet Data). Gateway), and further, AGW (Access 内 Gateway) existing in the Non3GPP network, and MN101 is UE (User Equipment). Further, the external network domain 11 can be regarded as a non-3GPP network managed by the home network domain 10 or the external network domain 11. In that case, the home network domain 11 which is a 3GPP network is connected to the Non3GPP network via the ePDG. Further, the two interfaces of the MN 101 (UE) in FIG. 11 are a 3GPP interface and a Non3GPP interface (WLAN or WiMAX), the IF 1010 is connected to a 3GPP network (home network domain in FIG. 1), and the IF 1011 is a Non3GPP network ( It may be connected to an external network domain in FIG. In this case, the 3GPP network is connected to the HA 102 using GTP (Generic Tunnelling Protocol) or PMIP, and the Non3GPP network is connected to the LMA 110 using PMIP.

Using a method of registering a plurality of care-of addresses, the MN 101 (or mobile router) can set a preference in the HA 102 to selectively route traffic flows to a plurality of care-of addresses. A method of setting this preference is disclosed in Non-Patent Document 5, and is possible by identifying a traffic flow using a unique flow identifier (FID). The MN 101 can selectively receive a flow via

various interfaces

1010 and 1011 according to the FID assigned to each traffic flow. Hereinafter, this method is referred to as “flow filtering”. Accordingly, the MN 101 can instruct its own HA 102 to which of the interfaces 1010 and 1011 a specific traffic flow is routed.

Here, in FIG. 11, it is assumed that the MN 101 starts a video conference session with the CN 130, and components constituting the video conference session are a signaling flow (FID1), a video flow (FID2), and a voice flow (FID3). Shall be. When the MN 101 transmits a message instructing how to flow these flows to the HA 102, the MN 101 maps each FID to a care-of address of each interface in the message of Non-Patent Document 5. For example, the signaling flow (FID1) is mapped to the care-of address of the IF 1010, and the video flow (FID2) and the voice flow (FID3) are mapped to the care-of address of the IF 1011. HA 102 forwards each flow to MN 101 using the mapping indicated by this message received from MN 101.

Similarly, the same technique described in Non-Patent Document 5 can be applied to MN101 and LMA110. The reason why the MN 101 performs flow routing by the LMA 110 rather than by the HA 102 is that the network state is constantly changing in the external network domain 11, and therefore the MN 101 frequently corrects the flow routing rule. If the flow routing rule is updated for the HA 102, a transmission delay occurs, so it is not effective when the network state frequently changes. Such a situation is commonly found, for example, in a wireless local area network (WLAN).

However, even if the MN 101 notifies the LMA 110 of the FID of each flow, it is not sufficient to ensure that the LMA 110 forwards the flow according to the preferences of the MN 101. This is because any packet transferred from the HA 102 to the MN 101 is protected by IPSec in order to prevent the intermediate node from knowing what the packet contains. Since the FID usually exists in the protected part of the packet, the LMA 110 cannot know which flow the packet belongs to. In order for the LMA 110 to know which flow the packet belongs to, the MN 101 needs to request the HA 102 to place the packet identifier outside the protected part.

There is a method of using a flow label described in Non-Patent Document 6 as a method for realizing this. Since the flow label is usually not protected within the packet, the LMA 110 can identify which flow the packet belongs to for flow routing. In this case, the MN 101 instructs the HA 102 to add a flow label to each packet, and notifies the LMA 110 how to forward the packet with the flow label to the care-of address of the MN 101. Just do it.

Further, in FIG. 11, it is assumed that the home network domain 10 of the MN 101 is located in the country A, and the MN 101 roams to the external network domain 11 located in the country B. In this state, the transmission time when the MN 101 transmits a packet to the HA 102 is longer than that when the packet is transmitted to the LMA 110. For this reason, when the MN 101 moves in the external network domain 11 at a high speed, the network state experienced by the MN 101 frequently changes. Under such circumstances, it is more efficient that the MN 101 performs flow routing with the LMA 110 than with the HA 102 in terms of round trip time.

Further, as a conventional example, in order to ensure that the LMA 110 can correctly execute the flow routing, a method in which the MN 101 requests the HA 102 to use a flow label in order to identify a packet to be transferred to the MN 101 is known. It has been. For example, the label L1 is attached to the voice flow from the CN 130. Also, the MN 101 notifies the LMA 110 which interface of the MN 101 the labeled packet is transferred to, for example, the packet with the label L1 is notified to be transferred to the IF 1010. When the HA 102 transfers the voice flow from the CN 130 to the MN 101, the HA 102 attaches a label L1 to the packet. In LMA 110, the packet with label L1 is accepted as a voice packet and transferred to IF 1010.

The concept of flow routing using both HA 102 and LMA 110 is also common in 3GPP systems, and user equipment (UE) may have multiple PDN-GW associations. Thus, if the user equipment connects with one PDN-GW in the external network domain 11, it will perform selective flow routing via the external PDN-GW (ie LMA 110) to reduce round trip time. You may have a preference that you want to run.

Furthermore, as described in Non-Patent Document 5, when the MN 101 is applied to a message for flow routing transmitted to the HA 102, the message includes one or many FID options, so that the FID option indicates the packet size of the message. Increase.

Therefore, in the eleventh embodiment, a plurality of flows of packets addressed to the MN 101 between the MN 101 that is a mobile communication device, the HA 102 that is a mobility management device of the MN 101, and / or the LMA 110 that is a relay node, The correspondence relationship of each destination IP address in the plurality of interfaces of the MN 101 is set in advance, and the MN 101 requests (triggers) the HA 102 and / or the LMA 110 to use this correspondence relationship, and the HA 102 and / or the LMA 110 sends this request. When received, a plurality of flows of packets destined for the MN 101 are selectively transferred to each destination IP address of the MN 101 based on the correspondence relationship. Note that as a message for requesting the HA 102 and / or LMA 110 to use the correspondence relationship between the flow and the destination IP address, a message having a flag or the like set in a message having a mobility header such as a BU message may be used. It may be requested by setting a flag or the like in an IKEv2 message that is performed when an IPSec tunnel is established with. Also, the correspondence between the flow and the destination IP address may be set statically or dynamically. In the case of dynamic setting, for example, it may be included in a message (BU message) requesting the use of the correspondence between the flow and the destination IP address.

Also in the eleventh embodiment, the MN 101 uses the notification trigger message 40 shown in FIG. 4 to notify (trigger) that the IP address is used to represent each different packet flow from the CN 130. Can be used. This is advantageous when the MN 101 requests the LMA 110 to execute flow routing. By using an IP address to represent each different packet flow from CN 130, LMA 110 can perform flow filtering based on the IP address of the packet. Here, the destination address field of the packet is not protected because it is used by the intermediate node for routing. Therefore, it means that the LMA 110 can correctly transfer the packet to the MN 101 based on the preference of the MN 101. Note that the MN 101 itself may request the HA 102 to use different IP addresses as transfer destinations according to the flow type in order to identify the flow type of the received packet. The network configuration in this case need not be limited to a network configuration in which the functions of the HA 102 and the LMA 110 are provided by separate entities as shown in FIG. For example, when the HA 102 and the LMA 110 are configured by the same entity, the prefix assigned from the function of the LMA 110 is compared with the address assigned by the function of the HA 102 (the address generated from the prefix). May be registered in the HA 102 as a care-of address). The external network domain 11 to which the MN 101 is connected does not necessarily have a network-based mobility management function, and the prefix assigned in the external network domain 11 may be unique for each MN. For example, when the MN 101 can use a HA 103 different from the HA 102 and is assigned a unique prefix from the HA 103, the prefix is registered in the HA 102 as a care-of prefix (an address generated from the prefix is a care-of address). It may be the case. If the prefix assigned to the MN 101 in the external network domain 11 is unique, all packets addressed to the address generated from the prefix are transferred to the MN 101. Therefore, the MN 101 sets the destination address of the packet transferred from the HA 102. The flow type of the packet can be specified by confirming the flow corresponding to the address. As a result, the flow type of the received packet can be easily specified without checking the source address, protocol number, port number, etc. included in the packet from the CN 130 included in the forwarded packet. . In this case, the MN 101 may have one interface.

FIG. 12 shows a message sequence for using an IP address to represent each different packet flow in the eleventh embodiment. Here, it is assumed that the MN 101 has

IFs

1010 and 1011 and two different packet flows from the CN 130, that is, a voice flow and a data flow. For this reason, the voice flow and data flow of packets addressed to MN 101 between MN 101 and HA 102, and the correspondence relationship between IP addresses IP Addr1 and IP Addr2 of MN 101 used as destination addresses when transferring those flows, respectively. Set in advance. Then, the MN 101 instructs (triggers) to use the IP addresses IP Addr1 and IP Addr2 to uniquely identify the voice flow and data flow from the CN 130 to the HA 102 (signaling S100).

This notification message can use the notification trigger message 40 shown in FIG. 4, but is not limited to this. When using the notification trigger message 40, the flag 44 is set to “1” to instruct the HA 102 to use the IP addresses IP Addr1, IP Addr2 to uniquely identify the voice flow and data flow from the CN 130, respectively. Also, the HA 102 understands this.

When the HA 102 receives the voice flow packet (CN: Voice) from the CN 130 (signaling S101), the HA 102 transfers the voice flow packet to the MN 101 via the address IP Addr1 in accordance with the instruction of the MN 101 (signaling S102). The LMA 110 executes normal prefix-based transfer based on the prefix of the address IP Addr1, and transfers the voice flow packet to the IF 1010 (signaling S103). Similarly, when the HA 102 receives the data flow packet (CN: Data) from the CN 130 (signaling S104), the HA 102 transfers the data flow packet to the MN 101 via the address IPrAddr2 of the IF 1011 according to the instruction of the MN 101 ( Signaling S105). The LMA 110 executes a normal prefix-based transfer based on the prefix of the address IP Addr2, and transfers the data flow packet to the same IF 1010 as the voice flow (signaling S106).

Next, it is assumed that the MN 101 determines to perform flow filtering in the LMA 110 on the data flow from the CN 130. For this purpose, the MN 101 and the LMA 110 previously set the corresponding relationship between the voice flow and data flow of the packet addressed to the MN 101 and the IP addresses IP Addr1 and IP Addr2 of the MN 101 in advance. Then, the MN 101 instructs (triggers) the LMA 110 to transfer a packet addressed to the address IP Addr2 to the IF 1011 (signaling S107). Therefore, when the LMA 110 receives a packet addressed to the address IP Addr2 (signaling S108), all packets addressed to the address IP Addr2 are transferred to the IF 1011 according to the instruction of the MN 101 (signaling S109).

Here, the advantage of the method described in the eleventh embodiment over the method using the flow label described in Non-Patent Document 6 is that the packet size can be reduced. However, according to Non-Patent Document 6, before the flow routing, the MN 101 needs to instruct both the HA 102 and the LMA 110 of each role of the flow routing. That is, in Non-Patent Document 6, the message transmitted from the MN 101 to the HA 102 in the signaling S100 shown in FIG. 12 needs to include a flow label that the HA 102 uses to uniquely identify packets from individual different flows. . A typical flow label occupies 20 bits (or 2 bytes) in the packet, and if MN 101 describes two different flow labels, 40 bits (or 4 bytes) are used. On the other hand, according to the eleventh embodiment, only a 1-bit flag 44 in the notification trigger message 40 shown in FIG. 4 is used for each flow from the MN 101 to the HA 102 using a unique IP address. It is sufficient to notify that. In this case, 39 bits (approximately 4 bytes) can be saved.

Similarly, the reduction in the number of bits is the same when the FID is used in the message transmitted from the MN 101 to the HA 102 in the signaling S100 shown in FIG. Each FID occupies 8 bits (ie 1 byte) in the message, and thus requires a total of 16 bits (ie 21 bytes). On the other hand, according to the eleventh embodiment, only a 1-bit flag 44 in the notification trigger message 40 shown in FIG. 4 is used for each flow from the MN 101 to the HA 102 using a unique IP address. It is sufficient to notify that. In this case, 15 bits (approximately 2 bytes) can be saved.

<Twelfth embodiment>
In the twelfth embodiment, as in the notification trigger message 40b shown in FIG. 13, for example, a 2-bit option type 44b is used instead of the flag 44 in the notification trigger message 40 shown in FIG. Notice. The reason for using the option type 44b is that the MN 101 or HA 102 sometimes wants to use an IP address for the notification contents of many notification messages. Such notification contents cannot be expressed by 1 bit, and require a larger number of bits.

FIG. 14 shows an address meaning list 11000 for each option type 11001 in the twelfth embodiment. The option type 11001 is composed of 2 bits. The IP address meaning 11002 indicates how the reception side of the notification trigger message 40b should use the IP address. When option type = 00, for example, “normal routing” is indicated. When option type = 01, for example, “binding / refresh” is indicated. In addition, when the notification trigger message 40b in which “10” is set in the option type 11001 is transmitted to the HA 102, the MN 101 wants to use an IP address to represent the flow of the CN 130 instead of the flag 44 (CN flow). (Identification) is notified (triggered) to the HA 102. When option type = 11, for example, “routing rule generation” is indicated.

<Thirteenth embodiment>
In the thirteenth embodiment, the MN 101 notifies the HA 102 of the intention of the MN 101 using the bits in the source address of the uplink packet. With this method, the MN 101 can instruct the HA 102 how to handle the downlink packet related to the uplink packet. The advantage of this method is that the MN 101 does not need to send messages to the HA 102 for each specific flow.

FIG. 15 shows a format of an encapsulated packet 12000 that the MN 101 uses for the HA 102 in the thirteenth embodiment. The packet 12000 can be used as a message transmitted by the signaling S100 illustrated in FIG. 12, but is not limited thereto. The encapsulated packet 12000 includes a transmission source address 12001 and an encapsulation unit 12002. The source address 12001 is an IPv4 or IPv6 address of the MN 101, and is configured (that is, divided) by an address space bit 120010 and a notification space bit 120011. By combining both the address space bit 120010 and the notification space bit 120011, the MN 101 can represent the source address 12001 of the packet 12000. The encapsulation unit 12002 includes a packet in which the MN 101 requests transfer from the HA 102 to the other party.

In order to enable the MN 101 to notify the HA 102 of its own intention, the value of the notification space bit 120011 differs depending on the intention of the MN 101 as shown in FIG. For example, if the MN 101 wants to request the HA 102 to use an IP address to identify a specific flow during downlink packet transfer, the notification space bit 120011 is set to “10”. To do. Based on the address semantic list 11000 shown in FIG. 14, the HA 102 understands that “10” “uses an IP address to identify this flow”.

A specific example will be described below. In FIG. 11, it is assumed that the MN 101 receives a data flow from the CN 130 via the HA 102 at the IF 1010. For this data flow, MN 101 and CN 130 need to exchange data with each other. For this reason, data is transferred from the MN 101 to the CN 130 and from the CN 130 to the MN 101. Assume that the MN 101 decides to request the HA 102 to use an IP address to identify this data flow for the purpose of flow routing in the LMA 110. Here, the MN 101 can also notify the LMA 110 how to flow-filter and forward a packet with a specific IP address.

Here, the MN 101 transmits an uplink packet in which “10” is set to the notification space bit 120011 in the transmission source address 12001 to the HA 102. When the HA 102 receives this uplink packet, it knows that the notification space bit 120011 is “10” and the MN 101 uses the IP address to identify the downlink packet of the same data flow. I understand that I am requesting that.

Here, it is obvious for those skilled in the art that the method of using the IP address for notifying the communication node of the action in the twelfth embodiment is different from Patent Document 3. In the prior art described in Patent Document 3, a network entity (for example, an AAA server) uses a SIP notification message option to delete client registration in the SIP server. With this option, the AAA server notifies the SIP server to delete the registration of the client identifier. If this prior art uses the twelfth embodiment, the source address of the SIP notification message is used as the client address, and it is sent without additionally including an identifier option. For this reason, there is a difference between the twelfth embodiment and this prior art.

Also, those skilled in the art will appreciate that the method of using the IP address to notify the communication node of the action in the thirteenth embodiment is different from that of Patent Document 4. In the prior art described in Patent Document 4, the IP address of the uplink packet received by the gateway node is used to generate and modify the same downlink packet routing rule. It is similar. However, the scope of this prior art is that the mobile node only notifies the entity of the action (routing rule creation and modification). On the other hand, in the thirteenth embodiment, a plurality of actions are dynamically notified to the entity using the bits of the IP address. For this reason, there is a difference between the thirteenth embodiment and this prior art.

<Fourteenth embodiment>
In the fourteenth embodiment, the MN 101 notifies its intention to the LMA 110 using bits in the uplink packet. Also in the fourteenth embodiment, the MN 101 can notify the LMA 110 of the intention of the MN 101 using the notification space bit 120011 shown in FIG. This means that the MN 101 can notify both the HA 102 and the LMA 110 using the same packet. The message transmitted by the MN 101 in the fourteenth embodiment corresponds to the signaling S100 or S107 shown in FIG. However, it is not limited to this.

MN 101 first negotiates with HA 102 and LMA 110 the meaning of notification space bit 120011 for the purpose of synchronization. For example, the MN 101 notifies the HA 102 that the first two bits in the 4-bit notification space bit 120011 represent an instruction for the HA 102 from the MN 101. Similarly, the MN 101 notifies the LMA 110 that the last two bits in the notification space bit 120011 represent an instruction for the LMA 110 from the MN 101. The advantage is that the number of messages that the MN 101 has to send to the HA 102 and LMA 110 can be saved.

For example, when the MN 101 receives the data flow from the CN 130 via the HA 102 at the IF 1010, the MN 101 and the CN 130 need to exchange data for this data flow, and transfer data to each other. MN 101 decides to use an IP address (eg MN.CoA7) to represent this data flow and instructs HA 102 to use the IP address (MN.CoA7) to represent this data flow Suppose you want to. Similarly, when the MN 101 receives a packet, the MN 101 wants to notify the IP address (MN.CoA7) that a routing rule for forwarding the received packet to the IF 1011 is generated.

Therefore, when the MN 101 transmits an uplink packet to the HA 102, the MN 101 sets “1011” to the notification space bit 120011 in the transmission source address 12001 of the packet. The HA 102 understands from the first two bits “10” of the notification space bit 120011 that the MN 101 wants to use the IP address (MN.CoA7) to identify the downlink packet of this data flow. Also, since the same uplink packet is transmitted to the HA 102 via the LMA 110, the LMA 110 changes the routing rule for the IP address (MN.CoA7) from the last two bits “11” of the notification space bit 120011. I understand what I want. In this case, the LMA 110 generates a routing rule for forwarding the packet to the IF 1011 for the IP address (MN.CoA7).

<Fifteenth embodiment>
In the fifteenth embodiment, the MN 101 notifies the HA 102 to self-generate a notification IP address using a flag. In the fifteenth embodiment, the MN 101 notifies the HA 102 to self-generate an IP address representing each different packet flow from the CN 130 using the notification trigger message 40 in the format shown in FIG. Can do. For example, the MN 101 transmits the notification trigger message 40 to the HA 102 in the signaling S100 shown in FIG. In this message 40, a flag 44 is set to “1”, and this flag 44 causes the HA 102 to self-generate an IP address set representing each different flow transferred from the CN 130 to the MN 101 with respect to the HA 102. I understand that I want to.

An advantage of the MN 101 requesting the HA 102 to self-generate an IP address for notification is that the amount of signaling between the MN 101 and the HA 102 can be saved. The MN 101 requests the HA 102 to self-generate an IP address for notification, so that it is not necessary to send a message to the HA 102 even when communication with another CN is started.

<Sixteenth Embodiment>
In the sixteenth embodiment, the MN 101 notifies the HA 102 to self-generate a notification IP address with the option type 44b instead of the flag 44 of the notification trigger message 40b shown in FIG. The reason for using option type 44b is that MN 101 or HA 102 may have many ways to self-generate an IP address. As a method of self-generating an IP address, there are a method of incrementing an IP address value or using a publicly known hash function. However, it is not limited to this. In order to notify the method of self-generating the IP address, a single bit cannot be used, so a larger number of bits is required.

For example, option type = 10 instructs the use of a publicly known hash function (for example, a secure hash algorithm) as a method for generating an IP address representing the flow of the CN 130. In this case, the MN 101 transmits a notification trigger message 40b having an option type = 10 to the HA 102. The HA 102 receives this message 40b, and the MN 101 generates a IP address representing the flow of the CN 130 as a known hash. I understand that I want to use the function.

<Seventeenth embodiment>
In the seventeenth embodiment, the HA 102 notifies the MN 101 of a method of self-generating a notification IP address with the option type 44b using the notification trigger message 40b shown in FIG. That is, in the seventeenth embodiment, the HA 102 uses the method described in the fifteenth embodiment to notify the MN 101 of a method for generating an IP address representing the flow of the CN 130. For example, option type = 11 indicates a method of incrementing the value of the IP address as a method of generating an IP address representing the flow of the CN 130. Here, the HA 102 selects a method that can be supported by the HA 102 if there is no instruction in the notification trigger message 40b received from the MN 101 indicating the method for generating the IP address representing the flow of the CN 130. In this case, the HA 102 increments the value of the IP address as a method of generating an IP address representing the flow of the CN 130 by sending back a message including the option type = 11 as a response to the notification trigger message 40b received from the MN 101. Notify the MN 101 to use the method.

This method has an advantage when the HA 102 cannot support the IP address generation method specified by the MN 101. Therefore, the HA 102 notifies the MN 101 of the IP address self-generation method, so that it is possible to ensure that the MN 101 and the HA 102 use the same IP address self-generation method to generate an IP address representing the flow of the CN 130.

<Eighteenth embodiment>
In the eighteenth embodiment, a bit in the IP address is used to instruct the IP address self-generation method. In this case, the MN 101 can instruct the HA 102 using the notification space bit 120011 shown in FIG. For example, the MN 101 uses a known hash function (for example, a secure hash algorithm) by transmitting a message (for example, signaling S100 shown in FIG. 12) in which the notification space bit 120011 is set to “10” to the HA 102. That the IP address representing the flow of the CN 130 is self-generated. Conversely, the HA 102 notifies the MN 101 of the IP address self-generation method supported by itself using the notification space bit 120011 shown in FIG.

<Nineteenth embodiment>
In the nineteenth embodiment of the present invention, the IF 1011 of the MN 101 connects to the home network domain 10 using the network-based mobility protocol in the action notification method described in the first embodiment of the present invention. Applicable when When the network configuration of FIG. 11 is applied to a 3GPP system, the external network domain 11 is regarded as a home network domain 10 or a Non3GPP network managed by the external network domain 11, and IF 1011 (WLAN or WiMAX) is The PM 10 is connected to the HA 102 in the home network domain 10 via the Non3GPP network using PMIP, and the IF 1010 is connected to the home network domain 10 that is a 3GPP network using GTP or PMIP. At this time, the HA 102 functions as an LMA for the MN 101.

The definition and acquisition method of the address meaning list 50 are the same as those in the first embodiment of the present invention, and thus the description thereof is omitted. When the HA 102 needs to notify the MN 101 of an action, the HA 102 refers to the address semantic list 50, acquires an address corresponding to the notified action, and sets it as the destination address of the packet addressed to the MN 101. If the packet to be transmitted to the MN 101 is a packet transmitted from the CN 130, the home address of the MN 101 that has already been set as the destination address is changed to the address acquired from the address meaning list 50 and transmitted. On the other hand, the MN 101 that has received this packet checks the destination address of the received packet and confirms whether there is a corresponding address in the address meaning list 50. If there is a corresponding address, the action indicated by the address is executed, and the destination address of the received packet is converted to the original home address and passed to the upper layer. As described above, the MN 101 recognizes and executes the requested action by confirming the destination address of the packet received from the HA 102, and at the same time, the destination address changed by the HA 102 for the action notification is changed again to the original home address. It is converted to an address and processed as a data packet addressed to a normal home address.

Note that since the above method can be applied independently to each interface of the MN 101, the MN 101 does not have to have a plurality of interfaces, and the MN 101 has either a 3GPP interface or a Non3GPP interface. It may be.

Also, when the MN 101 needs to notify the HA 102 of an action, the above-described method can be used. When the MN 101 needs to notify the HA 102 of an action, the MN 101 refers to the address semantic list 50, acquires an address corresponding to the notified action, and sets it as the source address of the packet. If this packet is addressed to the CN 130, the home address is originally set as the source address, but in this method, the MN 101 changes the home address to an address corresponding to the action and transmits it. To do. On the other hand, the HA 102 that has received this packet checks the transmission source address of the received packet and confirms whether there is a corresponding address in the address meaning list 50. If there is a corresponding address, the action indicated by the address is executed, and the source address of the received packet is changed to the original home address and transferred. In this way, the HA 102 recognizes and executes the requested action by confirming the source address of the packet received from the MN 101, and at the same time, the HA 102 again uses the source address changed by the MN 101 for the action notification. To the home address and forwarded as a normal data packet addressed to the CN 130.

Here, as an example of an action request from the MN 101 to the HA 102, a case of requesting switching of a packet transfer destination will be described. When the MN 101 has two interfaces, different prefixes (P1, P2) may be assigned to the IF 1010 and the IF 1011, respectively. This occurs not only when the two interfaces are connected to different HAs, but also when they are connected to the same HA, but here P1 is managed by HA102 and P2 is managed by another HA. It shall be. In this case, the MN 101 can use the address generated from each prefix for communication with the CN 130, but all packets addressed to the P1 address are transferred to the IF 1010, and all packets addressed to the P2 address are transferred to the IF 1011. . Here, the MN 101 registers an address different from the home address generated from the P2 with the HA 102 that manages the P1 as an address indicating an action of forwarding a packet addressed to the P1 address to the IF 1011. Note that the MN 101 also needs to register in the HA 102 packet filtering rules (forwarding a flow addressed to P1 to the IF 1011 (P2)) for executing flow filtering. Based on this packet filtering rule, the HA 102 identifies the flow addressed to the P1 address to be forwarded to the IF 1011, and further uses the address semantic list to forward the flow addressed to the P1 address to the IF 1011. Get the corresponding P2 address. Then, the destination address to which the home address of P1 is originally set is converted to the acquired P2 address and transmitted to the MN 101. Upon receiving this packet, the MN 101 recognizes that the destination address of the packet is the P2 address used for flow filtering, converts the destination address to the original home address, and passes it to the upper layer. That is, when the destination address is the above-described P2 address, the MN 101 recognizes that the LMA 110 has switched the forwarding destination of the packet to the home address of P1. As a result, the HA 102 does not need to encapsulate the packet addressed to the home address of P1 with the home address generated from P2, so that the packet size can be reduced.

Also, the packet transfer destination switching request is applied when the IF 1011 of the MN 101 is connected to the home network domain 10 using the mobile IP. When the network configuration of FIG. 11 is applied to a 3GPP system, the external network domain 11 is regarded as a home network domain 10 or a Non3GPP network managed by the external network domain 11, and IF 1011 (WLAN or WiMAX) is The mobile IP is used to connect to the HA 102 in the home network domain 10 via the Non3GPP network, and the IF 1010 is connected to the home network domain 10 that is a 3GPP network using GTP or PMIP. At this time, the HA 102 functions as an LMA for the MN 101. That is, the HA 102 functions as an LMA for a 3GPP network connection and functions as an HA for a Non3GPP network. Here, when the P1 prefix is assigned to the IF 1010 and the P2 prefix is assigned to the IF 1011, the MN 101 associates the action of transferring the packet addressed to the P1 address to the IF 1011 as described above to the HA 102 in association with the P2 address. Request. Then, a method is used in which the HA 102 converts the destination address to the P2 address, and the MN 101 reconverts it to the P1 home address. This eliminates the need for the HA 102 to encapsulate the packet destined for P1 with the home address of P2, thereby reducing the packet size.

According to the nineteenth embodiment of the present invention, the transmission side uses the address associated with the meaning of the action to be notified as the destination address or transmission source address of the packet to be transmitted, while the reception side corresponds to that address. By executing the action and further converting the destination address or the source address, it is not necessary to send a message including a specific option for notifying the action, and the message size and the number of messages can be reduced.

The present invention has been described above by taking the most practical and desirable embodiment as an example. However, it will be apparent to those skilled in the art that various modifications can be made. For example, the functional configuration of the MN 101 shown in FIG. 3 can be provided in a mobile router that is also a mobile communication device. With this configuration, an action targeting the mobile router can be transmitted using the IP address. Also, those skilled in the art will appreciate that the MN 101 can be located in a mobile network managed by a mobile router. For this reason, the MN 101 can notify the HA 102 of the prefix of the mobile network advertised by the mobile router. Then, the HA 102 can contact the mobile router or the home agent of the mobile router to start assigning an IP address necessary for notification. Furthermore, those skilled in the art can clearly apply the present invention to a fixed communication node having the functional configuration of the MN 101 shown in FIG.

Each functional block used in the description of the above embodiment is typically realized as an LSI that 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. Further, 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) that can be programmed after manufacturing the LSI, or a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used. Further, if integrated circuit technology comes out to replace LSI's as a result of the advancement of semiconductor technology or a derivative other technology, it is naturally also possible to carry out function block integration using this technology. For example, biotechnology can be applied.

INDUSTRIAL APPLICABILITY The present invention has an effect that when a notification message is transmitted between nodes using an IP address, a correspondence relationship between an arbitrary IP address and a notification purpose can be set, particularly when a mobile communication device roams. It can be used for
Further, the present invention has an effect that the mobile communication device can instruct the transfer management interface and / or the relay node of the flow transfer destination interface with a small packet size not including the flow ID or the flow label, This can be used especially when the mobile node roams.

Claims

In the communication method of transmitting from the first communication node to the second communication node using the IP address as the notification content of the notification message,
Setting a correspondence relationship between the IP address and the notification content of the notification message between the first communication node and the second communication node;
When transmitting the set notification content from the first communication node to the second communication node, the set IP address is transferred from the first communication node to the second communication node. Transmitting the packet as a destination address of the packet to be transmitted;
Decoding the set notification content from the destination address of the packet received by the second communication node from the first communication node;
A communication method characterized by comprising:
In a communication system that transmits an IP address as a notification content of a notification message from a first communication node to a second communication node,
Means for setting a correspondence relationship between the IP address and the notification content of the notification message between the first communication node and the second communication node;
When transmitting the set notification content from the first communication node to the second communication node, the set IP address is transferred from the first communication node to the second communication node. Means for transmitting the packet as a destination address of the packet to be transmitted;
Means for decoding the set notification content from the destination address of the packet received by the second communication node from the first communication node;
A communication system comprising:
The first communication node in the communication system for transmitting from the first communication node to the second communication node using the IP address as the notification content of the notification message,
Means for setting a correspondence between the IP address and the notification content of the notification message between the second communication nodes;
When transmitting the set notification content to the second communication node, the set IP address is used as a destination address of a packet to be transmitted from the first communication node to the second communication node. Means for transmitting the packet;
Communication node provided.
The second communication node in the communication system for transmitting from the first communication node to the second communication node using the IP address as the notification content of the notification message,
Means for setting a correspondence relationship between the IP address and the notification content of the notification message with the first communication node;
Means for decoding the set notification content from the destination address of the packet received from the first communication node;
Communication node provided.
In a communication method of transmitting using an IP address as a notification content of a notification message,
Generating an IP address to be used for notification purposes based on a prefix or prefix length obtained from the domain by the mobile communication device;
An IP address setting step for setting a correspondence relationship between the IP address generated for the notification purpose and the notification content of the notification message between the mobile communication device and the mobility management device;
When transmitting the set notification content from the mobility management device to the mobile communication device, the set IP address is used as a destination address of a packet to be transmitted from the mobility management device to the mobile communication device. Sending a packet;
Decoding the set notification content from the destination address of the packet received by the mobile communication device from the mobility management device;
A communication method characterized by comprising:
The IP address setting step sets a policy for reserving an IP address used for the notification purpose in advance between the mobile communication device and the mobility management device, and is generated by the mobile communication device based on the policy. 6. The communication method according to claim 5, wherein an IP address used for the notification purpose is selected from a plurality of IP addresses.
6. The communication method according to claim 5, wherein in the IP address setting step, when the mobile communication device has a plurality of interfaces, the IP address is set so as to further represent an interface to be notified.
The IP address represents an interface on which the notification target interface is sleeping, and the non-sleeping interface decodes the IP address to return the sleeping interface from a sleep state. 8. The communication method according to 7.
In a communication system that transmits using an IP address as a notification content of a notification message,
Means for generating an IP address used for notification purposes based on a prefix or prefix length obtained from a domain by a mobile communication device;
IP address setting means for setting a correspondence relationship between the generated IP address and the notification content of the notification message between the mobile communication device and the mobility management device;
When transmitting the set notification content from the mobility management device to the mobile communication device, the set IP address is used as a destination address of a packet to be transmitted from the mobility management device to the mobile communication device. Means for transmitting packets;
Means for decoding the set notification content from the destination address of the packet received by the mobile communication device from the mobility management device;
A communication system comprising:
The IP address setting means sets a policy for reserving an IP address used for the notification purpose in advance between the mobile communication device and the mobility management device, and is generated by the mobile communication device based on the policy. The communication system according to claim 9, wherein an IP address used for the notification purpose is selected from a plurality of IP addresses.
11. The communication system according to claim 10, wherein, when the mobile communication apparatus has a plurality of interfaces, the IP address setting means sets the IP address to further indicate an interface to be notified.
The IP address represents an interface on which the notification target interface is sleeping, and an interface that is not sleeping decodes the IP address to return the sleeping interface from a sleep state. 11. The communication system according to 11.
A mobile communication device in a communication system that transmits using an IP address as notification content of a notification message,
Means for generating an IP address to be used for notification purposes based on a prefix or prefix length obtained from a domain;
IP address setting means for setting a correspondence relationship between the generated IP address and the notification content of the notification message between the mobility management devices of the mobile communication device;
Means for decoding the set notification content from the destination address of the packet received from the mobility management device;
A mobile communication device.
The IP address setting means sets in advance a policy for reserving an IP address to be used for the notification purpose with the mobility management device, and a plurality of IPs generated by the mobile communication device based on the policy The mobile communication apparatus according to claim 13, wherein an IP address used for the notification purpose is selected from addresses.
14. The mobile communication device according to claim 13, wherein, when the mobile communication device has a plurality of interfaces, the IP address setting means sets the IP address to further indicate an interface to be notified.
The IP address represents an interface on which the notification target interface is sleeping, and an interface that is not sleeping decodes the IP address to return the sleeping interface from a sleep state. 15. The mobile communication device according to 15.
A mobility management device of a mobile communication device in a communication system that transmits using an IP address as a notification content of a notification message,
IP address setting means for setting a correspondence relationship between the IP address generated for the purpose of notification based on a prefix or prefix length by the mobile communication device and the notification content of the notification message with the mobile communication device;
Means for transmitting the packet using the set IP address as a destination address of a packet to be transmitted to the mobile communication device when transmitting the set notification content to the mobile communication device;
A mobility management device.
18. The mobility management device according to claim 17, further comprising means for decoding the set notification content from a destination address of the packet received from the mobile communication device.
The IP address setting means sets in advance a policy for reserving an IP address to be used for the notification purpose with the mobile communication device, and a plurality of IPs generated by the mobile communication device based on the policy 18. The mobility management apparatus according to claim 17, wherein an IP address used for the notification purpose is selected from addresses.
18. The mobility management device according to claim 17, wherein, when the mobile communication device has a plurality of interfaces, the IP address setting means sets the IP address to further indicate an interface to be notified.
The IP address represents an interface on which the notification target interface is sleeping, and a non-sleeping interface represents a request for decoding the IP address and returning the sleeping interface from a sleep state. The mobility management device according to claim 20.
In a communication method in which a mobility management device and / or a relay node of the mobile communication device transfers a packet addressed to the mobile communication device for a mobile communication device having a plurality of interfaces.
A correspondence relationship between a plurality of flows of packets addressed to the mobile communication device and destination IP addresses at a plurality of interfaces of the mobile communication device is previously determined between the mobile communication device and the mobility management device and / or the relay node. Steps to set,
Requesting the mobile management device and / or relay node to use the correspondence from the mobile communication device;
When the mobility management device and / or the relay node receives the request, a plurality of flows of packets addressed to the mobile communication device are selectively selected as each destination IP address of the mobile communication device based on the correspondence relationship. The step of transferring,
Communication method having.
In a communication system in which a mobility management device and / or a relay node of a mobile communication device transfers a packet addressed to the mobile communication device for a mobile communication device having a plurality of interfaces.
A correspondence relationship between a plurality of flows of packets addressed to the mobile communication device and destination IP addresses at a plurality of interfaces of the mobile communication device is previously determined between the mobile communication device and the mobility management device and / or the relay node. Means for setting;
Means for requesting the mobile management device and / or the relay node to use the correspondence relationship from the mobile communication device;
When the mobility management device and / or the relay node receives the request, a plurality of flows of packets addressed to the mobile communication device are selectively selected as each destination IP address of the mobile communication device based on the correspondence relationship. Means to transfer,
Communication system having.
The mobile communication device in a communication system in which a mobile management device and / or a relay node of the mobile communication device forwards a packet addressed to the mobile communication device for a mobile communication device having a plurality of interfaces,
Means for setting in advance correspondence between a plurality of flows of packets addressed to the mobile communication device and each destination IP address in a plurality of interfaces of the mobile communication device between the mobile management device and / or the relay node;
Means for requesting the mobility management device and / or the relay node to use the correspondence relationship;
A mobile communication device.
For the mobile communication device having a plurality of interfaces, the mobility management device of the mobile communication device is the mobility management device in a communication system in which a packet addressed to the mobile communication device is transferred.
Means for setting in advance a correspondence relationship between a plurality of flows of packets addressed to the mobile communication device and each destination IP address in a plurality of interfaces of the mobile communication device with the mobile communication device;
When receiving a request from the mobile communication device to use the correspondence relationship, a plurality of flows of packets destined for the mobile communication device are selectively transmitted to each destination IP address of the mobile communication device based on the correspondence relationship. Means to transfer,
A mobility management device.
For a mobile communication device having a plurality of interfaces, the mobility management device and / or relay node of the mobile communication device is the relay node in a communication system that forwards packets addressed to the mobile communication device,
Means for setting in advance a correspondence relationship between a plurality of flows of packets addressed to the mobile communication device and each destination IP address in a plurality of interfaces of the mobile communication device with the mobile communication device;
When a request is received from the mobile communication device to use the correspondence relationship, a plurality of flows of packets destined for the mobile communication device are selectively transmitted to each destination IP address of the mobile communication device based on the correspondence relationship. Means to transfer,
Having a relay node.