JP5918076B2 - Multi-home communication method and system - Google Patents

Description

  The present invention relates to a multi-home communication method and system for a mobile terminal, and more particularly to an SCTP multi-home communication method and system that enables quick multi-home communication by adding a communication path in a short time.

  Currently, mobile terminals MN (smartphones) equipped with an Android OS compatible with a plurality of wireless networks such as 3G, Wi-Fi, WiMAX, and LTE are in widespread use. General Android devices do not connect to multiple wireless networks at the same time, but connect to only one wireless network. If a failure or quality deterioration occurs in the connected wireless network, communication quality deterioration or communication session occurs. Disconnection occurs. In order to deal with such technical problems, Non-Patent Documents 1 and 2 are researching and discussing techniques for measuring the quality of wireless networks, surrounding radio field strength and congestion, and selecting (switching) a network to be connected. However, the communication path switching criterion and switching time are problematic.

  On the other hand, as a technology for switching communication paths at the transport layer, a connection using multiple communication paths is established between end hosts (multihome), and if a failure occurs on one communication path, the remaining communication paths SCTP (Stream Control Transmission Protocol), which realizes highly reliable communication by switching traffic, has been researched and developed and started in Non-Patent Documents 3 and 4.

  In the standard SCTP disclosed in Non-Patent Documents 3 and 4, even when a multi-home connection is established, only one communication path called “primary path” is actually used for data transfer. Therefore, when a failure or quality degradation occurs, other communication path switching criteria and switching time become problems as in the prior art.

  On the other hand, Non-Patent Document 6 proposes a method (Concurrent Multi-path Transfer (CMT) SCTP) for speeding up communication (throughput) by simultaneously transferring data through a plurality of communication paths. Also has the effect of making communication highly reliable. Further, Non-Patent Document 7 proposes a technique that makes it possible to realize addition / deletion of a communication path even in a NAT environment by using CMT-SCTP.

  Standard SCTP is experimentally implemented on many OSs such as FreeBSD and Windows (registered trademark), and in Non-Patent Document 5, a library that operates on Android (Linux (registered trademark)) has also been developed. However, most communication on the current Internet is based on TCP / UDP, and mobile communication services for general users using SCTP have not been developed. Therefore, in order to realize SCTP communication end-to-end, existing servers and computer programs need to be compatible with SCTP communication.

