JP2014022969A - マルチホーム通信方法およびシステム - Google Patents

Abstract

【課題】モバイル端末がNATを介してネットワークに接続されているために、そのIPアドレスをサーバに既登録のアソシエーションと対応付けられない場合でも、サーバとの間に簡単にマルチホーム接続を確立する。
【解決手段】サーバのトランスポート層において、疎通確認部１１は、モバイル端末との間に確立されたアソシエーション１４において、モバイル端末から受信したHEARTBEATに応答した疎通確認を、その送信元SCTPポート番号および当該アソシエーション１４に固有の検証タグのペアに基づいて行う。追加登録要請部１２は、IPアドレスが自身に未登録のHEARTBEATが受信されると、その送信元に対して当該IPアドレスの追加登録要請が記述された応答を返信する。モバイル端末のトランスポート層において、アドレス追加要求部１３は、前記HEARTBEATに対する応答が受信されると、自身のIPアドレスの追加を要求するメッセージをサーバへ送信する。
【選択図】図１

Description

本発明は、マルチホーム通信方式およびシステムに係り、特に、SCTPにより通信パスの迅速な追加を実現するマルチホーム通信方式およびシステムに関する。

現在、3G、Wi-Fi（登録商標）、WiMAX（登録商標）あるいはLTE（登録商標）等の複数の無線ネットワークに対応したAndroid OS搭載のモバイル端末(スマートフォン)が普及している。一般的なAndroid端末は、複数の無線ネットワークに同時接続することは行わず、一つの無線ネットワークのみに接続するため、接続中の無線ネットワークに障害や品質劣化が発生すると通信品質の劣化や通信セッションの切断が発生する。このような技術課題に対して、非特許文献１，２では、無線ネットワークの品質や周囲の電波強度・混雑度を測定し、接続するネットワークを選択する(切替える)技術が研究・議論されているが、通信パスの切り替え基準や切り替え時間が問題となる。

一方、トランスポート層で通信パスを切替える技術として、エンドホスト間で複数の通信パスを用いたコネクション(マルチホーム)を確立し、１つの通信パス上で障害が発生した場合は、残りの通信パスにトラヒックを切り替えることで高信頼な通信を実現するSCTP(Stream Control Transmission Protocol)が注目されている。

しかしながら、非特許文献３，４に開示されている標準のSCTPでは、マルチホーム接続を確立した場合であっても、実際にデータ転送に用いられるのは、"プライマリパス"と呼ばれる１本の通信パスのみであるため、障害や品質劣化の発生時には、従来技術と同様に、他の通信パスへの切り替え基準や切り替え時間が問題となる。

一方、非特許文献６には、複数の通信パスで同時にデータ転送を行うことにより、通信(スループット)を高速化する手法（Concurrent Multi-path Transfer(CMT) SCTP）が提案されており、この手法は通信を高信頼化させる効果もある。また、特許文献７には、CMT-SCTPを利用して、NAT環境においても通信パスの追加・削除を実現可能とする手法が提案されている。

標準のSCTPは、FreeBSDやWindows（登録商標）等の多くのOS上に試験的に実装され、非特許文献５には、Android(Linux（登録商標）)上で動作するライブラリも開示されているものの、現在のインターネットにおける通信の大半はTCP/UDPをベースとしており、SCTPを用いた一般ユーザ向けのモバイル通信サービスは展開されていない。このため、SCTP通信をエンドツーエンドで実現するためには、既存のサーバやコンピュータプログラムをSCTP通信に対応させる必要がある。

福山他、"IPv4 移動体通信において携帯電話網と無線LAN 間をシームレスに移動する方式の提案," マルチメディア、分散協調とモバイルシンポジウム 2011 論文集，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

SCTPでは、エンドホスト間に複数の通信パスを用いてアソシエーション(TCPのコネクションに相当する)を確立するマルチホーム接続が可能である。ただし、標準のSCTPは各エンドホストにグローバルなIPアドレス(IPv4アドレスまたはIPv6アドレス)が付与される状況を想定して設計されており、必ずしも、現在のインターネットにおいて広く普及しているNAT(Network address translation)装置を介した通信に適した設計になっていない。このため、エンドホスト間にアソシエーションが確立された後で、NAT装置を介した通信パスを追加しようとすると、以下のような技術課題が生じる。

