WO2009116276A1 - Procédé de communication, système de communication, nœud de communication, dispositif de communication mobile, dispositif de gestion mobile et nœud relais - Google Patents

Procédé de communication, système de communication, nœud de communication, dispositif de communication mobile, dispositif de gestion mobile et nœud relais Download PDF

Info

Publication number
WO2009116276A1
WO2009116276A1 PCT/JP2009/001200 JP2009001200W WO2009116276A1 WO 2009116276 A1 WO2009116276 A1 WO 2009116276A1 JP 2009001200 W JP2009001200 W JP 2009001200W WO 2009116276 A1 WO2009116276 A1 WO 2009116276A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
mobile communication
communication device
notification
packet
Prior art date
Application number
PCT/JP2009/001200
Other languages
English (en)
Japanese (ja)
Inventor
阿相啓吾
リムチュンキョンベンジャミン
ンーチャンワー
コーティエンミンベンジャミン
Original Assignee
パナソニック株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック株式会社 filed Critical パナソニック株式会社
Publication of WO2009116276A1 publication Critical patent/WO2009116276A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]

Definitions

  • 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.
  • a mobile node can permanently maintain one Internet Protocol (IP) address even if the connection point to the Internet is changed. it can.
  • IP Internet Protocol
  • This permanent IP address in MIPv6 is the address in the mobile node's home network domain and is known as the home address.
  • 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.
  • BU binding update
  • the home agent intercepts the packet addressed to the mobile node's home address and tunnels the packet to the care-of address.
  • the host is included in the mobility management domain. For this reason, MIPv6 is known as a host-based mobility management protocol.
  • 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.
  • MCoA Multiple Care-of Addresses Registration
  • 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.
  • BID Biting Unique Identification
  • This BID is assigned to an interface or care-of address and is bound to one home address of the mobile node and router.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the HA 102 can transmit various option packets for the MN 101 using the care-of address CoA1 as a destination address.
  • the source (Scr) address is the address (HA.Addr) of the HA 102
  • the destination (Dest) address is CoA1
  • the option contents are BRR (Binding Refresh Request) and FIO (Flow It indicates that two types of packets (Identification Option) are transmitted.
  • this method has a problem that the data amount of option packets transmitted from the HA 102 to the MN 101 becomes very large.
  • 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).
  • Patent Documents 1 and 2 describe the advantages of using an IP address to present an identifier.
  • 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.
  • an IP address is used to represent a domain name in the 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.
  • 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.
  • 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.
  • a correspondence relationship between an arbitrary IP address and a notification purpose cannot be set in a system in which a mobile node generates an arbitrary IP address based on an arbitrary prefix acquired from an arbitrary domain.
  • the correspondence relationship between the IP address and the notification purpose cannot be set.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the message 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. .
  • an arbitrary IP address can be set to represent the interface in addition to the notification contents.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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;
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • CN Correspondent Node
  • HA home agent
  • 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.
  • the first IF 1010 of the MN 101 is assumed to associate with the first AR 111 of the external network domain 11.
  • 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.
  • this address generation can be realized by using automatic address generation described in 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.
  • 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.
  • 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.
  • the HA 102 is a PDN-GW (Packet Data Network Gateway) existing in the 3GPP network
  • the ARs 111 and 112 are S-GW (Serving Gateway) or ePDG.
  • S-GW Serving Gateway
  • ePDG Serving Gateway
  • AGW Access Gateway
  • MN101 User Equipment
  • 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.
  • 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).
  • the 3GPP network uses GTP (Generic Tunnelling Protocol) or PMIP (PMIP: Proxy Mobile IP) to connect to the HA 102
  • PMIP Proxy Mobile IP
  • 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.
  • the second IF 1011 generates a care-of address (MN.CoA2) used in the external network domain 11.
  • the MN 101 binds the care-of address (MN.CoA2) to the home address of the MN 101 in the HA 102.
  • 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)
  • the second is that that passes through the second AR 112 using the care-of address (MN.CoA2). Routing path to be
  • PMIP network-based mobility management
  • 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.
  • 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.
  • 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.
  • MN.Home.Prefix the network prefix assigned to the mobile node
  • MN.Home.Prefix the allowed address configuration mode
  • 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.
  • 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.
  • 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.
  • PBU proxy BU
  • 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.
  • the MN 101 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.
  • the purpose of the IP address is mostly used for packet routing.
  • the second communication node 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.
  • the intermediate node 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.
  • 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.
  • 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.
  • the MN 101 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.
  • 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.
  • 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.
  • the packet size of the message increases.
  • 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.
  • 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.
  • 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.
  • the HA 102 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.
  • the large packet 20 can be divided into a plurality of small packets 20 that can be managed.
  • each packet 20 requires a packet header 21, the overhead used to transmit a plurality of notification packets 20 increases.
  • 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 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.
  • IP address 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the network interface 300 represents layer 1 (physical layer) and layer 2 (data link layer) communication components, firmware, drivers and profiles.
  • 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.
  • 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.
  • 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.
  • the database 302 stores a list of IP addresses used for notification purposes.
  • a signal / data path 306 allows trigger signals and packets to be exchanged between the database 302 and the address checking engine 303.
  • the address checking engine 303 can query the IP address list of the database 302 via the signal / data path 306.
  • the address checking engine 303 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.
  • the packet filtering rule also called a routing rule
  • 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.
  • 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.
  • BU binding update
  • 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.
  • the notification trigger message 40 is transmitted by a BU message.
  • the HA 102 receives the notification trigger message 40, it understands that the MN 101 wants to represent the notification using the IP address.
  • 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.
  • the HA 102 If this IP address is used by this mapping, an action for one or a plurality of communication nodes is instructed.
  • 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.
  • 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.
  • the HA 102 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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 (Ste 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.
  • 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.
  • this process ends (step S63), and the IP address is used when a notification message is transmitted to the MN 101.
  • the MN 101 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.
  • MN101 as a prefix 3FFF: B023: 8a2e: 73F / 124 124 bits are assigned.
  • 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.
  • 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).
  • 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).
  • step S73 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.
  • step S74 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).
  • 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.
  • the address semantic list 50 is checked and the destination address MN.
  • 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.
  • step S75 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).
  • 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.
  • 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.
  • the HA 102 notifies the action using the CoA of the MN 101.
  • the HA 102 transmits the encapsulated packet.
  • the original address may be used.
  • the HA 102 holds a plurality of addresses, and configures the address semantic list 50 by associating them with actions for notification purposes.
  • 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.
  • the HA 102 instructs the MN 101 to perform an action.
  • 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.
  • 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.
  • a destination address may be used instead of using the source address of the encapsulated packet.
  • the HA 102 holds a plurality of addresses, and configures the address semantic list 50 by associating them with actions for notification purposes.
  • the MN 101 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the prefix used in the external network domain 11 can be known to the HA 102.
  • 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.
  • 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.
  • 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.
  • LMA and HA 102 indicate that the packet is carrying VoIP (Voice over IP) traffic.
  • CoA7 implies.
  • the HA 102 transmits a VoIP packet addressed to the MN 101
  • the HA 102 uses the MN.
  • CoA7 is used.
  • 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.
  • QoS quality of service
  • 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.
  • 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.
  • the MN 101 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.
  • 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.
  • 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.
  • the BID is used to indicate the target interface.
  • 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.
  • 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.
  • 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.
  • the HA 102 determines to transmit the binding / refresh request message for the second IF 1011 via the first IF 1010.
  • the HA 102 attaches the BID2 of the second IF 1011 to the binding / refresh request message.
  • 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.
  • the packet size increases.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the type of each interface such as a cellular interface, a WLAN interface, a WiMAX interface, or a Bluetooth interface may be used.
  • 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.
  • 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.
  • 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
  • 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.
  • the notification trigger message 40 has a plurality of mappings in which IP addresses are associated with notification purposes.
  • this IP address mapping is generated by the MN 101.
  • 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.
  • 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.
  • MN 101 confirms that a message is applied to all IFs of MN 101. It is configured as represented by CoA1.
  • 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.
  • 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.
  • the identifier 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first IF 1010 of MN 101 is MN.
  • CoA1 is assigned and the second IF 1011 is MN.
  • CoA2 is assigned.
  • the second IF 1011 is in the sleep mode for power saving.
  • 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.
  • the MN Attach CoA1. This attachment is known as packet encapsulation.
  • the MN 101 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.
  • the same function is realized using an IP address.
  • the first IF 1010 is MN. To CoA1 and MN. Both packets addressed to CoA2 can be received.
  • 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.
  • the MN 101 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.
  • 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.
  • GTP Generic Tunnelling Protocol
  • PMIP is used as a means for establishing a link between two entities.
  • GTP can also be used between multiple entities.
  • the user equipment (UE) establishes an end-to-end tunnel with a PDN-GW (packet data network gateway) using GTP.
  • PDN-GW packet data network gateway
  • S-GW serving gateway
  • UE user equipment
  • 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.
  • FIG. 11 shows a case where the external network domain 11 has a network-based mobility management function.
  • an entity called a local mobility anchor (LMA) 110 acts as a geographical anchor point for each mobile node.
  • 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.
  • the AR 111 functions as a MAG (Mobile Anchor Gateway) and transmits a proxy BU (PBU) message to the LMA 110.
  • PBU proxy BU
  • 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.
  • the MN 101 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.
  • 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.
  • 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.
  • the HA 102 or LMA 110 is a PDN-GW (Packet Data Network Gateway)
  • the ARs 111 and 112 are S-GW (Serving Gateway) or ePDG (Evolved Packet Data). Gateway)
  • AGW Access ⁇ Gateway
  • MN101 User Equipment
  • 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.
  • 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. 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)
  • the IF 1011 is a Non3GPP network ( It may be connected to an external network domain in FIG.
  • the 3GPP network is connected to the HA 102 using GTP (Generic Tunnelling Protocol) or PMIP
  • the Non3GPP network is connected to the LMA 110 using PMIP.
  • 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.
  • 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.
  • 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).
  • FID1 a signaling flow
  • FID2 a video flow
  • FID3 a voice flow
  • the MN 101 maps each FID to a care-of address of each interface in the message of Non-Patent Document 5.
  • the signaling flow (FID1) is mapped to the care-of address of the IF 1010
  • 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.
  • 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).
  • WLAN wireless local area network
  • the MN 101 does not notify 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.
  • Non-Patent Document 6 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the label L1 is attached to the voice flow from the CN 130.
  • 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.
  • 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.
  • 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.
  • the message 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • LMA 110 can perform flow filtering based on the IP address of the packet.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the HA 102 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).
  • 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).
  • the MN 101 determines to perform flow filtering in the LMA 110 on the data flow from the CN 130.
  • 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.
  • 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).
  • 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.
  • the MN 101 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.
  • 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.
  • 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).
  • 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> 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.
  • 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.
  • option type 11 for example, “routing rule generation” is indicated.
  • 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.
  • 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.
  • the encapsulation unit 12002 includes a packet in which the MN 101 requests transfer from the HA 102 to the other party.
  • 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”.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the scope of this prior art is that the mobile node only notifies the entity of the action (routing rule creation and modification).
  • 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.
  • 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.
  • MN 101 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.
  • MN 101 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.
  • 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.
  • 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).
  • the MN 101 notifies the HA 102 to self-generate a notification IP address using a flag.
  • 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.
  • the MN 101 transmits the notification trigger message 40 to the HA 102 in the signaling S100 shown in FIG.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a bit in the IP address is used to instruct the IP address self-generation method.
  • the MN 101 can instruct the HA 102 using the notification space bit 120011 shown in FIG.
  • 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.
  • 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.
  • 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.
  • 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
  • the IF 1010 is connected to the home network domain 10 that is a 3GPP network using GTP or PMIP.
  • 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.
  • the HA 102 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.
  • 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.
  • 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.
  • 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.
  • the MN 101 when the MN 101 needs to notify the HA 102 of an action, the above-described method can be used.
  • the MN 101 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the HA 102 functions as an LMA for the MN 101.
  • the HA 102 functions as an LMA for a 3GPP network connection and functions as an HA for a Non3GPP network.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • 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.
  • 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.