Fukuyama et al., "Proposal of a method to move seamlessly between mobile phone network and wireless LAN in IPv4 mobile communication," Multimedia, Distributed Cooperation and Mobile Symposium 2011 Proceedings, pp.1115-1120, 2011. Access Network Discovery and Selection Function (ANDSF) RFC 3286-An Introduction to the Stream Control Transmission Protocol RFC 2960-Stream Control Transmission Protocol SCTP library (sctplib) [URL]: http://www.sctp.de/sctp-download.html J. R. Iyengar, P. D. Amer, and R. Stewart, `` Concurrent Multipath Transfer Using SCTP Multihoming Over Independent End-to-End Paths, '' IEEE / ACM Transactions on Networking, Vol. 14, No. 5, Oct 2006. RFC5061-Streaming Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration

  In SCTP, a single communication path (primary path) is connected between end hosts, and after establishing an association (inter-host connection) using this, a multi-home connection is realized by adding another communication path. it can. For example, when a mobile terminal MN communicating with a server S via a 3G network moves into an area of a different type of wireless network such as Wi-Fi, the communication path via the 3G network is maintained while maintaining the communication path. -A new communication path via the Fi network can be added. However, as described in detail below, the conventional SCTP may have a problem that a communication path cannot be quickly added under a predetermined condition.

  Here, referring to the sequence flow of FIG. 7, the mobile terminal MN having three interfaces a1, a2, and a3 respectively corresponding to the three communication methods 3G, Wi-Fi (registered trademark), and WiMAX (registered trademark). Explains the problems of conventional SCTP using SCTP as an example of establishing a multihomed connection with server S assigned two global IP addresses (b1, b2) .

  (1) The mobile terminal MN establishes an association with the server S in a state where only the interface a1 is connected to the 3G network. The INIT chunk is sent to one IP address (here, b1) of the server S via.

  The server S receiving this INIT chunk returns all the IP addresses (b1, b2) assigned to it in the INIT-ACK chunk at time t2 in accordance with the standard specification of SCTP. Communication paths (primary paths) [a1-b1] are connected. Thereafter, at time t3 and t4, the mobile terminal MN and the server S establish an association by transmitting and receiving a COOKIE-ECHO / COOKIE-ACK chunk for authentication processing using the communication path [a1-b1]. .

  At this time, in SCTP, each end host is designed to manage communication parameters such as communication path status (ACTIVE / INACTIVE), chunk retransmission interval, and error counter for each destination IP address to the communication partner. That is, in SCTP, each communication path is not managed by a pair of source and destination IP addresses, but managed only by a destination IP address. For this reason, after successfully establishing an association with the server S, the mobile terminal MN transmits HEARTBEAT from the interface a1 to the IP address b2 of the server S at time t5, and HEARTBEAT-ACK is returned at time t6. Then, it is recognized that all interfaces including other interfaces a2 and a3 that are not actually confirmed to communicate can communicate with the IP address b2 of the server S. In addition, for communication parameters set in units of paths such as error counters and congestion windows, the value at the time of communication via the communication path [a1-b2] with the same destination IP address (b2) is the same as that of other unconnected communication. Applied to paths [a2-b2] and [a3-b2].

  (2) Next, the situation where the mobile terminal MN enters the Wi-Fi network area where there is actually no connectivity to the Internet and the interface a2 is activated, that is, the state of the interface a2 of the mobile terminal MN is from DOWN Consider a situation where the IP address has been dynamically assigned and changed to UP.

  Since the mobile terminal MN recognizes that the IP address b2 has communication with the server S, ASCONF (Address Configuration for adding a communication path between its own interface a2 and the IP address b2 of the server S is used. ) The chunk is sent from the interface a2 to the IP address b2 at time t7. However, the ASCONF does not arrive at the server S because the connected Wi-Fi network has no connectivity to the Internet.

  When the mobile terminal MN cannot receive a reply (ASCONF-ACK) from the server S to the sent ASCONF chunk within a certain time, it repeats the retransmission of the ASCONF chunk at a uniquely calculated time interval (retransmission timeout time), and then When the number of retransmissions (error counter) exceeds the upper limit, the status of IP address b2 is determined to be “INACTIVE (unreachable)” at time t8.

  Thereafter, at time t9, the mobile terminal MN sends out an ASCONF chunk for adding an address via the primary path [a1-b1]. However, the server S recognizes the ASCONF chunk from the registered interface a1. Therefore, the reception of the ASCONF is ignored. This is because the transmission process via the primary path is a process for maintaining the continuity of the sequence number of the ASCONF chunk received by the server S, and there is no effect related to address addition (in SCTP, the continuity of the sequence number of the ASCONF is not To be considered).

  After that, the mobile terminal MN performs communication confirmation to the IP address b2 that is set to “INACTIVE”, so that the mobile terminal MN sends the IP address b2 from the interface a1 or a2 to the IP address b2 at a uniquely calculated time interval (usually every several tens of seconds). Repeat HEARTBEAT transmission. At this time, which of the interfaces a1 and a2 becomes the HEARTBEAT transmission source depends on the SCTP implementation.

  (3) When HEARTBEAT is transmitted from the interface a1 of the mobile terminal MN, the communication of the HEARTBEAT succeeds, so the mobile terminal MN determines that the path to the IP address b2 is “ACTIVE” again, and the IP from the interface a2 ASCONF chunk is sent to address b2, but in actuality communication via a2-b2 is not successful. As a result, HEARTBEAT communication success with respect to interfaces a1 to b2 and ASCONF chunk communication failure with respect to interfaces a2 to b2 are repeated.

  On the other hand, when HEARTBEAT is transmitted from the interface a2, since HEARTBEAT communication is not successful, retransmission of HEARTBEAT is repeated. Here, in any case, the communication (state) confirmation from the mobile terminal MN to the IP address b2 is performed based on the HEARTBEAT transmission interval (usually a maximum of several tens of seconds). .

  (4) After that, the mobile terminal MN enters the area of the Wi-Fi network that can be connected to the Internet, and the interface a3 is enabled and given an IP address, or another interface that can connect the interface a2 to the Internet. Consider a situation where you are connected to a Wi-Fi network.

  Here, when the mobile terminal MN adds a communication path using the interface a3, the mobile terminal MN recognizes a new connection by changing the IP address or changing the interface state (UP / Down). Immediately try to add a new communication path [a3-b2] or [a2-b2]. However, as described above, the communication confirmation of the communication path [a2-b2] from the mobile terminal MN to the IP address b2 of the server S is performed regardless of the interfaces a1, a2, and a3 used by the mobile terminal MN, and the HEARTBEAT transmission interval. Because it is implemented in the ASCONF chunk cannot be sent immediately. That is, for the IP address b2 with the status “INACTIVE”, ASCONF Add cannot be transmitted until time t10 when the HEARTBEAT is successfully communicated and the status is “ACTIVE”. For this reason, even if the mobile terminal MN becomes able to communicate with the server S via a new wireless network, a communication path cannot be immediately added.

  In addition, when HEARTBEAT is sent from the interface a1, even after the communication path to the IP address b2 is added, the communication parameters between the a1 and b2 (chunk retransmission interval, error counter, etc.) Since it is used as a parameter of another communication path having the same b2 but different communication quality, there arises a problem that management and control of the state of the communication path in SCTP becomes inefficient.

  The first object of the present invention is that when the network environment of the mobile terminal transitions from a state in which communication with the server side is impossible to a state in which communication is possible, a communication path addition request (ASCCONF Add) is required without waiting for communication confirmation by HERTBEAT. ) Can be sent immediately to enable a quick multihome connection.

  The second object of the present invention is to make the communication parameter of the communication path added for multi-home connection independent of the communication parameter of the communication path connected earlier, so that the added communication path This is to prevent communication parameters that have already been connected under different network environments from being applied.

  To achieve the above object, the present invention establishes a multi-home connection via a wireless network by SCTP between one node having a plurality of interfaces and the other node assigned a plurality of IP addresses. The multihome communication method is characterized in that the following measures are taken.

  (1) In one node, the first interface transmits an initialization request addressed to the first address of the other node, and the other node responds to this to establish the association by connecting the first communication path. A procedure for requesting addition of a communication path to the second address of the other node from within the area of the network to which the second interface is connected in one node; If the connection with the network is disconnected without succeeding in adding the communication path, the procedure for setting the status of the second address to ACTIVE (UNCONFIRMED) and the status of the one node at the status of ACTIVE (UNCONFIRMED) There is a procedure for sending an addition request to the second address without confirming communication and adding a communication path.

  (2) When a communication path to the second address is successfully added, a procedure for initializing communication parameters related to the second address is further provided in the one and the other nodes.