ここでは、ネットワークにNAT装置を介して接続するモバイル端末MNがサーバSにマルチホーム接続する際の手順を、図５のシーケンスフローを参照して、モバイル端末MNが２つのインタフェースIF(a1，a2)を備え、サーバSが２つのインタフェースIF(b1，b2)を備える場合を例にして説明する。

(1)時刻t1では、モバイル端末MNがサーバSとの間にアソシエーション呼ばれる論理的な接続（SCTPコネクション)を確立するために、一方のインタフェースIF(a1)からサーバSの一方のIF(b1)へINITチャンクを送出し、モバイル端末MNの一方のインタフェースIF(a1)の割り当てられているグローバルIPアドレスGA(1st)がサーバSへ通知される。ここで、IF(a1)，IF(b1)間の通信がNAT装置を介して行われると、モバイル端末MNは自身のグローバルIPアドレスを知らないため、送出するINITチャンクに自身のグローバルIPアドレスGA(1st)を付与できない。ただし、サーバSは受信パケットのIPヘッダ等を参照することにより、モバイル端末MNの一方のインタフェースIF(a1)に割り当てられているグローバルIPアドレスGA(1st)を認識できる。

(2)時刻t2では、サーバSの一方のインタフェースIF(b1)からモバイル端末MNの一方のインタフェースIF(a1)へINIT-ACKチャンクが返信され、サーバSの各インタフェースIF(b1)，IF(b2)に割り当てられているグローバルIPアドレスGA(b1)，GB(b2)がモバイル端末MNへ通知される。さらに、時刻t3，t4ではIF(a1)-IF(b1)間で認証処理のためのCOOKIE-ECHOおよびCOOKIE-ACKの各チャンクが送受される。これにより、IF(a1)-IF(b1)間に第１通信パス（プライマリパス）が接続されてアソシエーションの確立が完了する。

(3)次いで、IF(a2)-IF(b2)間に通信パスを新たに追加する場合を考える。SCTPでは、通信パスの追加手順として、当該通信パス[IF(a2)-IF(b2)]に対してHEARTBEAT/HEARTBEAT-ACKチャンクの送受信による疎通性の確認が行われ、通信パスがACTIVE(かつCONFIRMED)状態にあることが判別された後、ASCONF(Address Configuration Change)チャンクにより通信パスの追加・削除が行われる。このため、モバイル端末MNは時刻t5以降、IF(a2)からサーバSのIF(b2)宛にHEARTBEATを周期的に送出する(ここで、SCTPの実装によっては、モバイル端末MNはサーバSに対してIF(a1)からHEARTBEATを送出してしまい、厳密には通信パス[IF(a2)-IF(b2)]の疎通性を確認しない場合もあるが、ここでは、モバイル端末MNがHEARTBEATの送出元を指定できるものと想定する)。

(4)サーバSは、モバイル端末MNのIF(a2)から送出されたHEARTBEATを受信すると、その送出元IPアドレスGA(2nd)をIPヘッダ等より抽出し、サーバS上で管理しているグローバルIPアドレスとアソシエーションとの対応リストを参照する。しかしながら、当該グローバルIPアドレスGA(2nd)は対応リストに存在しないので当該HEARTBEATは廃棄され、時刻t6において、その送出元のグローバルIPアドレスGA(2nd)に対して、アソシエーションの切断を通知するためのABORTチャンクが送出されてしまう。

(5)前記ABORTチャンクを受信したモバイル端末MNでは、先に接続したコネクション[IF(a1)-IF(b1)]を含めて、サーバSとのアソシエーションを切断する。

このように、標準のSCTPでは、HEARTBEATの送信元IPアドレス（グローバル）がアソシエーションと予め対応付けられていないと、当該HEARTBEATが廃棄されてしまい、通信パスを追加できないのみならず、その送出元に対して、アソシエーションの切断を通知するためのABORTチャンクが送出されてアソシエーションが切断されてしまうという技術課題があった。