Landscapes

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

Abstract

L'invention concerne une technique de définition d'une correspondance entre une adresse IP arbitraire et un objectif de rapport, lorsqu'une adresse IP est transmise en tant que contenu d'un rapport d'un message de rapport entre nœuds. Selon la technique, en cas de réception d'un message de déclenchement de rapport (40) provenant d'un MN (101), un HA (102) définit une liste de significations d'adresse (50), obtenue en mettant en correspondance l'adresse IP avec le contenu du rapport entre le HA (102) et le MN (101). Lors de la transmission d'un contenu de rapport défini dans la liste de significations d'adresse (50), le HA (102) définit l'ensemble d'adresses IP de la liste de significations d'adresse (50) en tant qu’adresse de destination d'un paquet destiné au MN (101). Le MN (101) déchiffre le contenu du rapport à partir de l'adresse de destination du paquet.
PCT/JP2009/001200 2008-03-19 2009-03-18 Procédé de communication, système de communication, nœud de communication, dispositif de communication mobile, dispositif de gestion mobile et nœud relais WO2009116276A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2008-071779 2008-03-19
JP2008071779 2008-03-19
JP2009000907 2009-01-06
JP2009-000907 2009-01-06

Publications (1)

Publication Number Publication Date
WO2009116276A1 true WO2009116276A1 (fr) 2009-09-24