According to the present invention, the following effects are achieved.
(1) In the standard specification of SCTP, when adding a communication path (secondary path) from the mobile terminal side between the mobile terminal / server with which the association has been established by connecting the primary path, the status is not confirmed because the communication has not been confirmed. For an “INACTIVE” IP address, even if the mobile terminal moves to a network environment where communication with the IP address can be performed, a communication path addition request (ASCONF) cannot be sent immediately. ASCONF can only be sent after communication to the IP address has been confirmed and the status of the IP address has changed to “ACTIVE”.

  On the other hand, in the present invention, the status of the IP address that has failed to communicate is set to “ACTIVE (UNCONFIRMED)” instead of “INACTIVE” defined in the standard specification of SCTP, and ASCONF in the “ACTIVE (UNCONFIRMED)” SCTP is extended so that can be sent. Therefore, when attempting to connect a communication path to the IP address, ASCONF can be sent immediately without waiting for communication confirmation by HERTBEAT, and quick multipath communication is possible.

  (2) In the standard specification of SCTP, the communication parameters set for the communication path with a certain destination IP address are subsequently carried over to the communication path connected to the same destination IP address via a different network. On the other hand, in the present invention, when a communication path is connected to the same destination IP address as before, SCTP is extended so that the communication parameters are initialized. Therefore, it is possible to prevent a decrease in communication efficiency due to communication parameters having different communication environments and conditions being set unconditionally to other communication paths because the destination IP address is the same.