本発明の目的は、上記した従来技術の課題を解決し、モバイル端末MNがNAT装置を介してネットワークに接続するために自身のグローバルIPアドレスをサーバSにおいてアソシエーションと対応付けられない場合でも、サーバSとの間に簡単にマルチホーム接続を確立できるマルチホーム通信方式およびシステムを提供することにある。

上記の目的を達成するために、本発明は、ネットワークにNAT装置を介して接続された一方のノードが他方のノードとの間にマルチホーム接続によるSCTPアソシエーションを確立するマルチホーム通信方法において、以下のような手順を含む点に特徴がある。

(1)一方のノードの第１インタフェースから他方のノードの第１インタフェースへ初期化要求を送信し、これに他方のノードが応答することで第１通信パスを接続してアソシエーションを確立する手順と、他方のノードが、前記初期化要求の検証タグ、送信元IPアドレスおよび送信元SCTPポート番号を対応付けて登録する手順と、一方のノードの第２インタフェースから他方のノードの第２インタフェースへ疎通確認要求を周期的に送信する手順と、他方のノードにおいて、前記疎通確認要求の検証タグおよび送信元SCTPポート番号の対応付けが自身に既登録であれば、当該疎通確認要求の送信元IPアドレスとは無関係に疎通成功の応答を返信する手順とを含む。

(2)他方のノードが、前記疎通確認要求の検証タグおよび送信元IPアドレスの組合せが自身に未登録であると、第２インタフェースから一方のノードの第２インタフェースへ当該IPアドレスの登録要請を返信する手順と、一方のノードが、前記登録要請に応答して、第２インタフェースから他方のノードの第２インタフェースへ前記IPアドレスの追加要求を送信する手順と、他方のノードが、前記追加要求に応答して、前記IPアドレスを前記検証タグと対応付けて登録する手順とを含む。

本発明によれば、以下のような効果が達成される。

(1)一方のノードがNAT装置を介してネットワークに接続されているために、そのグローバルIPアドレスが他方のノードにおいてアソシエーションの検証タグと対応付けられない場合でも、他方のノードにおける疎通確認が、一方のノードのIPアドレスとは無関係に、アソシエーションに固有の検証タグおよび送信元ポート番号の対応付けに基づいて行われるので、疎通確認を成功させて通信パスを追加できるようになる。

(2)他方のノードは、検証タグとの対応付けが未登録のIPアドレスから初期化要求を受信すると、一方のノードへ当該未登録IPアドレスの登録を要請し、一方のノードが当該登録要請に応答して未登録IPアドレスを登録要求すると、当該未登録IPアドレスを検証タグと対応付けて追加登録するので、一方のノードのIPアドレスが何らかの原因で変更され、これを当該一方のノードが認識できない場合でも、通信パスを維持できるようになる。

本発明に係るSCTP通信システムの構成を示したブロック図である。 本発明が適用されるネットワーク構成の一例を示した図である。 本発明が適用されるネットワーク構成の他の一例を示した図である。 本発明の一実施形態に係るマルチホーム接続の手順を示したシーケンスフローである。 従来のマルチホーム接続の手順を示したシーケンスフローである。

以下、図面を参照して本発明の実施の形態について詳細に説明する。本発明は、図２に示したように、専用ソフトウェアをインストール可能なサーバ・コンピュータプログラムとモバイル端末MNとの間でSCTPをベースとしたマルチホーム通信を行うシステムにおいて、通信を高信頼化する手順に関するものである(図中のSCTPベース通信ソフトにおける処理手順)。

また、図３に一例を示したように、IPネットワーク内にプロトコル変換サーバを設置し、SCTP通信とTCP通信とを変換することにより、既存のサーバ・コンピュータを変更することなく、SCTPをベースとしたマルチホーム通信システムを実現する手法も考えられる。本発明は、このようなプロトコル変換サーバを介して既存のサーバ・コンピュータと通信を行うシステムにも適用できる。

図１は、本発明に係るSCTP通信システムの構成を示したブロック図であり、本発明の説明に不要な構成は図示が省略されている。ここでは、モバイル端末MNからサーバSへのマルチホーム接続を例にして説明する。