Family

ID=41090691

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/001200 WO2009116276A1 (fr) 2008-03-19 2009-03-18 Procédé de communication, système de communication, nœud de communication, dispositif de communication mobile, dispositif de gestion mobile et nœud relais

Country Status (1)

Country Link
WO (1) WO2009116276A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005085078A (ja) * 2003-09-10 2005-03-31 Fuji Xerox Co Ltd 省電力対応装置を含むネットワークシステム
WO2006093288A1 (fr) * 2005-03-04 2006-09-08 Matsushita Electric Industrial Co., Ltd. Nœud de communication et méthode de contrôle de communication
JP2007306206A (ja) * 2006-05-10 2007-11-22 Advanced Telecommunication Research Institute International 通信システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005085078A (ja) * 2003-09-10 2005-03-31 Fuji Xerox Co Ltd 省電力対応装置を含むネットワークシステム
WO2006093288A1 (fr) * 2005-03-04 2006-09-08 Matsushita Electric Industrial Co., Ltd. Nœud de communication et méthode de contrôle de communication
JP2007306206A (ja) * 2006-05-10 2007-11-22 Advanced Telecommunication Research Institute International 通信システム

Similar Documents

Publication Publication Date Title
Liu et al. Distributed mobility management: Current practices and gap analysis
JP4431112B2 (ja) 端末及び通信システム
US8170010B2 (en) Multiple interface mobile node with simultaneous home- and foreign network connection
US7191226B2 (en) IP mobility in a communication system
US20120063428A1 (en) Interface Switching System, Mobile Node, Proxy Node, and Mobile Management Node
WO2009153943A1 (fr) Procédé de création d’antémémoire d’association, système de création d’antémémoire d’association, agent de rattachement et nœud mobile
US8879504B2 (en) Redirection method, redirection system, mobile node, home agent, and proxy node
WO2009116246A1 (fr) Procédé de communication, système de communication, nœud mobile, routeur d'accès
US20100268804A1 (en) Address allocation method, address allocation system, mobile node, and proxy node
JP2010521888A (ja) フロー識別用の鍵を使用した、モバイルｉｐのトンネリング・サポート
US8411658B2 (en) Mobile terminal and network node
US8824353B2 (en) Mobility route optimization in a network having distributed local mobility anchors
KR100929546B1 (ko) 패킷 데이터 전송
WO2010035464A1 (fr) Procédé d'attribution de préfixe, système d'attribution de préfixe et nœud mobile
US7813347B2 (en) System and method to enable combination of network controlled mobility and UE controlled mobility between different IP versions
US20100208663A1 (en) Communication system, mobile terminal, and network node
WO2008014719A1 (fr) Dispositif et procédé permettant d'exécuter une itinérance de noeud dans un réseau ip version 6
JP5016030B2 (ja) デュアルスタック移動体ノードがＩＰｖ４ネットワーク中でローミングするための方法と装置
KR100927940B1 (ko) 이동 네트워크에서 ｓｍｒ을 이용한 위치 등록 방법 및 패킷 전달 방법
EP1863251A1 (fr) Procédé et dispositif pour optimiser l'acheminement dans un système mobile IPv6 en maintenant la confidencialité des emplacements
WO2009116276A1 (fr) Procédé de communication, système de communication, nœud de communication, dispositif de communication mobile, dispositif de gestion mobile et nœud relais
JP2005033470A (ja) モバイルＩＰｖ６における経路削減のための方法
JP2005033469A (ja) モバイルＩＰｖ６における経路最適化のためのモバイルルータ及び方法
WO2007028311A1 (fr) Procede d'optimisation de la communication entre noeuds mobiles
JP2004289659A (ja) 移動通信システム、移動通信システムに使用する通信装置および移動ｉｐ端末

Legal Events

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

Ref document number: 09722548

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09722548

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP