JP5097620B2 - Multipath communication system - Google Patents

Description

  The present invention relates to a communication method using a plurality of communication paths in a communication device connected to a plurality of networks.

  With the development of wireless network technology, it has become possible to use multiple networks such as mobile phones, PHS, and wireless LANs in parallel in communication devices. However, in a communication device such as a mobile terminal on the premise of movement, even if there are multiple communication paths connected to multiple networks and the communication destination, the communication path used in the application layer is the user. Was limited to a single communication path via one of the selected networks. On the other hand, even if multipath communication is performed using multiple communication paths, the application layer has a technology that combines multiple communications in the transport layer in order to provide it as a single communication as before. (For example, see Patent Document 1).

Japanese Patent Laid-Open No. 2001-60956

  With the technology described in Patent Document 1, a communication device connected to a plurality of networks can communicate with the application layer as a single communication even if a plurality of communication paths are used for communication with a communication destination. Become. However, in order to bundle each communication in the transport layer, it is necessary to change the transport layer program such as TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) incorporated in the operating system. Communication such as Internet Control Message Protocol (ICMP) that does not use a layer is not considered.

  In addition, the movement of the communication device is not considered, and the communication continuation method in the application layer when the connected network is changed and the IP address for communication is changed is not considered.

  The present invention provides a communication device that enables multipath communication using a plurality of communication paths together without changing the transport layer.

  More specifically, a communication device is provided in which the application layer can process multipath communication as one communication without changing the transport layer.

  Further, even if the network to be connected is changed due to movement of the communication device or the like, the application layer provides a communication device capable of continuing communication.

  More specifically, the present invention comprises a virtual interface that allows a plurality of network interface devices and their device drivers to be viewed as one in the IP layer processing unit in the communication device on both the transmission side and the reception side, Data packets are transmitted and received via the virtual interface.

More specifically, a terminal having a plurality of network interface devices, each assigned a different network address,
An operating system, an application program, a device driver for a plurality of network interface devices, and a virtual interface program for connecting the operating system and the device driver, which are executed by the processor;
The operating system has an IP layer processing program that converts data handled by application programs and IP packets suitable for transmission and reception on the network.
The program that implements the virtual interface is
Relay processing of IP packets exchanged between the IP layer processing program and the device driver;
An IP layer processing interface as one device driver for the IP layer processing program;
A device driver interface for device drivers;
For each session, for a plurality of IP packets received from one IP layer processing interface, a distribution process is performed so as to be transmitted from any of a plurality of network interface devices, and a process for transmitting to a device driver;
A process for transmitting IP packets received by a plurality of network interface devices from one IP layer interface to an IP layer processing program is realized.