モバイル端末MNおよびサーバSの各ネットワークノードには、インタフェース層、ネットワーク層、トランスポート層およびアプリケーション層から構成されるIPスタックが実装され、トランスポート層のプロトコルとしてSCTPが採用されている。モバイル端末MNおよびサーバSの各SCTPは、マルチホーム接続用の標準機能に加えて、本発明に固有のオプション機能を備え、これにより通信パス１５の迅速な追加によるマルチホーム通信が可能になる。

サーバSのトランスポート層において、疎通確認部１１は、モバイル端末MNとの間に確立されたアソシエーション(SCTPコネクション)１４において、モバイル端末MNから受信したHEARTBEAT（速確認要求）チャンクに応答した疎通確認を、当該HEARTBEATの送信元IPアドレス（グローバル）とは無関係に、当該HEARTBEATチャンクの送信元SCTPポート番号および当該アソシエーション１４に固有の検証タグのペアに基づいて行う。追加登録要請部１２は、送信元IPアドレスが自身に未登録のHEARTBEATチャンクが受信されると、その送信元に対して、当該未登録の送信元IPアドレスの追加登録要請が記述されたHEARTBEAT-ACKチャンクを返信する。

モバイル端末MNのトランスポート層において、アドレス追加要求部１３は、サーバSへ送信したHEARTBEATチャンクに対して、前記送信元IPアドレスの追加登録要請の記述されたHEARTBEAT-ACKチャンクが受信されると、自身のグローバルIPアドレスの追加登録を要求するASCONFチャンクをサーバSへ送信する。

図４は、上記のオプション機能を備えたモバイル端末MN-サーバS間でのマルチホーム接続の手順を示したシーケンスフローであり、モバイル端末MNは２つのインタフェースIF(a1)，IF(a2)を備え、サーバSは２つのインタフェースIF(b1)，IF(b2)を備えている。サーバSの各インタフェースIF(b1)，IF(b2)には、それぞれグローバルIPアドレスGA(b1),GA(b2)が割り当てられているものとする。

時刻t1では、モバイル端末MNがサーバSとの間にアソシエーションを確立するため、一方のインタフェースIF(a1)からサーバSの一方のインタフェースIF(b1)のグローバルIPアドレスGA(b1)宛にINIT（初期化要求）チャンクを送出し、前記一方のインタフェースIF(a1)に動的に割り当てられるグローバルIPアドレスGA(1st)がサーバ側Sへ通知される。ここでは従来技術と同様に、サーバSは受信パケットのIPヘッダ等を参照することにより、モバイル端末MNの一方のインタフェースIF(a1)に割り当てられるグローバルIPアドレスGA(1st)を認識できる。

時刻t2では、サーバSの一方のインタフェースIF(b1)からモバイル端末MNの一方のインタフェースIF(a1)へINIT-ACK（初期化応答）チャンクが返信され、サーバSの全てのグローバルIPアドレスGA(b1),GA(b2)がモバイル端末MNへ通知される。サーバSでは、前記INITチャンクに記述されている検証タグQならびに当該INITチャンクの送信元IPアドレスおよび送信元SCTPポート番号が相互に対応付けられて登録される。

時刻t3，t4では、IFa1-IFb1間で認証処理のためのCOOKIE-ECHOおよびCOOKIE-ACKの各チャンクが送受されて各インタフェースIFa1，IFb2間に第１通信パス#1が接続され、アソシエーション１４の確立が完了する。

その後、モバイル端末MNがサーバSとの間でマルチホーム接続を実現しようとする場合、時刻t5以降では、モバイル端末MNの他方のインタフェースIF(a2)からサーバSの他方のインタフェースIF(b2)へHEARTBEATが送信され、これに応答して返信されるHEARTBEAT-ACKチャンクに基づいて疎通性が確認される。

このとき、本実施形態では前記疎通確認部１１において、アソシエーション確立時(INIT/INIT-ACKの送受時)に作成される、各アソシエーションに固有の検証タグQ、送信元IPアドレスおよび送信元SCTPポート番号の対応関係のうち、検証タグQおよび送信元SCTPポート番号のペアに基づいて疎通確認が実施され、当該ペアにより特定できるアソシエーションに対してHEARTBEAT-ACKが返信される。すなわち、本実施形態では送信元IPアドレスに基づくアソシエーションの特定は行われない。