1 is a block diagram of a first embodiment of an SCTP communication system according to the present invention. It is the figure which showed an example of the network configuration to which this invention is applied. It is the figure which showed another example of the network structure to which this invention is applied. It is the sequence flow which showed the procedure of the multihome connection which concerns on 1st Embodiment of this invention. It is a block diagram of 2nd Embodiment of the SCTP communication system which concerns on this invention. It is the sequence flow which showed the procedure of the multihome connection which concerns on 2nd Embodiment of this invention. It is the sequence flow which showed the procedure of the conventional multihome connection.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. As shown in FIG. 2, the present invention provides a procedure for making communication highly reliable in a system that performs multi-home communication based on SCTP between a server computer program capable of installing dedicated software and a mobile terminal MN. (Processing procedure in SCTP-based communication software in the figure).

  In addition, as shown in Fig. 3, a protocol conversion server is installed in the IP network, and SCTP communication and TCP communication are converted, so that SCTP can be used as a base without changing existing server computers. A technique for realizing the multihomed communication system is also conceivable. The present invention can also be applied to a system that communicates with an existing server computer via such a protocol conversion server.

  FIG. 1 is a block diagram showing a configuration of the first embodiment of the SCTP communication system according to the present invention, and illustrations of components unnecessary for the description of the present invention are omitted. Here, a multihome connection from the mobile terminal MN to the server S will be described as an example.

  In each network node of the mobile terminal MN and the server S, an IP stack composed of an interface layer, a network layer, a transport layer, and an application layer is mounted, and SCTP is adopted as a transport layer protocol. Each SCTP of the mobile terminal MN and the server S is provided with an extended function unique to the present invention in addition to the standard function for multi-home connection that connects a plurality of communication paths 10 with one association 11, thereby providing a communication path 10. Multi-home communication is enabled by quick addition of.

  In the transport layer (SCTP) of the mobile terminal MN, the first extension unit 12 changes the network environment of the mobile terminal MN from a state where communication with the IP address assigned to the server S is impossible to a possible state. At this time, the SCTP is extended so that a communication path addition request (ASCCONF Add) can be sent immediately without waiting for communication confirmation by HERTBEAT.

  FIG. 4 is a sequence flow showing a procedure of multihome connection between the mobile terminal MN / server S having the extended function. Here, a mobile terminal MN equipped with three interfaces a1, a2, and a3 respectively corresponding to three communication methods 3G, Wi-Fi (registered trademark), and WiMAX (registered trademark) has two global IP addresses (b1, The procedure for establishing multi-home connection by SCTP with the server S to which b2) is assigned will be described from the state where only the interface a1 of the mobile terminal MN is connected to the 3G network.

  (1) Since the mobile terminal MN establishes the association 11 with the server S, at time t1, one IP address (here, b1) of the server S is transmitted from the interface a1 through the 3G network according to its routing setting. Send an INIT chunk to The server S that has received this INIT chunk returns all the IP addresses (b1, b2) assigned to it at time t2 in the INIT-ACK chunk and returns the first communication path [a1- b1] is connected.

  Next, at time t3 and t4, the mobile terminal MN and the server S establish the association 11 by transmitting and receiving a COOKIE-ECHO / COOKIE-ACK chunk for authentication processing using the communication path [a1-b1]. To do. Each end host manages communication parameters such as communication path [a1-b1] status (ACTIVE / INACTIVE), chunk retransmission interval, and error counter for each destination IP address of the communication partner.

  After that, when HEARTBEAT is transmitted from the interface a1 to the IP address b2 of the server S and HEARTBEAT-ACK is returned, the server S receives the communication from all the interfaces including the other interfaces a2 and a3 that are not actually confirmed to communicate. It is recognized that it can communicate with the IP address b2. Also, with respect to communication parameters set in units of paths such as error counters and congestion windows, values at the time of communication using the communication path [a1-b2] are other unconnected communication paths [a2-b2], [a3-b2 Applies to

  (2) Next, the mobile terminal MN newly enters the area of the Wi-Fi network, the state of the interface a2 changes from DOWN to UP (valid), the IP address is dynamically assigned, and the IP of the server S Consider a case where a communication path connected to address b2 is added.

  Since the mobile terminal MN recognizes that the IP address b2 of the server S has communicability, an ASCONF (Address Configuration) chunk for adding a communication path [a2-b2] is added from the interface a2 at time t5. Send to IP address b2. However, the ASCONF does not arrive at the server S because the connected Wi-Fi network has no connectivity to the Internet. When the mobile terminal MN cannot receive a reply (ASCONF-ACK) from the server S to the sent ASCONF chunk within a certain time, it repeats the retransmission of the ASCONF chunk at a uniquely calculated time interval (retransmission timeout time), and then When the number of retransmissions (error counter) exceeds the upper limit, at time t6, the status of IP address b2 is set to “INACTIVE” based on the standard specification of SCTP.

  Thereafter, when the mobile terminal MN moves out of the area of the Wi-Fi network and the assigned IP address becomes invalid at time t7, if the status of the IP address b2 is the conventional SCTP standard specification In this embodiment, “INACTIVE” is set to “ACTIVE (UNCONFIRMED)” by the first extended function unit 12.

  In the standard specification of SCTP, not only data transmission but also transmission of ASCONF chunk is not explicitly permitted under “ACTIVE (UNCONFIRMED)”. On the other hand, in this embodiment, when the IP address becomes invalid, the status is `` ACTIVE (UNCONFIRMED) '', and the ASCONF chunk is not subjected to the communication confirmation by HERTBEAT under the `` ACTIVE (UNCONFIRMED) ''. SCTP has been extended to allow sending.

  (3) At time t8, ASCONF Delete requesting deletion of the communication path related to the interface a2 is transmitted from the interface a2 to the IP address b2 based on the standard specification of SCTP. At time t9, ASCONF ACK is returned from IP address b2 to interface a2 as a response to the deletion request.

  (4) After that, at time t10, the mobile terminal MN moves into the network area of the interface a2 or a3.For example, when the addition of a communication path from the interface a2 to the IP address b2 of the server S is requested, Since the status of the IP address b2 is “ACTIVE (UNCONFIRMED)”, ASCONF Add can be transmitted immediately from the interface a2 of the mobile terminal MN with the IP address b2 of the server S as the destination without waiting for the communication confirmation by HEARTBEAT. When ASCONF ACK is returned from the IP address b2 of the server S to the interface a2 of the mobile terminal MN at time t12, the communication path [a2-b2] is connected between the mobile terminal MN and the server S.

  At time t13, HERTBEAT is transmitted from the interface a2 of the mobile terminal MN with the IP address b2 of the server S as the destination. At time t14, HERTBEAT-ACK is returned from the IP address b2 of the server S to the interface a2 of the mobile terminal MN, and thereafter, transmission / reception of HERTBEAT / HERTBEAT-ACK is repeated at a predetermined cycle.

  According to this embodiment, SCTP is expanded so that the status of the IP address that failed to connect the communication path becomes “ACTIVE (UNCONFIRMED)” instead of “INACTIVE” defined in the standard specification of SCTP. Next, when trying to connect a communication path to the IP address, ASFONF can be sent immediately without waiting for communication confirmation by HERTBEAT, and quick multipath communication becomes possible.

  FIG. 5 is a block diagram showing the configuration of the second embodiment of the SCTP communication system according to the present invention. Here, the configuration unnecessary for the description of the present invention is omitted.

  In the present embodiment, the second extension unit 13 is provided in the transport layer (SCTP) of the mobile terminal MN, and the communication path parameters added for the multihome connection are obtained from the parameters of the communication path connected previously. It is characterized in that the SCTP is extended so that the parameter of the communication path that has been connected first in a different network environment is not applied to the added communication path by making it independent.

  FIG. 6 is a sequence flow showing the operation of the second embodiment of the present invention. Since the procedure up to time t11 is the same as or equivalent to that of the first embodiment, the description thereof is omitted.

  In the standard specification of SCTP, when a communication path is newly added, as a communication parameter, parameters of other communication paths (a1-b2) that are connected first and have the same destination IP address (here, b2) are used. However, it is inherited regardless of differences in communication environment and conditions. On the other hand, in this embodiment, when ASCONF Add and ASCONF ACK are transmitted and received between the server S and the mobile terminal MN at time t11 and t12, and the communication path is added, the server S returns the ASCONF ACK return timing. At (t11) and at the reception timing (t12) of the ASCONF ACK in the mobile terminal MN, the communication parameter related to the destination IP address b2 is initialized.

  As described above, in this embodiment, when a communication path having the same destination IP address is newly added, SCTP is expanded so that the parameter is initialized, and the parameter of the existing communication path is added to the added communication path. Cannot be taken over. Therefore, it is possible to prevent a decrease in communication efficiency due to another communication parameter having a different communication environment and conditions being taken over by the added new communication path.

  DESCRIPTION OF SYMBOLS 10 ... Communication path, 11 ... Association, 12 ... 1st expansion part, 13 ... 2nd expansion part

Claims (4)

In a multihome communication method for establishing a multihome connection via a wireless network by SCTP between one node having a plurality of interfaces and the other node assigned with a plurality of IP addresses,
In one node, the first interface sends an initialization request addressed to the first address of the other node, and the other node responds to this by establishing the association by connecting the first communication path;
In one node, from within the network area of the second interface is connected, the procedure in which the second interface requests the additional communication paths addressed second address of the other node,
If one of the nodes disconnects from the network without successfully adding a communication path to the second address, the status of the second address is set to ACTIVE (UNCONFIRMED);
SCTP multi-homed communication including a procedure for adding a communication path by sending an addition request to the second address whose status is ACTIVE (UNCONFIRMED) in one node without confirming communication Method.   The SCTP according to claim 1, further comprising a step of initializing communication parameters related to the second address in the one and the other nodes when the communication path is successfully added to the second address. Multi-home communication method. In a multi-home communication system comprising a plurality of interfaces and establishing a multi-home connection via a wireless network by SCTP with a connection destination node assigned a plurality of IP addresses,
Means for transmitting an initialization request addressed to the first address of the connection destination node from the first interface, connecting the first communication path, and establishing an association with the connection destination node;
Means for requesting the addition of a communication path from the area of the network to which the second interface is connected to the second address of the connection destination node.
Means for setting the status of the second address to ACTIVE (UNCONFIRMED) when the connection with the network is cut without successfully adding a communication path to the second address;
A SCTP multihomed communication system comprising means for adding a communication path by transmitting an addition request to the second address whose status is ACTIVE (UNCONFIRMED) without confirming communication.   4. The SCTP multihomed communication system according to claim 3, further comprising means for initializing communication parameters related to the second address when the communication path is successfully added to the second address.