Furthermore, the terminal and the server are each provided with a multipath control program that is executed by a processor provided therein,
The terminal and server multipath control programs exchange messages with each other to check whether the communication partner device supports multipath communication and / or whether multipath communication using multiple network addresses is possible. I do.

  That is, at the time of transmission, the virtual interface distributes the data packet from the IP layer processing unit so as to be transmitted from any of the plurality of network interface devices, and at the time of reception, the data packet received by the plurality of network interface devices Collectively and pass to the IP layer processing unit as received by one network interface device. As a result, it is possible to provide a single communication to an application as a single communication using a plurality of communication paths with respect to a single communication session without changing the IP layer processing unit.

  In addition, communication is performed separately from application communication to check whether the communication device of the communication destination supports multipath communication and / or which communication path can be used for communication among multiple communication paths. Exchange messages for checking whether multipath communication is possible between devices, and messages for transmitting changes in the connected network. By sharing the status information through such message exchange, it becomes possible to continue communication in the application layer even when the IP address is changed.

  According to the present invention, it is possible to perform multipath communication using a plurality of communication paths without changing the transport layer.

  In addition, even if the network to be connected is changed due to movement of the communication device or the like, multipath communication can be continued.

  Hereinafter, embodiments of the present invention will be described. In the present embodiment, a communication device that is connected to a plurality of networks and whose IP address may change due to movement is called a terminal 107, and a communication device with a fixed IP address is called a server 108.

  FIG. 1 illustrates a system configuration and its program configuration in the present embodiment.

  The terminal 107 is equipped with a client application 102 and a multipath control 117 as application programs. The operating system 121 for controlling the terminal 107 includes TCP (Transmission Control Protocol) or UDP for data output from the application program. A transport layer processing unit 103 that performs transport protocol processing such as (User Datagram Protocol) and an IP layer processing unit 119 that converts data into IP packets are mounted.

  The terminal 107 includes three network interface devices that are physically connected to the network, and further includes a device driver that controls each network interface device. That is, the device driver A109 controls connection to the network A112 (for example, a cellular phone network), the device driver B110 controls the connection to the network B113 (for example, PHS network), and the device driver C111 controls the connection to the network C114 (for example, wireless LAN network). These networks A112, B113, and C114 are connected to a network D101 (for example, the Internet). The device driver 109 has an IP address I / FA of the network A112, the device driver 110 has an IP address I / FB of the network B113, the device driver 111 has an IP address I / FC of the network C114, Assume that each is assigned.

  Note that the number of network interface devices is not limited to three, and the present invention can be applied to a plurality of network interface devices. Also, one device driver may control one network interface device as described above, or may control a plurality of network interface devices that handle the same communication medium, or a plurality of devices that handle different communication media. The network interface device may be controlled.

  In the present embodiment, a program for connecting the device drivers A 109, B 110, and C 111 that control network interface devices actually connected to the network and the IP processing unit 119 is implemented as the virtual interface 104. The virtual interface 104 is assigned a cognitive IP A that is an IP address that can uniquely identify the terminal 107. The cognitive IP A does not need to belong to the network to which the terminal 107 is connected. The IP address I / FA, IP address I / FB, and IP address I / FC are IP addresses that belong to the network, and are determined by the network allocation policy (for example, DHCP). There is a cognitive IP address that is fixed (at least not changed during communication) regardless of network connection. Hereinafter, the IP address assigned to the virtual interface 104 is referred to as a cognitive IP address.

  The server 108 includes a server application 105 as an application program, a multipath control 118, and an operating system 122 similar to the terminal 107. The operating system 122 includes a transport layer processing unit 116 and an IP layer processing unit 120. is doing. The server 108 includes one network interface device connected to a physical network D101 (for example, the Internet) and its device driver D115. Further, it is assumed that an IP address I / FD is assigned to the device driver D115.

  The terminal 107 and the server 108 can be realized using a general computer having a CPU (also referred to as a processor), a memory, a fixed storage device, and an input / output interface. Further, the functions realized by the terminal 107 and the server 108 described below are realized in the terminal 107 and the server 108 by the CPU executing a program stored in a fixed storage device or memory.

  Each program may be stored in advance in a storage device in the computer, or introduced into the storage unit from another device via an input / output interface and a medium usable by the computer when necessary. May be. The medium refers to, for example, a storage medium that can be attached to and detached from the input / output interface, or a communication medium (that is, a network or a carrier wave or a digital signal that propagates through the network). In the following embodiments, the program will be described as an execution subject for convenience.

  Similarly to the terminal 107, the server 108 also implements a device driver program that connects the device driver 115 and the IP processing unit 120 as the virtual interface 106. It is assumed that the same address as the IP address I / FD assigned to the device driver D115 is assigned to the virtual interface 106 as the cognitive IP B.

  A network A112, a network B113, and a network C114 are also connected to the network D101, and there are three communication paths between the terminal 107 and the server 108 via the network A112, the network B113, or the network C114. When the terminal 107 moves, the IP address assigned to the device driver may be changed or disconnected from the network.

  The client application 102 in the terminal 107 and the server application 105 in the server 108 communicate by exchanging data. Although it is assumed that communication is started by transmitting data from the client application 102 to the server application 105, data is also transmitted from the server application 105 to the client application 102 after the communication is started.

  The data transmitted from the client application 102 is transferred to the transport layer processing unit 103 when the communication uses a transport protocol such as TCP or UDP. When the client application 102 uses communication such as ICMP (Internet Control Message Protocol) that does not use the transport protocol, the message is sent to the IP layer processing unit 119 without passing through the transport layer processing unit 103.

  In this embodiment, communication using a transport protocol will be described. However, the present invention can be applied even when the transport protocol is not used, considering the difference that the processing in the transport layer processing unit 103 is not performed. However, it is not limited to communication using a transport protocol. The data processed by the transport layer processing unit 103 is transferred to the IP layer processing unit 119 and converted into IP packets. In this embodiment, data obtained by converting data from the client application 102 or the server application 105 into an IP packet is called a data packet.

  The data packet is sent to the virtual interface 104, which communication path is used for transmission through the virtual interface 104, and the data packet is encapsulated so that it can actually flow through the network. Which communication path is used for transmission is determined at a rate according to the transmission rate of the available communication path by setting a transmission rate for each communication path in the terminal 107. The encapsulated data packet is sent to the server 108 via the network.

  The encapsulated data packet is received by the device driver D115 of the server 108 and passed to the virtual interface 106. The virtual interface 106 decapsulates (decapsulates) and takes out the data packet. The data packet is transferred to the transport layer processing unit 116, processed, and then transferred to the server application 105 for communication. Transmission of data packets from the server application 105 to the client application 102 is performed in the same manner.

  At the start of communication when the first data is transmitted from the client application 102, it is unclear which network can communicate with the server 108 that is the communication destination and whether multipath communication is possible. . Therefore, the program of the multipath control 117 of the terminal 107 and the program of the multipath control 118 of the server 108 communicate to check whether or not a multipath session can be established between the terminal 107 and the server 108, and if so, establish the multipath session. To do. The virtual interface 104 and the virtual interface 106 grasp the state of the multipath session, determine the destination network of the data packet, and encapsulate the destination network together.

  The multipath control 117 of the terminal 107 manages the state according to the state transition flow of FIG. 2, and the multipath control 118 of the server 108 manages the state according to the state transition flow of FIG.

  A multipath session refers to a state in which multipath communication can be performed between the communication apparatuses that perform communication from the start to the end of the multipath communication, that is, between the communication apparatuses. A path refers to a network in a state where packets can be transmitted and received between communication devices. It is assumed that a multipath session has been established if it is known that communication is possible on any one or more of a plurality of paths, and that multipath communication is supported.

  As the status of the multipath session, four states are defined for each communication partner: “Not established”, “Established”, “Established”, and “Not possible”. “Unestablished” is a state in which no session has been established, and it is unknown whether a communication path exists with the communication partner or multipath communication is supported (it is listed in the path management table). There is a possibility that there is a path through which packets can be transmitted and received). “Established” is a state in which session establishment has started for the communication partner but has not yet been completed, and it is unknown whether a communication path exists or multipath communication is supported. “Established” is a state in which the establishment of a multipath session with the communication partner has been completed, a communication path exists, and multipath communication is supported. “Not possible” is a state in which no communication path exists with the communication partner or multipath communication is not supported. Even if the path exists, it is determined that the session ends when there is no communication from the application and a predetermined time elapses. Also, even when all the paths constituting the multipath session no longer exist, it is determined that the session is terminated without performing the termination process.

  The state of the multipath session is held in the session management table 400 illustrated in FIG. Column 401 describes the IP address of the communication partner. An address to which the client 102 requests transmission is described as an IP address. This address is a cognitive IP address for a device that supports multipath communication, such as the terminal 107 or the server 108, but for a communication device that does not support it, the address assigned to the device driver of the communication partner It becomes. Column 402 describes the session state, and column 403 describes the remaining session time. If the session remaining time is already established, the remaining time from the last data packet transmission until the session holding time specified in advance is described. If the session status is not possible, enter the remaining time until the session re-establishment time specified in advance.

  Line 404 describes an example in which the communication partner is server A 108. The session state is established and the remaining session time is 30 seconds. Line 405 describes an example in which the communication partner is server B 108. The session state is not possible and the session re-establishment time is 20 seconds.

  FIG. 2 illustrates a state transition flow of the multipath control 117 of the terminal 107.

  The session state starts from step 201 where the state is not established 201. The process waits at step 202 until a communication start request is received. When a communication start request is received, the process proceeds to step 203, the row is added to the session management table, the session state is being established, and session start processing is performed at step 204. Session start processing is performed in parallel for each device driver. The device driver that is the target of session start processing is installed in the terminal 107, and all device drivers that control connection to the network (in FIG. 1, device drivers A to C that control connection to the networks A112 to C114). C).

  In the session start process, packets called messages are exchanged between the multipath control 117 of the terminal 107 and the multipath control 118 of the server 108. In the present embodiment, it is assumed that all messages are UDP packets. It is assumed that a predetermined port number is used as the message port number. In the session start processing, a session start request message 700 is transmitted from the terminal 107 to the server 108, and the multipath control 118 of the server 108 that has received the session start request message 700 returns a session start response message 900 to the terminal 107. When the multipath control 117 of the terminal 107 receives the session start response message 900, the multipath control 117 calculates a round trip time (hereinafter referred to as RTT) that is a time from transmission of the session start request message 700 to reception of the session start response message 900. , A session establishment message 1000 is transmitted to the server 108. When the server 108 receives the session establishment message 1000, the session start sequence ends.

  A session start processing flow of the multipath control 117 of the terminal 107 is shown in FIG. When a communication start request is received from the client application 102, in step 501, a device driver that has not been subjected to session start processing is specified from device drivers installed in the terminal 107, and a session start request message 700 is transmitted.

  In this embodiment, session start processing is performed for all device drivers connected to the network, but it is not always necessary to perform session start processing for all device drivers. The driver may be allowed to perform session start processing. When step 501 ends, the process proceeds to step 502 where a reception wait timer for the session start response message 900 is set.

  Here, FIG. 7 illustrates a packet format of the session start request message 700. 701 stores the message type and 702 stores the cognitive IP address. A path ID uniquely determined in the terminal 107 for each communication path is stored in 703, and a transmission rate according to a device driver used for transmission is stored in 704. 705 stores the transmission time of the session start request message 700 by the terminal 107. The transmission rate 704 is stored according to the transmission rate setting table 800 shown in FIG.

  The values set in the transmission rate setting table 800 are set by reading a transmission rate setting file set in advance by the user when the multipath control 117 is activated. A device driver name is described in 801 of the transmission rate setting table 800, and a transmission rate is described in 802.

  Next, FIG. 9 illustrates a packet format of the session start response message 900. 901 stores “session start response message” as a message type, and 902 stores the cognitive IP address of the server 108. In 903, the path ID stored in the path ID 703 of the session start request message 700 is stored. In 904, the transmission time from the terminal 107 stored in the transmission time column 705 of the session start request message 700 is stored as the transmission time 1. 905 stores the transmission time of the session start response message 900 of the server 108 as the transmission time 2.

  Returning to the explanation of FIG. 5, in step 503, it is checked whether the session start response message 900 is received from the server 108. If not received, the process proceeds to step 504. In step 504, it is checked whether the time of the session start response message reception waiting timer has elapsed, and if it has elapsed, the process proceeds to step 505. In step 505, it is checked in this session start sequence whether the number of transmissions of the session start message is equal to or less than a predetermined number. If the number exceeds the predetermined number, the process proceeds to step 508 and the session start process is failed and terminated. To do. If the predetermined number of times has not been exceeded, in step 506, the session start request message 700 is retransmitted. In step 507, similarly to step 502, a reception waiting timer for the session start response message 900 is set, and the process returns to step 503. When the session start response message 900 is received in step 503, the process proceeds to step 509, in which the device driver that transmits the session establishment message 1000 is designated and transmitted to the device driver that is performing the session start processing.

  Here, FIG. 10 illustrates a packet format of the session establishment message 1000. The session establishment message 1000 is stored in the message type 1001, and the cognitive IP address of the terminal 107 is stored in 1002. The path ID is stored in 1003, and the time stored in the transmission time (2) 905 of the session start response message 900 from the server 108 is stored in 1004.

  Returning to the description of FIG. 5, in step 510, the session start request message 700 is sent by comparing the time stored in the transmission time (1) 904 of the session start response message 900 from the server 108 with the current time of the terminal 107. Calculate the RTT by calculating the time taken from sending to receiving the session start response message 900. The path with the server 108 that has received the session start response message 900 is added to the path management table 1100 in step 511 as a path capable of multipath communication.

  Here, FIG. 11 illustrates the path management table 1100 of the terminal 107. A column 1101 describes the cognitive IP address of the server 108 as a destination. A column 1102 stores a path ID. A column 1103 describes the physical IP address of the transmission destination. A column 1104 describes the source address of the terminal 107. A column 1105 describes the distribution rate for the path. The distribution rate is calculated based on the transmission rate 802 of the communication path described and used in the path management table 1100. For example, the distribution rate of paths using device driver A can be calculated according to the following formula.