ここで、検証タグQおよび送信元SCTPポート番号のペアと一致するアソシエーションがサーバSに未登録であれば、前記HEARTBEATがOOTB(Out Of The Blue)パケットとして扱われてABORTが返信される。これに対して、検証タグおよび送信元SCTPポート番号のペアと一致するアソシエーションがサーバSに既登録であれば、時刻t6において、サーバSのIF(b2)からモバイル端末MNのIF(a2)へHEARTBEAT-ACKのチャンクが返信される。

モバイル端末MNでは、前記HEARTBEAT-ACKの受信により、通信パスがACTIVE(かつCONFIRMED)状態にあることが判別すると、時刻t7において、IF(a2)からサーバSのIF(b2)へASCONF(Address Configuration Change)チャンクを送信して通信パスの追加・削除を要求する。時刻t8では、サーバSからモバイル端末MNへASCONF-ACKチャンクが返信されて第２通信パス#2[IF(a2)-IF(b2)]の接続が完了する。

ところで、HEARTBEATの検証方法が上記のように改修され、モバイル端末MNからサーバSへのHEARTBEATによる疎通確認が、モバイル端末MNのグローバルIPアドレスとは無関係に行われるようになると、以下のような技術課題が新たに生じ得る。

すなわち、モバイル端末MNのグローバルIPアドレスが、アクセスポイントとなるルータ（図示せず）の再起動等により変更された（ここでは、IF(a2)のグローバルIPアドレスがGA(2nd)からGA(3rd)に変更されたものとする）にも関わらず、これをモバイル端末MNが認識できないと、モバイル端末MNとサーバSとの間でASCONFによる新しいグローバルIPアドレスGA(3rd)の登録処理が行われない。したがって、サーバSは変更前のグローバルIPアドレスGA(2nd)に対してデータを送信し続けることになる。

そして、このような状態でもモバイル端末MNからサーバSへのデータ送信は成功し、かつモバイル端末MNのIF(a2)からサーバSのIF(b2)へ定期的に送信され続けるHEARTBEATによる疎通確認も、サーバSでは検証タグおよび送信元SCTPポート番号のペアに基づいて、モバイル端末MNの変更後のIPアドレスGA(3rd)とは無関係に行われるので成功してしまう。その結果、通信パスの片方向（サーバS→モバイル端末MN）においてデータ転送が行えない状態が一定期間持続してしまい、その後、再送が繰り返されて当該第２通信パス#2がサーバSにおいてINACTIVEの状態とされる。

このような技術課題を解決するために、本発明では、HEARTBEATを受信処理するサーバSに、不明なIPアドレス（ここでは、GA(3rd)）からHEARTBEATを受信した際には、その旨を当該不明なIPアドレスの送信元に伝え、送信元にASCONFの送付を促すための構成として、前記図１を参照して説明した追加登録要請部１２を追加している。

さらに具体的に説明すれば、不明なIPアドレスGA(3rd)からHEARTBEATを受信したサーバSが、前記図４の時刻t4においてHEARTBEAT-ACKを返信する際に、HEARTBEAT-ACKチャンクの空きビット[2]に専用のフラグを付与する一方、当該フラグが付与されたHEARTBEAT-ACKを受信したモバイル端末MNでは、前記図１を参照して説明した追アドレス追加要求部１３が、以下の手順に従ってASCONFを送信する。

(1)モバイル端末MNは、新しいIPアドレスGA(3rd)をサーバSに追加登録するためのASCONF_ADDチャンクをIF(a2)からサーバSのIF(b2)へ送信する。サーバSは、当該ASCONF_ADDチャンクのヘッダ情報を参照することでモバイル端末MNの変更後のグローバルIPアドレスGA(3rd)を認識し、当該IPアドレスGA(3rd)を新しいIPアドレスとして前記アソシエーションの検証タグQと対応付けて登録する。

(2)モバイル端末MNは、古いIPアドレスGA(1st)，GA(2nd)の登録をサーバSから削除させるためにASCONF_DELETEチャンクを送信する。サーバSは、当該ASCONF_DELETEチャンクのヘッダ情報を参照することでモバイル端末MNのグローバルIPアドレスGA(3rd)を認識し、同一アソシエーションの当該IPアドレスGA(3rd)以外の全てのIPアドレスGA(1st)，GA(2nd)を削除する。なお、SCTPでは通信パスを削除する場合に、削除するIPアドレスを指定する方法と、指定するIPアドレス以外のIPアドレスを削除する方法との２通りの方法が規定されている。

(3)モバイル端末MNが複数のインターフェース(IPアドレス)を用いてサーバと接続されている場合、上記(2)の処理によって、同一アソシエーションにおける新しいIPアドレスGA(3rd)以外のIPアドレスが削除されてしまうので、再度、インタフェースIF(a1)よりASCONF_ADDチャンクを送信し、削除されたIPアドレスを登録し直す。

１１…疎通確認部，１２…追加登録要請部，１３…アドレス追加要求部，１４…アソシエーション(SCTPコネクション)，１５…通信パス

Claims (6)

1. ネットワークにNAT装置を介して接続された一方のノードが他方のノードとの間にマルチホーム接続によるSCTPアソシエーションを確立するマルチホーム通信方法において、
   一方のノードの第１インタフェースから他方のノードの第１インタフェースへ初期化要求を送信し、これに他方のノードが応答することで第１通信パスを接続してアソシエーションを確立する手順と、
   他方のノードが、前記初期化要求の検証タグ、送信元IPアドレスおよび送信元SCTPポート番号を対応付けて自ノードへ登録する手順と、
   前記一方のノードが、第２インタフェースから他方のノードの第２インタフェースへ疎通確認要求を周期的に送信する手順と、
   前記他方のノードが、前記疎通確認要求の検証タグおよび送信元SCTPポート番号の対応付けが自身に既登録であれば、当該疎通確認要求の送信元IPアドレスとは無関係に疎通成功の応答を返信する手順とを含むことを特徴とするマルチホーム通信方法。
2. 前記他方のノードが、前記疎通確認要求の送信元IPアドレスが自身に未登録であると、第２インタフェースから一方のノードの第２インタフェースへ当該IPアドレスの登録要請を返信する手順と、
   前記一方のノードが、前記登録要請に応答して、第２インタフェースから他方のノードの第２インタフェースへ前記IPアドレスの追加要求を送信する手順と、
   前記他方のノードが、前記追加要求に応答して、前記IPアドレスを前記検証タグと対応付けて登録する手順とを含むことを特徴とする請求項１に記載のマルチホーム通信方法。
3. 前記一方のノードの第２インタフェースから他方のノードの第２インタフェースへ、前記追加要求したIPアドレス以外の既登録のIPアドレスの削除要求を送信する手順と、
   前記他方のノードが、前記削除要求されたIPアドレスの登録を削除する手順とを含むことを特徴とする請求項２に記載のマルチホーム通信方法。
4. 前記一方のノードが、前記第２インタフェース以外のインタフェースから他方のノードの第２インタフェース以外のインタフェースへIPアドレスの登録要求を送信する手順を含むことを特徴とする請求項３に記載のマルチホーム通信方法。
5. ネットワークにNAT装置を介して接続された一方のノードが他方のノードとの間にマルチホーム接続によるSCTPアソシエーションを確立するマルチホーム通信システムにおいて、
   一方のノードが、
   他方のノードへ初期化要求を送信する手段と、
   他方のノードへ疎通確認要求を送信する手段とを具備し、
   他方のノードが、
   一方のノードから受信した初期化要求の検証タグ、送信元IPアドレスおよび送信元SCTPポート番号を対応付けて登録する手段と、
   一方のノードから受信した疎通確認要求の検証タグおよび送信元SCTPポート番号の対応付けが自身に既登録であれば、当該疎通確認要求の送信元IPアドレスとは無関係に疎通成功の応答を返信する手段とを具備したことを特徴とするマルチホーム通信システム。
6. 前記他方のノードが、前記疎通確認要求の送信元IPアドレスが自身に未登録であると、当該IPアドレスの登録要請を返信する手段と、
   前記一方のノードが、前記登録要請に応答して、前記IPアドレスの追加登録を要求する手段と、
   前記他方のノードが、前記追加登録の要求に応答して、前記IPアドレスを前記検証タグと対応付けて登録する手段とをさらに具備したことを特徴とする請求項５に記載のマルチホーム通信システム。