"Distribution rate to device driver A" = 100 x "transmission rate of device driver A" / "sum of transmission rates of all paths"
According to the transmission rate illustrated in FIG. 8, the transmission rate of I / FA is 60, and the sum of the transmission rates of all paths is I / FA transmission rate 60, I / FB transmission rate 30, and I / FC. 100 because it is the sum of the transmission rates of 10. Therefore, the allocation rate to I / FA is 100 × 60/100 = 60%.

  A column 1105 describes the RTT with the server 108. Column 1107 describes whether each path is a primary path with the shortest RTT. If it is a primary path, 1 is entered, and if it is not a primary path, 0 is entered. A column 1108 describes the remaining time of the pass confirmation timer. Write information about the path in each line. As an example, a line 1109 in which the session start process is performed by the device driver AA of the terminal 107 and the communication destination is the server A108 will be described. If the server A108 is described in the column 1101, and the path ID is 1, for example, the path ID1 is described in the column 1102. The address of the device driver D of the server A 108 can be found by examining the source address of the IP header of the packet including the session start response message 900 from the server 108. In this embodiment, since the cognitive IP address of the server 108 and the IP address of the device driver D are the same, the IP address of the device driver D of the server A 108 is also the server A 108. The address of the device driver D of the server A 108 acquired from the source address of the IP header is described in column 1103, and I / F A is described as the source address of the terminal 107 in column 1104. The RTT calculated in step 510 is stored in column 1106. The column 1107 stores whether or not the path shown in the column 1109 is a primary path for the server A108, but 0 is entered because it is still unknown at the time of step 511. A column 1108 describes the remaining time of the path confirmation timer as a timer until the path confirmation process is performed. For the time of the pass confirmation timer, a predetermined value (for example, 30 seconds) is described.

  Returning to the description of FIG. 5, in step 512, it is searched whether or not the path added in step 511 is the shortest RTT among the paths to the server A108, and if the RTT is the shortest, the primary path is set in step 513 to the column 1107. 1 should be entered. If RTT is the shortest, nothing is done. With the above processing, the session start processing is successful (step 514), and the processing is terminated.

  Returning to the explanation of FIG. 2, when the session start process is completed in step 204, it is checked in step 205 whether the session start process is successful, and one of the session start processes performed for each device driver is successful. If so, the process proceeds to step 209. If all the session start processes fail, the process proceeds to step 206. If unsuccessful, the session state of the corresponding row of the session management table is disabled in step 206, and the session re-establishment timer is described in the corresponding row of the session management table in step 207. The reestablishment timer time may be a predetermined value. When the time of the session re-establishment timer has elapsed in step 208, the process returns to step 201 and the session state is not established. If the session start process is successful, in step 209, the session state of the relevant row in the session management table is established, and the process waits until an event occurs. The events waiting for occurrence include step 211 in which the time of the path confirmation timer elapses, step 212 in which a path is added due to connection to a new network, etc., and step 213 in which disconnection from the network is detected and the path is deleted. is there. When the path confirmation timer described in the path management table 1100 elapses in step 211, path confirmation processing is performed for the elapsed path in step 217.

  In the path confirmation process (step 217), the multipath control 117 of the terminal 107 transmits a path confirmation request message 1200 to the server 108. The multipath control 118 of the server 108 that has received the path confirmation request message 1200 causes the terminal 107 to transmit a path response message. The multipath control 117 of the terminal 107 that has received the path confirmation response message causes the server 108 to transmit a path confirmation notification message. The device driver that transmits the message is a device driver that performs path confirmation.

  FIG. 12 illustrates a packet format of the path confirmation request message 1200. A column 1201 stores a path confirmation request message 1200 as a message type, and 1202 stores a cognitive IP address of the terminal 107. A path ID for performing path confirmation is stored in 1203, and a transmission time of the path confirmation request message 1200 is stored in 1204. Next, the packet format example of the path confirmation response message is the same as the format shown in FIG. The path confirmation response message is stored in the message type 901, and the cognitive IP address of the server 108 is stored in 902. In 903, the path ID stored in 1203 of the path confirmation request message 1200 is stored. The transmission time stored in 1204 of the path confirmation request message 1200 is stored in transmission time (1) 904, and the transmission time of the path confirmation response message is stored in transmission time (2) 905. An example of the packet format of the path confirmation notification message is the same as the packet format shown in FIG. A path confirmation notification message is stored in the message type 1001, and the cognitive IP address of the terminal 107 is stored in 1002 of the terminal 107. The path ID for which path confirmation has been performed is stored in 1003, and the transmission time of the path confirmation response message stored in 1005 of the path confirmation response message 1307 is stored in 1004.

  FIG. 13 shows a flowchart of the path confirmation processing by the multipath control 117 of the terminal 107. When the path confirmation request message 1200 is transmitted in step 1301, a reception waiting timer for the path confirmation response message is set in step 1302. In step 1303, it is checked whether a path confirmation response message has been received. If a path confirmation response message has been received, the process proceeds to step 1310, and if not, the process proceeds to step 1304. In step 1304, it is checked whether the path confirmation response message reception timer has elapsed. If not, the flow returns to step 1303. If it has passed, in step 1305, it is checked whether the number of transmissions of the path confirmation request message 1200 is a predetermined number or less. If it is not less than the predetermined number, the path is disconnected, so the path is managed in step 1308. Delete the row in table 1100. If there are other paths remaining in step 1309, another path with the shortest RTT is reset as the primary path and the process is terminated. If it is equal to or smaller than the predetermined number, the path confirmation request message 1200 is retransmitted in step 1306, the path confirmation response wait timer is set in the same manner as in step 1302 in step 1307, and the process returns to step 1303.

  If a path confirmation response message is received in step 1303, a path confirmation notification message is sent to the server 108 in step 1310. In step 1311, the RTT is calculated by comparing the transmission time (1) 1004 of the path confirmation response message with the current time. Calculate and update the RTT in the column of the path management table 1100. In step 1312, the path confirmation timer for the relevant line in the path management table 1100 is reset. In step 1313, it is checked whether the RTT of the path for which the path confirmation processing has been performed with the server 108 is the shortest, and if it is the shortest, the primary path is set in step 1314. If there are other short paths, do nothing. With the above processing, the path confirmation processing is determined to be successful in step 1315 and the processing is terminated.

  Returning to the explanation of FIG. 2, the result of the path confirmation process in step 217 is checked in step 218. If the path is disconnected, the process proceeds to step 215. If the path is not disconnected, the process returns to step 209. If the event generated in step 210 is the path addition step 212, in step 216, session start processing is performed using the added path. When a path is added, a device driver and a network interface device are newly attached to the terminal 107, and a case where the device driver and the network interface device are connected to a network that has not been connected before. .

  If the event generated in step 210 is the path deletion step 213, path deletion processing is performed in step 214. Path deletion is processing performed when it is detected that the network has been disconnected, such as when a device driver attached to the terminal 107 is removed, or if the connected network is out of service if it is wireless. is there. In the path deletion process, the multipath control 117 of the terminal 107 that has detected the path deletion transmits a path deletion request message to the server 108 using the primary path. The multipath control 118 of the server 108 that has received the path deletion request message returns a path deletion response message to the terminal 107. The message used in the route deletion process is transmitted by specifying the device driver that is the primary path as the transmission destination.

  FIG. 14 illustrates packet formats of a path deletion request message and a path deletion response message 1400. Each message type 1401 stores a “path deletion request message” or a “path deletion response message”. In the case of a path deletion request message, the cognitive IP address 1402 stores the cognitive IP address of the terminal 107, and in the case of a path deletion response message, the cognitive IP address of the server 108 is stored, and the path ID 1403 stores the ID of the path to be deleted. .

  FIG. 15 illustrates a path deletion processing flowchart of the multipath control 117 of the terminal 107. In step 1501, the row of the path is deleted from the path management table 1100, and in step 1502, it is checked whether another path exists at the same communication destination. If another path does not exist, the process ends. If another path exists, it is checked in step 1503 if the deleted path is a primary path. If not, the process proceeds to step 1505. If it is the primary path, in step 1504, the path with the shortest RTT is set as the primary path in the remaining paths.

  In step 1505, a path deletion request message 1400 is transmitted from the primary path. The transmission destination for transmission is performed for all communication destinations that can communicate with the deleted path among the communication destinations described in the destination of the path management table 1100. In step 1506, a reception wait timer for the path deletion response message 1400 is set. The timer time is a predetermined value. In step 1507, it is checked whether or not a path deletion response message 1400 has been received.

  If it has not been received, it is checked in step 1508 whether the path deletion response message reception waiting timer has elapsed, and if not, the process returns to step 1507. If it has elapsed, it is checked in step 1509 if the number of transmissions of the path deletion request is less than a predetermined number, and if not less than the predetermined number, the process is terminated. If it is less than or equal to a certain number, the path deletion request message 1400 is retransmitted in step 1510, the path deletion response message reception waiting timer is set in step 1511 in the same manner as in step 1506, and the process returns to step 1507. The above is the path deletion process of the terminal 107.

  Returning to the description of FIG. 2, when the path deletion processing step 214 is completed, the path management table 1100 is checked in step 215, and whether a path exists for the communication destination whose session state has been established in the session management table 400. Perform the check. If the path does not exist, the relevant line is deleted from the session management table 400, and the process returns to step 201. If the path exists, the process returns to step 209.

  If the event generated in step 210 is not any of steps 211 to 213, the session remaining time in the session management table 400 has elapsed or a session end request message has been received. In step 219, session end processing is performed. In the session end process, the multipath control 117 of the terminal 107 transmits a session end request message to the server 108. When the multipath control 118 of the server 108 receives the session end request message, it returns a session end response message to the terminal 107. Upon receiving the session end response message, the multipath control 117 of the terminal 107 transmits a session end confirmation message 1600 to the server 108. The message used in session termination processing is sent by specifying the device driver that is the primary path as the destination.

  FIG. 16 illustrates the packet format of the session end confirmation message. The message type 1601 stores the type of each message, and the cognitive IP address 1602 stores the cognitive IP address of the message transmission source.

  Next, FIG. 17 illustrates a flowchart of session end processing of the multipath control 117 of the terminal 107 and the multipath control 118 of the server 108. In step 1701, it is checked whether the end process starts due to the elapse of the session end timer or the start is due to reception of the session end request message 1600. If a session end request is received, the process proceeds to step 1710. If the session end timer has elapsed, the process proceeds to step 1702, and a session end request message 1600 is transmitted from the primary path. In step 1703, a session end response message reception timer is set to a predetermined time.

  In step 1704, it is checked whether or not a session end response message has been received. If not received, the process proceeds to step 1705 to check whether the session end response message reception waiting timer has elapsed. If it has not elapsed, the process returns to step 1704. If it has not elapsed, in step 1706, it is checked whether the number of transmissions of the session end request message is equal to or less than a predetermined number. If the number of transmissions is not less than a certain number, the process proceeds to step 1716. If it is equal to or smaller than the predetermined number of times, the session end request message is retransmitted in step 1707. In step 1708, the session end response message reception waiting timer is set in the same manner as in step 1703, and the process returns to step 1704. When the session end response message is received in step 1704, a session end confirmation message 1600 is transmitted from the primary path in step 1709, and the process proceeds to step 1716.

  If a session end request is received in step 1701, in step 1710, a session end response message is transmitted from the primary path to the transmission source that has transmitted the session end request. Next, in step 1711, the reception waiting timer of the session end confirmation message 1600 is set to a predetermined value. In step 1712, it is checked whether or not a session end confirmation message 1600 has been received. If not received, the process proceeds to step 1713 to check whether the session end confirmation message reception waiting timer has elapsed. If it has elapsed, the process proceeds to Step 1716.

  If it has not elapsed, it is checked in step 1714 whether the session end request message has been retransmitted. If it has not been retransmitted, the process returns to step 1702. If it has been resent, the session end response is resent in step 1715, and the process returns to step 1702. In step 1706, all paths destined to the communication destination for which the session termination processing has been performed are deleted from the transaction management table. In step 1717, the line relating to the session of the communication destination is deleted from the session management table, and the processing is terminated.

  Returning to the description of FIG. 2, when the session end processing is completed in step 219, the process returns to step 201.

  According to the above state transition flowchart, the multipath control 117 of the terminal 107 can manage the session state with the multipath control 118 of the communication destination server 108.

  Next, a state transition flow of the multipath control 118 of the server 108 will be described with reference to FIG.

  The process starts from step 301 in which the session state is not established, and waits in step 302 until a session start request is received. If a session start request is received, the process proceeds to step 303 and the corresponding row is added to the session management table. In step 304, session start processing is performed. A plurality of session start processes may be performed in parallel.

  FIG. 6 illustrates a flowchart of the session start process of the multipath control 118 of the server 108. When the session start request message 700 is received from the terminal 107 in step 601, the process proceeds to step 602 and a session start response message 900 is transmitted. The destination of the session start response message is the source address of the session start request message. In step 603, a reception waiting timer for the session establishment message 1000 is set to a predetermined value, and in step 604, it is checked whether the session establishment message 1000 has been received. If received, go to step 610. If not received, the process proceeds to step 605 to check whether the session establishment message reception waiting timer has elapsed.

  If not, the process returns to step 604. If it has elapsed, the process proceeds to step 606, where it is checked whether the number of transmissions of the session start response message 900 is equal to or less than a predetermined number. If it is not less than a certain number of times, the session start process will fail and the process will end. If it is equal to or smaller than the predetermined number of times, the session start response message 900 is retransmitted in step 607. In step 608, similarly to step 603, a session establishment message reception waiting timer is set, and the process returns to step 604. In step 610, the RTT is calculated by comparing the transmission time of the session start response message 900 stored in the session establishment message 1000 with the current time. In step 611, the path to the transmission source of the session start request message 700 is added to the path management table 1100.

  The path management table 1100 of the server 108 is the same as the path management table 1100 of the terminal 107 shown in FIG. 11. However, a predetermined waiting confirmation timer for path confirmation is described in the column 1108. The path confirmation reception waiting timer needs to be set longer than the path confirmation timer of the terminal 107, such as three times the path confirmation timer of the terminal 107 described in step 511 of FIG. Further, the transmission rate 704 stored in the session start request message 700 shown in FIG. 7 is used as the transmission rate of each path used for calculating the distribution rate in the column 1105. In step 612, it is checked whether the path added in step 611 is the path with the shortest RTT. If the path has the shortest RTT, the path is set as the primary path in step 613. Without passing, the process proceeds to step 614, where the session start process is successful and the process ends.

  Returning to the description of FIG. 3, the result of the session start process is checked in step 305. If all the session start processes fail, the process proceeds to step 306 to disable the session state of the session management table. Similarly, a session re-establishment timer is set. In step 308, it is checked whether the session re-establishment timer has elapsed. If even one of the session start processes is successful, the session state of the session management table is established in step 309, and an event derivation is waited in step 310. The event generated in step 310 is one of a step 311 for receiving a path confirmation request message 1200, a step 312 for passing a path confirmation reception timer, a step 313 for receiving a path addition request message, and a step 314 for receiving a path deletion request message 1400. . If the generated event is the step 311 for receiving the path confirmation request message 1200, the process proceeds to step 318 to perform path confirmation processing.

  FIG. 18 illustrates a flowchart of the path confirmation processing of the multipath control 118 of the server 108. When the path confirmation request message 1200 is received in step 1801, a path confirmation response message is returned to the transmission source of the request message in step 1802. In step 1803, the reception waiting timer for the path confirmation notification message is set to a predetermined value. In step 1804, it is checked whether a path confirmation notification message has been received. If it has been received, the process proceeds to step 1811. If not received, the process proceeds to step 1805. In step 1805, it is checked whether the path confirmation notification message reception waiting timer has elapsed. If it has elapsed, the process proceeds to step 1809, where the path is disconnected and the process is terminated. If the path confirmation notification message reception wait timer has not elapsed, it is checked in step 1806 whether the path confirmation request message 1200 has been retransmitted. If no retransmission has been received, the process returns to step 1804.

  If it has been received, the path confirmation response message is resent in step 1807. In step 1808, the reception waiting timer for the path confirmation notification message is set in the same manner as in step 1803, and the process returns to step 1804. When the path confirmation notification message is received, in step 1810, the RTT of the path is calculated by comparing the transmission time of the path confirmation response message stored in the path confirmation notification message with the current time. In step 1811, the path confirmation reception timer of the path management table 1100 is reset. In step 1812, the path having undergone the path confirmation process is checked for the path with the shortest RTT. If the path is the shortest, the primary path is set in step 1813, the path confirmation process is successful, and the process ends.

  Returning to the description of FIG. 3, it is checked in step 319 whether the path is disconnected. If the path is not disconnected, the process returns to step 309. If the path is disconnected, the process proceeds to step 316. If the event that occurred in step 310 is step 312 of the path confirmation reception timer, the process proceeds to step 316 to perform path deletion processing.

  FIG. 19 illustrates a flowchart of the path deletion process of the server 108. In step 1901, it is checked whether the reception is a path deletion request message 1400. If the path deletion request message 1400 is received, a path deletion response message 1400 is returned to the request message sender in step 1902, and the process proceeds to step 1903. . If the path deletion request message 1400 is not received but the path is cut by the path confirmation process or if the path confirmation reception timer has elapsed, the process proceeds to step 1903 without executing step 1902. In step 1903, the path is deleted from the path management table 1100, and the process proceeds to step 1904. In step 1904, it is checked whether there is another path at the same destination as the path that has been deleted. If not, the process ends. If there is another path, the process proceeds to step 1905, where it is checked whether the deleted path is the primary path. If it is not the primary path, the process is terminated. If it is the primary path, the process proceeds to step 1906, and the path having the shortest RTT among the other paths is set as the primary path, and the process is terminated.

  Returning to the description of FIG. 3, as a result of the path deletion process, it is checked in step 317 whether a communicable path remains. If a path remains, the process returns to step 309. If not, delete the session from the session management table and return to step 301. If the event generated in step 310 is the step 313 for receiving a path addition request message, the process proceeds to step 315 to perform session start processing, and then returns to step 309. If the event generated in step 310 is the step 314 for receiving the path deletion request message 1400, the process proceeds to step 316. If the event generated in step 310 is not one of steps 311 to 314, the session remaining time described in the session management table has elapsed or a session end request message has been received, and the session end process is performed in step 320 . The session termination process is the same as the flowchart shown in FIG.

  By following the above state transition flow, the multipath control 118 of the server 108 can perform session state management with the multipath control 117 of the communication destination terminal 107.

  Data packet transmission processing for communication between the client application 102 of the terminal 107 and the server application 105 of the server 108 is performed according to the session state of multipath communication. The data packet is transferred to the virtual interface 104 or 106, and transmission processing is performed.

  FIG. 20 illustrates a flowchart of data packet and message transmission processing by the virtual interface 104 or 106. When a packet transmission request is received in step 2001, it is determined in step 2013 whether it is a message or a data packet. Whether it is a message can be determined by the port number. If it is a message, the device driver used for transmission is determined as the device driver designated by the multipath control 117 or 118, and the process proceeds to step 2008.

  If it is not a message, the session management table managed by the multipath control 117 or 118 is referred to search for a communication partner that matches the destination of the data packet. When the search ends, the process proceeds to step 2002. In step 2002, if there is no matching communication partner as a result of the search, it is determined that the session state has not been established, and the process proceeds to step 2003 to discard the data packet. In step 2005, the virtual interface 104 or 106 issues a communication start request for the destination of the data packet to the multipath control 117 or 118, and ends the processing. In step 2002, if the session state of the matched communication partner is already established, the process proceeds to step 2006, and the subsequent distribution process is performed.

  As a distribution process, in step 2006, the path management table 1100 managed by the multipath control 117 or 118 is referred to, a device driver to be transmitted is determined according to the distribution ratio of the path matching the destination, and the process proceeds to step 2007. In step 2007, the session remaining time of the row in the session management table is extended to a predetermined value, and the process proceeds to step 2008. In step 2008, the data packet is encapsulated for transmission from the device driver that performs transmission. In this embodiment, in order to support the NAPT technology used when a global IP address is not assigned to the terminal 107, the packet packetized by the IP layer processing unit is stored in the payload portion of the UDP packet together with the IP header. Encapsulation. The NAPT technology is described in the technical document RFC2663 (http://www.ietf.org/rfc/rfc2663.txt) published by the IETF. The IP header to be sent from the device driver is stored in the IP header of the encapsulated data packet as before. The source address stored in the IP header follows the device driver. The destination port number stored in the UDP header of the encapsulated packet may be a value determined for this communication. The IP header of the data packet received from the IP layer processing unit stored in the payload part of the encapsulated packet is the IP header when the virtual interface is the source, the destination cognitive IP address as the destination address, The cognitive IP address assigned to the local device is stored as the source address.

  When the encapsulation of the data packet is completed and the distribution process is completed, the process proceeds to step 2009 and the device driver transmits to the network. Routing for transmission is performed according to the routing table held by the operating system of the terminal 107 or the server 108, and the process is terminated.

  If the destination session state has not been established in step 2005, the process proceeds to step 2010 to check whether the session state is not possible. If the session state is not possible, the destination is a node that does not support multipath communication. Therefore, the packet passed to the virtual interface 104 or 106 is not encapsulated and is transmitted as it is from the device driver. A device driver that performs transmission is determined according to a routing table held by the operating system of the terminal 107 or the server 108. If the destination session state is not impossible in step 2010, the process proceeds to step 2012, where the packet is discarded and the process is terminated.

  FIG. 21 illustrates a flowchart of data packet and message reception processing in the terminal 107 and the server 108. When all the packets received by the device driver in step 2101 are handed over to the virtual interface 104 or 106, it is determined in step 2106 whether or not it is a message. move on. Whether it is a message can be determined by the port number. In step 2102, it is checked whether the data packet is encapsulated for multipath communication. If it is an encapsulated packet, the process proceeds to step 2103 to decapsulate the data packet.

  Decapsulation is a process of removing the IP header 2601 and the UDP header 2602 and taking out the data packet transmitted from the virtual interface 104 or 106 of the transmission source. If it is not an encapsulated packet, the process proceeds to step 2104, where the destination of the data packet is converted into the cognitive IP address of the terminal 107 or server 108 that received it. By performing the conversion, it is possible to process data packets from a node that does not support multipath communication as if they were transmitted to a cognitive IP address. The processed data packet is handed over to the operating system of the terminal 107 or the server 108 in step 2105 and subjected to the same receiving process as before, and then passed to the application.

  As described above, multipath communication using a plurality of communication paths can be provided as one communication to the application layer without changing the transport layer processing unit. Further, even when the network to be connected is changed due to movement of the communication device, the application layer program can continue communication.

It is an example of the system configuration | structure of this embodiment. 10 is an example of a state transition flow of multipath control 117 of terminal 107. 4 is an example of a state transition flow of multipath control 117 of the server 108. It is an example of the management table of a session. 12 is an example of a session start processing flow of multipath control 117 of terminal 107. 6 is a session start processing flow example of multipath control 117 of the server 108. 4 is a packet format example of a session start request message 700. 4 is an example of a transmission rate setting table 800. 10 is a packet format example of a session start response message 900. 10 is a packet format example of a session establishment message 1000. 4 is an example of a path management table 1100. 4 is a packet format example of a path confirmation request message 1200. 10 is an example of a flow of a path confirmation process of a multipath control 117 of the terminal 107. It is an example of a packet format of a path deletion request message and a path deletion response message. 12 is an example of a path deletion process flow of multipath control 117 of terminal 107. It is a packet format example of a message used in session termination processing. 12 is an example of a path deletion process flow of the multipath control 117 of the server. 10 is an example of a path confirmation processing flow of a multipath control 117 of the server 108. 12 is an example of a path deletion process flow of the multipath control 117 of the server. It is a data packet transmission flow example of a virtual interface It is a data packet reception flow example of the virtual interface

Explanation of symbols

107: terminal, 108: server, 400: session management table, 700: session management start request message, 900: session start response message, 1000: session establishment message, 1100: path management table, 1200: path confirmation request message, 1400: Path deletion request message / path deletion response message, 1600: Session end confirmation message.

Claims (5)

A multipath communication system including a terminal and a server connected via a network,
The terminal includes a plurality of network interface devices each assigned a different network address,
The server includes one network interface device,
The terminal includes an operating system, an application program, a device driver for the plurality of network interface devices, and a virtual interface program that connects the operating system and the device driver, and is executed by a processor.
The operating system includes an IP layer processing program that converts data handled by the application program and an IP packet suitable for transmission / reception on the network,
The virtual interface program is a relay process of an IP packet exchanged between the IP layer processing program and the device driver, one IP layer processing interface as one device driver for the IP layer processing program, The device driver interface for the device driver, and for each session, for a plurality of IP packets received from the one IP layer processing interface, performing a distribution process to be transmitted from any of the plurality of network interface devices, A process for transmitting to a device driver and a process for transmitting an IP packet received by the plurality of network interface devices from the one IP layer processing interface to the IP layer processing program are realized.
The terminal and the server each include a multipath control program executed by a processor included in each of the terminals and the server,
The multipath control program of the terminal and the server mutually checks whether a communication partner device supports multipath communication and / or whether multipath communication using the plurality of network addresses is possible. Exchange messages for
For each communication partner device, the session has not been established, the session has not been established, the session has been established for the communication partner device but has not yet been established, and the communication partner device Manages the session established state, communication path does not exist with the communication partner device, or the communication partner device does not support multipath communication, and the session is not established Or, when a predetermined time has passed in a session established state, perform message exchange with the multipath control program of the server as a communication partner, perform path addition processing or path deletion processing,
The device driver is used to transmit a session start request message to the multipath control program of the server and receive a session start response message from the multipath control program of the server. The session that uses the path with the shortest round trip time is used as the primary path.
A multipath communication system. The multipath communication system according to claim 1,
The multipath control program further calculates a distribution ratio to the plurality of network interface devices,
The virtual interface program is
A multipath communication system characterized in that, for each session, a plurality of IP packets received from the one IP layer processing interface are subjected to the distribution processing to the plurality of network interface devices according to the calculated distribution ratio. . The multipath communication system according to claim 2 , wherein
The virtual interface program is
A multipath communication system, wherein encapsulation is performed by storing an IP packet received from the IP layer processing interface in a payload portion of a UDP packet. The multipath communication system according to claim 2 , wherein
The multipath control program of the terminal is
The network address assigned to the virtual interface program provided in a device to be a communication partner;
For each path, a path ID uniquely determined in the terminal,
A network address assigned to a network interface device included in the device and the device to be communicated with;
A multipath communication system, characterized by managing a path management table including the distribution ratio to the plurality of paths. The multipath communication system according to claim 4 , wherein
The virtual interface of the terminal and the server checks whether the data packet received by the device driver has been encapsulated,
If the encapsulation has been performed, take out the IP packet,
If the encapsulation is not performed, the destination of the data packet is converted to the network address that uniquely identifies the received terminal or the server in the network.

Images